Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm bothering about a naming problem.

Given that I got an interface which got named Extension, and there will be lots of implementations, like Radio extension, video extension, music extension, etc.

First I have them all named with same suffix, "ext", e.g., RadioExt, VideoExt, etc. Moment later I realized the suffix was redundant since they all realized the same single interface Extension, and I should describe them in more literal manner. So I removed all suffixes.

However, there was debate among my colleagues, some argued that suffix was more clear and more readable. Actually, I think it's right at some extent. So I'm confused which naming is better.

Any opinions?

UPDATE
I'm targeting Android and iOS. As what you guys said, language support would be preferable. The fact that obj-c doesn't support namespace is really a pain. Furthermore, looks like prefixes in iOS programming is more official way to solve name collision, I'd have to apply this guide anyway for trying keeping consistent for all my ports.

share|improve this question
    
Lets just say prefixes are good if you're building a library that others will use. If it's you or your colleagues that are going to use it, it's really more of a formality than anything else. –  Neil Apr 19 '12 at 15:03
1  
If you need prefixes to prevent name collisions, use one prefix, something with your company name and the library name, and apply it library-wide. –  mjfgates Apr 20 '12 at 5:36

9 Answers 9

This is the a good case for using a namespace or package where applicable based on your language implementation.

my.company.domain.extensions.Radio

These are the problems that these language tools were designed to solve.

In any case, applying the tautology rule is a good one.

If you are saying the same thing over again in a useless way, they find a way to say it differently. In these cases, repeated Prefix and Suffix naming conventions is usually a smell.

Packages in Java, unfortunately are though of mapping directly 1:1 with directories on a filesystem. This is an unfortunate side-effect of the most ubiquitous classloader that loads classes from the filesystem. There are many other classloaders that don't load classes from a hierarchical storage system, but still use package names to disambiguate classes from one another. Assuming a storage implementation is a flawed assumption.

Packages are namespaces in Java, just called something else.

Namespaces in general are to disambiguate name collisions, regardless of language.

share|improve this answer
1  
I don't think that mandating that all subclasses are in a namespace which provides nothing else -- which would make the prefix/suffix redundant -- is a good idea. namespaces IMHO are for another kind of structuration. –  AProgrammer Apr 19 '12 at 15:22
5  
Using a prefix or suffix to namespace is a vestigial practice from C programming, where it makes a lot of sense. Having it as a language feature lets you use the prefix when it adds clarity and omit it when it doesn't. It's fascinating how many people have C-programmer habits and don't know why. Even if they've never used C, people pick up habits from a mentor who did. –  Karl Bielefeldt Apr 19 '12 at 15:28
    
This is not the purpose of namespaces. Namespaces are like directories, and we don't collect all the text files into a single directory. –  kevin cline Apr 19 '12 at 16:23
1  
@kevin: But we do collect, say, all our source files into a related directory. –  DeadMG Apr 19 '12 at 16:27
2  
@DeadMG: I don't. I put source files in directories related to the subsystem they are part of. And this is the problem with this idea. Namespaces are for classes that are logically related, not to mirror the inheritance hierarchy. –  JeremyP Apr 20 '12 at 10:24

If you are using a language that supports namespaces, I would suggest using a namespace to contain all implementations of Extension. Java doesn't support namespaces, but you could still structure your packages such that all implementations of Extension are packaged together.

share|improve this answer
2  
Do you consider namespaces and packages to be fundamentally different? I've always thought of them as mostly synonymous - two syntactically different ways to subdivide modules. –  Michael K Apr 19 '12 at 15:14
    
