It's common to use '-able' as a suffix for interfaces e.g.

Serializable Printable Enumerable Drinkable Shootable Rotatable

I was thinking that 'Can-' might better because it may be more descriptive. Yes, it is more wordy and it adds noise to the interface name. In particular, passive verbs can be used.

E.g. 1 does Shootable mean that the object is able to shoot (a gun might implement this), or does it means that it can be shot at (a target board might implement this). With the 'Can-' prefix, the former would be "CanShoot" and the latter would be "CanBeShotAt" or "CanShootAt".

E.g. 2 A document 'CanBePrinted' and a printer 'CanPrint'

Or, should we stick with '-Able' and let the documentation provide the context?

Any opinions.

  • Man, use "-able". Period. Commented Jul 18, 2013 at 13:10
  • 2
    Use both for class Cannibal implements Can, Able {} Commented Jul 18, 2013 at 19:41

9 Answers 9


Perhaps you want Is-able?

Some examples from .Net:


There doesn't appear to be a uniform standard. Go with what reads well.

if (document.IsPrintable && printer.CanPrint) { printer.Print(document) }

EDIT: As pointed out, the question was about Interfaces, not Properties.

In that case, I can't find any interfaces named Can-. Interfaces tend to always use -able. I'd agree with this terminology. A method may request as a parameter a ISerializable object or IPrintable document. Asking for a ICanBeSerialized object or a ICanBePrinted document is very awkward to read.

On the other side, the Printer, I'd suggest simply calling the interface IPrinter. Your method will be asking for a IPrinter device.

Read the method signature below out loud. (Personally, I consider the "I" prefix to be silent.) Does it read well? Does it sound right?

void PrintDocument(IPrinter device, IPrintable document)
  • 2
    Document.IsPrintable is better than Document.CanBePrinted. As far as I can tell they used -able to avoid passive voice. Commented Jan 25, 2012 at 10:58
  • "Can be printed" seems like more proper English than "is printable". Commented Jan 25, 2012 at 13:19
  • 2
    "Passive voice is used when the focus is on the action. It is not important or not known, however, who or what is performing the action." I can only guess that they wanted the focus to stay on the object and not the action. So if a "Type.IsSerializable" throws an exception, it's the Type's fault. not the methods' but if a "Type.CanBeSerialized" throws an exception then you'd blame the method and not the type. Admittedly the difference is minor but it's there. Commented Jan 25, 2012 at 13:38
  • 3
    I see that this is the accepted answer, but this doesn't answer the OP's question. The examples provided are Property names. The OP is asking for a naming convention for Interface names, such as ISerializable, IDataErrorInfo, and INotifyPropertyChanged. Commented Jan 25, 2012 at 18:51
  • @KevinMcCormick, good point! Edits above. Commented Jan 26, 2012 at 22:00

Grammatically speaking, "canFoobar" is a predicate, while "Foobarable" is an adjective or a noun (usually a noun in the context of an API).

Also note the subtle difference: -able implies a passive role to the noun it is applied to, that is, if Something is Foobarable, then it can be foobarred by something else; can- implies an active role, that is, if Something canFoobar, then it can foobar something else. Or, from a different angle: if A can foobar B, then A.canFoobar() and B is Foobarable.

In terms of OOP expressivity, I'd associate predicates with methods or properties, while nouns are classes or interfaces. So:


class Something implements Foobarable { ... }

Clearly the prefix and suffix are almost obvious choices for different types of actions or rather, different directions of an action.

Current usage and preferences may be inconsistent due to many reasons, though.

Action is performed by the object:
CanShoot --> It shoots (at) something
CanFly --> It flies
CanChange --> It changes

Action is performed on the object:
Readable --> You can read it
Writable --> You can write (to) it
Printable --> You can print it

While it may not be a rule or even necessarily logical, it helps to adopt the convention and maintain consistency of use in variable naming.

  • But you can just use: CanBeRead / CanBeWritten / CanBePrinted On the contrary you can't do CanShoot --> into -able
    – rufreakde
    Commented Jan 5, 2023 at 8:58

