This post originated from an RSS feed registered with Agile Buzz by Steven E. Newton. Original Post: Coding Pet Peeves Feed Title: Crater Moon Buzz Feed URL: http://www.cmdev.com/buzz/blosxom.cgi?flav=rss Feed Description: Views and experiences from the software world. Latest Agile Buzz Posts Latest Agile Buzz Posts by Steven E. Newton Latest Posts From Crater Moon Buzz

Eight little things I like to nitpick about in code. Mostly applicable to Java, but some are language-neutral.

1. Don't return null, return the NullObject. Checking for null in a returned value requires code that has nothing to do with the problem domain, and rarely does an API document what it means when a null is returned. My biggest beef is with methods that return a collection type return null. Just return the empty collection, and if it matters to the caller, check the size(). Often it's completely reasonable for code that does something with each element in a collection to do it zero times if the collection is empty.
2. Only use Java interfaces to define types, not as namespaces for globals. I've seen it suggested many times in questionable guides to create an interface as a dumping ground for public static values. Just Don't Do It. If the values have any meaning in the code, then they can be associated with the class that most closely operates with them. If the "class" is application configuration, then for Pete's sake create a configuration class with the ability to do things like pick up options from a configuration file, environment variables, or command-line arguments.
3. Override toString for all value types. It's simple enough to generate a readable representation of the properties of an object, and it's tremendously useful in monitoring, logging, and debugging. Far better than the default of the class name and a meaningless VM address.
4. Sort import statements, starting with java.*, then javax.*, then other 3rd party, then com.mydomain.*. Within a group, alphabetize.
5. Import down to the class name, unless you have more than 3 imports in a package, then you may import .*. Both this and the previous one are made much simpler by tools like Eclipse that automatically organize imports. Both are just the sort of neatness that any skilled professional should expect.
6. Vwls r mprtnt. Can't make heads or tails of that? Try this: "Vowels are important". Code with class, method, and variable names that abbreviate out all the vowels in identifiers quickly becomes and indecipherable mess. I see this most frequently in code that is closely associated with a relational database schema, because DBAs seem to love dropping all the vowels. Avoid the temptation to aggressively abbreviate as well -- an example being a proposal to abbreviate every word longer than 6 letters to 4 or less.
7. Never name a class Manager, Handler, or Data. Don't use the nouns "Object", "Manager", "Handler", or "Data" in class names. These words say nothing about the responsibility of the class, leading maintenance programmers to lump all kinds of irrelevant code into the class. Think instead about what the class is actually supposed to do and name it after that.
8. Abbreviations used mixed case in identifiers except where an overriding convention exists. e.g UmlIpParser is much more readable then UMLIPParser. For most of my recent employers, things like the company's initials, the project's code name, or the like, are examples of overriding convention. That's OK because generally all the developers involved know the convention.