This post originated from an RSS feed registered with Python Buzz by Thomas Guest. Original Post: Shameful Names Feed Title: Word Aligned: Category Python Feed URL: http://feeds.feedburner.com/WordAlignedCategoryPython Feed Description: Dynamic languages in general. Python in particular. The adventures of a space sensitive programmer. Latest Python Buzz Posts Latest Python Buzz Posts by Thomas Guest Latest Posts From Word Aligned: Category Python

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. Prefer something. 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 like this->something^[1].
• Utility is a poor name for a module. And yes, the same goes for utilities and util.
• Don’t create a class called SomethingManager when plain old Something would do. Why? Because “manager” is a long word and I’ll bet class instance names get abbreviated to something_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 a SomethingManagerManager.

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.