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.

Suppose I have an abstract class named Task.

Is there a standard or convention that would suggest I should name it AbstractTask instead?

share|improve this question

closed as primarily opinion-based by gnat, Martijn Pieters, MichaelT, Dan Pichelman, jwenting Oct 6 at 7:00

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Naming conventions listed here: oracle.com/technetwork/java/codeconventions-135099.html suggest no, though this link: stackoverflow.com/questions/1006332/… says you could and it wouldn't be a terrible thing if you did. –  FrustratedWithFormsDesigner Jun 13 '12 at 18:35
    
In C# the standard convention is to Suffix with '*Base'. –  Den Oct 3 at 10:06

13 Answers 13

up vote 14 down vote accepted

According to Bloch's Effective Java (Item 18) the Abstract prefix is a convention used in a special case.

You can combine the virtues of interfaces and abstract classes by providing an abstract skeletal implementation class to go with each nontrivial interface that you export. ... By convention, skeletal implementations are called AbstractInterface, where Interface is the name of the interface they implement.

But Bloch also points out that the name SkeletalInterface would have made sense, but concludes that

the Abstract convention is now firmly established.

As other answers have pointed out, in general there is no reason to apply this naming convention to all abstract classes.

share|improve this answer

There is no convention. It's all about what will help you, as the developer, code faster and better, and help others understand your code.

Ask the people who will be seeing and maintaining the code. What would they rather see? What will make it easier on them? Then name it based on what they'd like.

On another note, Code Conventions for the Java Programming Language: 9. Naming Conventions suggests no requirement:

Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).

share|improve this answer
    
@gnat Thanks for the edit :-) –  Dynamic Jun 13 '12 at 18:44
    
+1 for providing a reference –  Gary Rowe Jun 14 '12 at 12:16

No. Intellisense will trivially tell me if it is abstract, so you're just violating DRY here.

share|improve this answer
14  
-1 Adding abstract to a class name doesn't violate DRY, and not everybody uses intellisence. For example, what do you do if you are reading the code on a web page, or if it is part of a patch you are looking at in a plain text editor or an external diff tool? –  Bryan Oakley Jun 13 '12 at 22:39
8  
@Bryan: Of course it violates DRY. abstract class AbstractName? Clearly has "abstract" twice. And if you are not using Intellisense, then that's your problem, everybody else uses sane tools to view code. –  DeadMG Jun 14 '12 at 7:12
7  
"Everbody"? Most of the people I know use emacs and vi, with a few who use eclipse. Saying something is "your problem" isn't exactly the definition of teamwork. My poorlyl made point was, you can't just set a blanket rule and say that's how it's done. Different teams have different requirements, and not everybody needs assistance with intellisense. Plus, as I said, there are many times when you're looking at code in some tool other than your primary editor or IDE. –  Bryan Oakley Jun 14 '12 at 10:55
    
+1 definitely violates DRY. Relying on Intellisense is a bit strong, but anyone using the base class should at least look to see what they're extending as part of SOLID. –  Gary Rowe Jun 14 '12 at 12:21
3  
@BryanOakley why not also put public and final as well? A class name would then look like PublicAbstractPersonThatImplementsInterfaceHuman. Hmm, not quite sure that's good. But I agree, there is nothing such as a universal convention -- use whatever increases the team's collective productivity. –  Monster Truck Jun 15 '12 at 8:01

This is somewhat a matter of preference (but borderline bad practice), but most people don't like seeing part of the qualifiers in the name of the class.

Most IDE's will make that information easily available to you anyway, so putting it in the name isn't necessary, and it will be cleaner to just omit it. It's reminiscent of hungarian notation for variable naming, and that's certainly considered bad form now-a-days. I recommend simply calling it Task.

share|improve this answer

In .NET, the use of "Base" as a suffix to denote an abstract base class is often seen. I would defer to the other answers as to whether this is common practice in Java.

share|improve this answer
1  
+1 for "Base" and "Impl" suffixes. They make a structural point (an abstract class will be the base for something). –  vski Jun 13 '12 at 20:18
4  
@vski: no, I strongly disagree: they're a useless pain in the butt. It's generally perfectly fine to name your interface or base classe with a generic name describe the interface, and your concrete implementation with more expliit names. –  haylem Jun 13 '12 at 20:56
2  
I tend to use ...Base for a base class behind an interface. The good name is already taken by the interface, and the base class isn't used anyway by client code. –  starblue Jun 13 '12 at 21:30
1  
@Haylem many java design patterns use interfaces with only one expected implementation. Impl is a very useful suffix in these cases. –  funkybro Jun 13 '12 at 23:31
    
