Shameful Names
There’s a lots of good positive advice out there on how programmers should name classes, functions, variables and so on. To help balance things out are three half-baked tips on how not to name things.
- Don’t use
m_something
for member variables. Prefersomething
. If there’s any doubt about a variable’s scope your code blocks are too long. Besides, you can always qualify a member variable’s scope likethis->something
1. Utility
is a poor name for a module. And yes, the same goes forutilities
andutil
.- Don’t create a class called
SomethingManager
when plain oldSomething
would do. Why? Because “manager” is a long word and I’ll bet class instance names get abbreviated tosomething_mgr
. Because you’ll end up with source code with too many managers and not enough workers 2. And because eventually you’ll find yourself needing aSomethingManagerManager
.
One thing I like about Scheme is that you can use punctuation characters in identifiers. Question marks work well in predicates (rather than is_empty
, write empty?
), and an exclamation mark alerts readers to functions with side-effects (set!
, for example).
1 I can understand C++ programmers objecting to the explicit self
Python requires for member access. The objection becomes less easy to understand if they adopt the m_something
naming convention.
2 Now that I think about it, my real objection is to object oriented code-bloat. Too many managers = too deep a heirarchy = not enough action. Think of JBoss and shudder.