@MichaelK: They can be used for similar purposes but there are differences: In Java, there is a direct mapping between packages and directories in the filesystem. I don't know of any language that enforces similar rules on namespaces - in fact, I think I recall that C# allows multiple classes per file, and you could have each class in a different namespace. Also, I don't know of a language that has both namespaces and packages (though that doesn't mean such things don't exist - only that I haven't seen them). –  FrustratedWithFormsDesigner Apr 19 '12 at 15:22
    
Thank you for clarifying that. C# does has a far looser mapping between files and classes. I'm not sure whether that is good, bad, or neutral. –  Michael K Apr 19 '12 at 17:05
2  
I disagree. To me, packages/namespaces should be used for logically coherent areas of functionality, not to mirror the class hierarchy. For instance, if my DOM implementation contains a class that implements java.util.list that class should go in my package, not java.util.list.listimplementations (or whatever). –  JeremyP Apr 20 '12 at 10:20
1  
@FrustratedWithFormsDesigner the direct mapping between packages and namespaces is an unfortunate implementation detail of the filesystem classpath loaders. It doesn't have to be that way, and isn't that way in in .jar files or alternative classpath loaders. –  Jarrod Roberson Apr 22 '12 at 16:41

I going to go with an "It Depends" answer here, but first off, I'll bash a couple of concepts about as food for thought before getting into the real heart of the matter.

First off, I read an answer that made a passing mention of Hungarian notation. One of the reasons why I really dislike the use of the Hungarian notation is because the prefixes aren't always meaningful to the reader unless the reader is familiar with the same coding standard as the author. You can read a couple of letters as a prefix and assume that the author intended it to mean one thing, but really it means another. The fewer the letters used, the easier it is to misinterpret, and if you are adding letters to clarify the intention, then you might as well just spell the whole thing out. So, potentially meaningless abbreviations are out, and nice descriptive words are definitely the better option.

So you've got a nice descriptive word that you think should be a prefix or a suffix for your class, variable, object, or whatever. Do you use dollarAmount, or amountInDollars? or, does it even matter? Should this concept be limited to your variables/fields/properties/etc.., or should the classes be prefixed and suffixed also? Or perhaps the question you should be asking is: What value does this word provide within the context of the code?.

Compare the following:

var itemList = new List<Item>();
var listOfItems = new List<Item>();
var items = new List<Item>();

Is it worth stating that your items are a part of a list, or is it enough to infer that a variable represents a list if you use a plural name? If it were me, I'd use the simplest name with the fewest characters, because I like nice concise names that are descriptive enough for me to understand the meaning, even if it is inferred. I see no additional value making things any wordier, especially if I find myself dealing with a long line of code with a lot of words in it. Granted, there are those who might feel differently, however the point I am trying to make isn't to debate the finer nuances of the choices of names I have here, but to highlight that all things being equal, for the case I have shown you it isn't entirely necessary to use a prefix or a suffix in this case.

So how about the following cases?:

var items = new ItemArray();
var items = new ItemList();
var items = new ItemCollection();
var items = new Items();

In this example, there is one stand-out option that I personally wouldn't choose to use. While later in the code I might not care about my variable name beyond the fact that I have some sort of a list or a collection there, when it comes to the actual class type, the suffixes remind me that each class represents a different interface for the object that I am creating, and thus the suffixes provide me with valuable information about their compatibility with other classes that I may wish to invoke in a common way.

C# offers the ability to create static classes as containers for extension methods. That being the case, consider the following:

public static class CommonExtensions { ... }
public static class UnCommonExtensions { ... }

Is there any value here? Possibly not, because it isn't really clear which is the prefix and which is the suffix. I know that the class contains extension methods, but do I really need the word Extensions there? On the flip side, do the words Common and Uncommon offer any value? Should I have used a partial class instead, and just call the class in each partial class file Extensions? That's probably not a bad idea, but consider the following case:

public static class StringExtensions { ... }
public static class TextBoxExtensions { ... }
public static class ObjectExtensions { ... }

This is perhaps a little more descriptive and allows a nice logical grouping of the various extension methods being made available.

My last point is about standards and expectations. When a brand new system, language, or an API becomes available, people tend to follow whichever conventions were suggested by the developers of the product at the time it was released. Some APIs use Hungarian-styled prefixes as a means to distinguish different parts of the API, and to group classes where name spacing isn't available, or because there is a lot of history and there is an expectation to continue to present an interface in a certain way. Personally I don't see much wrong with this if there isn't a better way to do things. What about the Win32 API, with all of those Windows methods that end in Ex, and W and suchlike? Such suffixes probably meant something to the engineers that had created those methods at the time, but to those of us who never really learned what the prefixes actually stood for, they didn't really make a great deal of sense for the most part.

So, I feel that the answer really is that it depends on each specific situation. Short and essentially unclear abbreviations do not offer value, while descriptive words do. It is however a case of where and when the prefixes and suffixes are used, and how they might add value to the names you are giving the entities within your code. As always, strive for the simplest form that you can use. Be descriptive enough to get the message across while remaining concise enough to retain value in the name, and when you have decided how to go about naming things, do it systematically and consistently.

share|improve this answer

Prefixes and suffixes aren't inherently good or bad. They may be useful, or they may be unnecessary extra baggage, depending on the tools you use and your own point of view. For example, the convention in Objective-C is to name classes with a two- or three-letter prefix. This is mostly done to avoid name collisions, since Objective-C doesn't provide namespaces. Such prefixes wouldn't be necessary and are often avoided in C++.

On the other hand, the fact that Objective-C classes start with a short prefix like 'NS' or 'UI' or 'MK' makes them instantly identifiable as members of a particular framework. That's true of namespaces, too, if they're always specified with the class name; not so much in code that uses a using directive.

The fact that obj-c doesn't support namespace is really a pain.

How so? Unless you're writing frameworks for other people, all you really need to do is add a prefix to your class names. Or don't -- since every other framework that you're likely to use probably has a prefix, you can choose not to use one and probably still avoid collisions.

Furthermore, looks like prefixes in iOS programming is more official way to solve name collision, I'd have to apply this guide anyway for trying keeping consistent for all my ports.

As the two platforms are programmed using very different frameworks in different languages, it seems unlikely that you'll be sharing much code between them. So I don't see how a convention in Objective-C should significantly affect your Android projects.

share|improve this answer
    
For these two platforms, yes, there won't be much code shared between them. However, we decided that the same architecture, same naming rule, and same names for all interfaces would be applied to both implementations. Someday we'll even move to more platforms, so we must keep all implementations as consistent as possible, for maintenance reason. Perhaps I didn't present it clearly. –  fifth Apr 21 '12 at 17:00

Yes, it is reasonable to use suffixes for this purpose. I prefer suffixes because the word order more closely matches the usual English word order: "UnsafeDelivery" and "PriceInDollars" instead "deliveryUnsafe" and "dollarPrice". (Maybe "dollarPrice" sounds better in Hungarian.)

Do not use use namespaces or packages for this purpose. Namespaces should be coherent, with hierarchical (not circular) dependencies. We implement interfaces to deliver some feature, and the implementation belongs in the same namespace with the other classes delivering the same feature. As an extreme counterexample, you wouldn't collect up all the Runnable implementations into a runnables namespace. That would make as much sense as putting all the chairs in your house in the same room.

share|improve this answer
    
Beautiful analogy in the last sentence! –  Peter Hilton Sep 4 at 0:06

Joel Spolsky has endorsed Hungarian notion, which means to include the "kind" as part of the name. Note that the "kind" is not the same as the type; an integer could refer to the size, amount, identifier, etc. The purpose of including a the kind as part of the name is that I can immediately see whether something makes sense by looking at it:

dollarProfit = dollarAssets * (1.0 + pctReturn);  // reasonable
dollarProfit = pctReturn / pctDiscount;           // seems wrong

Of course, the astute reader will point-out that a language with strict typing can force adherence with the compiler, and indeed I personally believe that language support is preferable. Likewise, I also believe that variables and functions used together often belong within a namespace, which is also enforced by the compiler.

But if you have a language that lacks namespaces and strict typing, then perhaps a naming convention is in order. Many C libraries have a prefix notation for this very reason.

share|improve this answer
    
Compile-time validation of physical units is practical only in languages that and can generate new anonymous types automatically; otherwise the poor programmer has to define a type for every intermediate step in a computation. This can be done with C++ template functions, but is unmanageable in C#, Java, or Ada. –  kevin cline Apr 19 '12 at 15:34
    
@kevincline I had ML and Haskell in mind when I wrote that. –  chrisaycock Apr 19 '12 at 16:06
    
I did too. I was pretty sure that ML and Haskell had sufficiently powerful type systems, but couldn't find a quick answer. I need to learn me a Haskell. –  kevin cline Apr 19 '12 at 16:27
1  
The prefixes used in C and C++ libraries are there because those languages didn't have namespaces back in the day. They were used to keep library functions from name-colliding with client code. NOT an issue with any modern language, including C++ itself since 1995 or so. –  mjfgates Apr 20 '12 at 5:34

Prefixes or suffixes on your class names based on what they inherit from is a Bad Idea. If messes up intellisense-type features in IDEs; prefixes are worse for this, but suffixes aren't good. It makes the class names longer without helping clarity. We went through the simplest possible version of this back in the 90's with MFC, where every class ended up being named "CSomeThingOrOther;" that was quite bad enough.

Also, and you touched on this without explicating it, INTERFACES. What do you do if your class implements six different interfaces, put on half a dozen suffixes? What does the poor guy whose class inherits from yours do? What if you implement those interfaces purely for your own implementation, and don't intend your clients to know that? There's a five-gallon can of worms here that you don't want to open.

share|improve this answer

Depends. Would I suffix every control widget with the word Control? ButtonControl, TextControl, LabelControl? No. Use a package or namespace for such a grouping.

Would I suffix every kind of button with Button? RadioButton, ToggleButton, ImageButton …? Seems more reasonable, depending on usage. It may also be necessary (ImageButton) to actually describe the class accurately.

Would I suffix custom list types (i.e. implementing IList<T> in C#)? WidgetList, ObservableList, ImmutableList etc.? Almost certainly yes.

I can’t say for certain where I’d make the cut but the observations:

  • In the latter case (…List) the classes don’t logically belong in the same namespace, so this kind of grouping is out of the question.
  • Using the List suffix for those classes is natural and readable, and doesn’t get in the way.
  • Like in the case of the ImageButton, these class names would simply be incomplete without the suffix. OK, WidgetList could simply be Widgets. But that doesn’t work for the other types.
share|improve this answer

Names should be specific and yet not too long nor redundant. Something like Radio seems too wide for a class, even an interface, which will probably need to collaborate with other Radio related classes, some of which could be a better candidate for the unqualified name, but I think I'd tend to use qualified names for all of them. In that context, RadioExt seems reasonable.

Other have mentioned namespaces/packages. I'd tend to put all my Radio classes in a namespace, and the unqualified name Radio is a priori a good name for it. In that case you'd drop the Radio from the classes names. Leaving you with Ext or Extension, but such name should probably be reserved for Interface/base classes of an extension system provided by the package. So in that case I'd qualify the Ext with and indication of the provider of the extension system used.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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