This site uses cookies to deliver our services and to show you relevant ads and job listings.
By using our site, you acknowledge that you have read and understand our Cookie Policy, Privacy Policy, and our Terms of Service.
Your use of Stack Overflow’s Products and Services, including the Stack Overflow Network, is subject to these policies and terms.

Join us in building a kind, collaborative learning community via our updated
Code of Conduct.

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?

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?

Document.IsPrintable is better than Document.CanBePrinted. As far as I can tell they used -able to avoid passive voice.
– Thanos PapathanasiouJan 25 '12 at 10:58

"Can be printed" seems like more proper English than "is printable".
– Danny VarodJan 25 '12 at 13:19

1

"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.
– Thanos PapathanasiouJan 25 '12 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.
– Kevin McCormickJan 25 '12 at 18:51

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:

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.

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.

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.
– Danny VarodJan 25 '12 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.
– axel22Jan 26 '12 at 9:17

I only recall using adjective phrases for mock classes implementing interfaces for unit tests - since they had no real role.
– Danny VarodJan 26 '12 at 9:45