Naming things is supposedly one of the two hard things in Computer Science. Here are some tips on naming for programmers.
Getters
In the Java world property accessors are traditionally prefixed with “get” and “set”, the Java bean convention:
person.getFirstName()
Code becomes more pleasant to read if you omit the “get” prefix:
person.firstName()
Of course, you can do this only if you don’t use a framework that depends on the convention to recognize properties via reflection (like some OR mappers, for example).
What about setters? I rarely write setters anymore. If you design your classes as immutable types you don’t need setters. Even if your class has mutable state you probably want to control this state via methods more specific to the domain of the problem. Also, the more you apply the tell, don’t ask principle the less you will find the need for getters.
Brevity vs. verbosity
There were times when it was common to see mass variable declarations like the following at the beginning of a function:
int i, j, k, l, m, n; float a, b, c, u, v, x, y, z;
Fortunately, times have changed for the better, and most programmers are aware that descriptive naming is important. However, some programmers do over-compensate. Length of an identifier is not a virtue by itself.
The Objective-C Cocoa framework is famous for overly long method names:
[array objectAtIndex:index]
Parts of Objective-C were inspired by Smalltalk. But in Smalltalk the same method is called at:
[array at:index]
This is a reasonably sufficient name for such a common functionality in programming.
Here’s another example: If the concept of a measurement station is very prevalent in the domain of your project then it’s ok to call instances just station instead of measurementStation if it’s the only kind of station in the domain.
Yes, the IDE does auto-complete long names. However, readability of the code decreases if the reader has to scan the same long-winded names over and over again:
MeasurementStation measurementStation = new MeasurementStation(); Measurement measurement = measurementStation.startMeasurement();
Often you can find names that are more to the point than longer descriptions, e.g. acquire instead of takeOwnershipOf. (source)
Hungarian notation and friends
The famous Hungarian notation is no longer in widespread use. However, there are variations of it that I would recommend against as well for the sake of readability. For example, bookList or bookArray can be simply books. Another variation would be conventions like myField or m_field for member variables. If you need these notations to determine the origin of a variable, then your scopes are probably too big, i.e. your methods, functions or classes are too long. Additionally, IDEs and editors for programmers can highlight these different scopes anyway. Other examples for unnecessary Hungarian-style notation are IFoo for interfaces, EFoo for enums or the infamous FooImpl.
Screaming constants
There is really no need for constants and enum values to constantly SCREAM at you and other readers. This SCREAMING_CASE convention has its origin in C, where constants used to be defined as macros when the const keyword wasn’t introduced yet, and it later found its way into other programming language ecosystems. Names for constants and enum values are not more important than other identifiers and don’t have to be spelled differently. Try it, you will enjoy the newfound silence in your code.
Conclusion
These are some tips to improve readability of code through better names. Some of these tips go against traditional conventions, so you should discuss them with your team before applying them. Consistency within an existing code base can definitely be more important. But if you have the freedom you should definitely give them a try.
Schneide Blog 