Regarding the use of Impl, see Default vs Impl - stay away from Impl! Using Base as a suffix (e.g. TaskBase) implies that a base class is a pattern rather than a language construct. –  Gary Rowe Jun 14 '12 at 12:18

A good rule of thumb is to not include properties in a name that are obvious from the syntax. Since in Java, you need to mark an abstract class with the aptly named abstract keyword, I would not include it in the name. In C++, for example, the case is not so clear cut, but at least the compiler will tell you when you incorrectly used an abstract class. In something like Python again, explicitly naming an abstract class as such is not a bad idea.

The usual exception to the rule is when the name is ambiguous. If, for whatever reason, there is a concrete subclass Task (in other examples, this may be more sensible, but whatever), then sure, use AbstractTask.

share|improve this answer

In my opinion, an entity's name shouldn't convey information about its type structure, but about its semantics. So it doesn't make sense to define your class as "AbstractSomething" if the abstraction is not part of its runtime goal. That it is a base abstract class is visible for the programmer, and doesn't need to be reflected in the name.

However, if makes perfect to call an implementation of an abstract factory an AbstractFactory, because that does relate to the class's intent.

In general, favor naming convention that help to convey the most information about the goal of your class.

Similarly, stay clear from SomethingImpl. We don't care that it's an implementation and not a base class. If your class hierarchy is designed properly for inheritance, then someone could inherit from it. Surely there would be no value in them adding more "Impl" suffixes or other artifacts. There's also no value in adding an "Interface" suffix or "I" prefix.

Consider:

IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl

As opposed to:

Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
                                   <-- Ferrari
                                   <-- Trabi

I prefer the latter by far.


This, in some respect, similar to the blatant misuse of the Hungarian Notation that latter gave it its bad rep, as people wrongly started to interpret it as requiring developers to prefix their variables with an indicator of the variable's type. While this can sometimes have its uses (mostly if you are lazy to look up the type's definition), it's mostly useless. Simonyi's original idea with the Hungarian Notation was to use it as a mnemonic to remind the developer of the entity's capabilities, not of its type.

share|improve this answer
protected abstract SomeClass { }

This tells me this is an Abstract class. Adding a prefix is a tautology and anti-pattern and not appropriate in most cases, see the link where it talks about package local being an exception for example.

In most cases Abstract classes shouldn't be part of a public facing API, if it is there should really be a good reason and a good reason should provide an obviously good name other than AbstractSomeClass.

In most cases if you can't come up with a more descriptive name you probably need to do some redesign.

share|improve this answer

I'm not a Java developer (INAJD?) and don't know the standard nomenclature for such things, but I think Task sounds abstract enough that it can stand alone as-is.

share|improve this answer
    
RE: Base Suffix: stackoverflow.com/a/429494/1782 –  jmfsg Jun 13 '12 at 19:03

What if you want to write an abstract AbstractSyntaxTree class? Or perhaps just an abstract SyntaxTree?

It's not conventional and it can easily confuse people.

share|improve this answer

My five cents, Probably you'll have implementations of that abstract class and they will be named 'SomeSpecificTask', 'TaskWithBubbles', 'StrangeTask' etc. So there won't be a name clash between your abstract 'Task' and them.

Additionally, 'abstract' word is about language syntax, not business domain entities, so I'd prefer not to use it as a part of the name.

On the other hand, in one answer here I saw excerpt from J.Bloch Effective Java which says that using 'abstract' as a part of a name is a well-established practice. It may be so. But anyway in official java code conventions there is nothing about that.

share|improve this answer

If you work in a team, then entire team must decide whether you should prefix abstract classes with "Abstract".

If you work on your own, then it's entirely up to you, not me or anybody else on this site.

share|improve this answer

I have done this. I did add 'Abstract' as prefix to my abstract class named AbstractOperation. The reason I did this was there was another package that had a non abstract class named Operation, and It helped my team and the programmers who took over later in avoiding any confusion between the two.

share|improve this answer

protected by gnat Oct 3 at 12:40

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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