Personally I would stick with the -able version. Here is my reason: Most (all?) graphical editors suggest identifiers based on what you have typed. Although some of them are 'smart' enough to also search within identifiers some still just offer search beginnings of identifiers.

To speed up typing you'd like to shorten the list of suggested identifiers with as few keystrokes as possible. The more identifiers have the same beginning, e.g. 'ICan-' the more characters you will have to type.

If you think this is not a problem in your case then that's great and I would recommend using other criteria to choose a naming convention. In some case, e.g. in our team, we prefer identifiers that distinguish after as few keystrokes as possible.

Apart from that I would recommend to use the naming convention that makes your code most understandable for those working on the project. Have a conversation within your team. There is no right or wrong as such. Just conventions that work and conventions that work less.

Don't forget that good refactoring tools allow you to rename things as often as you like. So it's easy to experiment with different approaches.

  • 1
    +1. My reasoning would be the same, put the controlling verb first to make it easier to search/find/sort in the IDE.
    – pap
    Commented Jan 25, 2012 at 8:08
  • 1
    not only does intellisense work that way but so does a human scanning text, prefixes make your code less readable
    – jk.
    Commented Jan 25, 2012 at 11:10

I think you may wish to distinguish between capability and permission. While Serializable and CanSerialize imply that something is capable of being serialized, there are also permission issues (or perhaps lack of disk space) and you may need to consider MaySerialize. Leaving things at ~able removes the need to distinguish between can and may.

  • SerializableIfNotDiskFullAndIfNotPermissionMissing... Lol :)
    – Max
    Commented Jan 25, 2012 at 12:25

When subclassing/implementing interfaces I think the rule of thumb is that you should be able to say "B is a A" (where B implements A). It doesn't sound right to say:

A Document is a CanBePrinted

But it sounds right (or at least better) to say:

A Document is a Printable


I think that both grammar-wise and convention-wise Xable is better for names of interfaces, whereas IsX, CanX, DoesX are better for names of properties.

From MSDN:

"Do name Boolean properties with an affirmative phrase (CanSeek instead of CantSeek). Optionally, you can also prefix Boolean properties with Is, Can, or Has, but only where it adds value." http://msdn.microsoft.com/en-us/library/ms229012.aspx

  • +1 for the helpful link; I can never figure out what to name things
    – CamelBlues
    Commented Jan 25, 2012 at 20:59

In my opinion the "-able" variant is much more readable then your proposed "CanDoSomething" which imposes much more camel humps.

  • 1
    and Can- is more a method name Commented Jan 25, 2012 at 0:00
  • Property name - see MSDN. A method names should be "verbs or verb phrases". Besides, what is wrong with multiple humps? Commented Jan 25, 2012 at 13:28

In Scala, *Able is used for interfaces, but Can* is used for the type class pattern. Essentially, to be able to call certain methods, an implicit value of a certain type must exist in scope. The name of this type is sometimes prefixed with Can.

  • Can* is not a good name for a class. Quote from MSDN: "Do name classes, interfaces, and value types with nouns, noun phrases, or occasionally adjective phrases, using Pascal casing", link: msdn.microsoft.com/en-us/library/ms229040.aspx Good name for class would be Document, acceptable name would be Printable. Commented Jan 25, 2012 at 23:59
  • One example in the Scala language is the CanBuildFrom. This would be an adjective phrase. The use-case of this class is very different than that of other classes. Instances of this class are almost never constructed nor resolved by the client - rather, they are available in the scope for certain types. If they are available for a certain type, then methods involving that type which are marked to require this typeclass can be called. This exists to offer an extensibility mechanism more flexible than subtyping. See scala-lang.org/node/114.
    – axel22
    Commented Jan 26, 2012 at 9:17
  • I only recall using adjective phrases for mock classes implementing interfaces for unit tests - since they had no real role. Commented Jan 26, 2012 at 9:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.