Better Software - September 2008 - (Page 17) Code Craft language. Idiomatic C code is quite a different beast class Foo from idiomatic Python. Listings 2a, 2b, and 2c il{ lustrate this. The Python code in listing 2b is idiomprivate: atic, but it could have been written like listing 2c, int thing; which is a more direct translation of the original C code. But it’s not idiomatic Python, and it doesn’t public: look or feel “right” as a consequence. // How would you name the ctor parameter? (Choose one) Non-idiomatic code sets our internal alarm bells Foo(int thing_in) : thing(thing_in) {} // (1) ringing, and rightly so. Idioms don’t just look nice, Foo(int t) : thing(t) {} // (2) they help us write safe, correct code, avoiding the Foo(int thing) : thing(thing) {} // (3) subtle pitfalls in the language. As in all heuristics, }; there is a body of collected wisdom contained in our programming language idioms that is perilous Listing 3 to ignore. Learning the specific idioms of a lanWhy does this simple naming issue matter? Well, it guage is a rite of passage and marks one’s mastery shouldn’t, until we combine the Meyers Minimal Member of the language. But important as they are, idioms are not sacred. Nor are Moniker Mechanism with another idiom. When constructing idioms fixed and immutable. Fashion doesn’t stand still; over a C++ class, you can initialize members in an initialization list. time tastes change. Some classic programming idioms have be- There’s another naming minefield here. Three of the options come dated. Hungarian Notation used to be a conventional, are enumerated in listing 3. They are only subtly different, are functionally equivalent, safe, and well-regarded practice. These days it is not merely passé but socially unacceptable—the modern equivalent of and each seems perfectly adequate. They are all common in modern C++ code. My workplace tends to adhere to idiom 3; software leprosy. it’s nicely symmetric and doesn’t introduce another unnecessary name into the code. Great. Idiom Idiocy Well, not quite. Idiom 3 has a hidden sting in its tail. Sure Sometimes the desire for beautiful, idiomatic code can trip us up. Well-intentioned use of idioms can bite you. Here’s a enough, in listing 3 it works just as advertised. But consider cautionary tale involving C++, which has particularly amusing what happens when you need some slightly more complex constructor logic, like listing 4. idioms. Recall the oft-cited Perl mantra, “There’s more than one Foo::Foo(int thing) : thing(thing) way to do it.” Well, C++ is like that for idioms—there’s always { more than one idiom for anything in C++, and you can bet if (thing == 1) that each has zealots who fervently believe that theirs is the thing = 2; Only Right Way To Do It. } One of the most basic, contentious, C++ idioms is the naming member variables. Many of these idioms involve the Listing 4 subtle incursion of Hungarian Notation. What is the value of the thing member when a Foo is conMany C++ programmers prefix member variables with an underscore. However, this is dubious practice as the language structed with the value 1? It’s 2, right? Well, no it isn’t. It’s standard reserves many identifier names beginning with an un- 1. “But how can that be?” I hear you ask. The name thing derscore. Class member variables are not actually one of the inside the constructor is bound to the constructor parameter, reserved cases, but this convention sails dangerously close to not to the class’ member variable. If you wanted to assign the the wind. Also common is the “m_” prefix, where “m” stands member, you must write: for member. I’ve even seen the disgustingly cute “m_member”. this->thing = 2; Euch! So what do the C++ experts do? Herb Sutter advocates a Otherwise, you’re just writing to a temporary variable that trailing underscore on member variable names. I have a personal dislike for this approach as the variable names read very will shortly be thrown away. This is a subtle but nasty way to introduce obscure bugs into your codebase. So there you have strangely. Scott Meyers is the sensible advocate of minimalism—he a collision of idioms. Some idioms are bad for you! How could you alleviate this problem? There are many writes the variable name, the whole name, and nothing but the name. To my mind, this approach makes sense. If you need any ways. For example, you could make the thing parameter extra indication of “member-ness,” you probably have code const in the constructor implementation. But for built-in that is too hard to read—your function has too many param- types passed by value, this isn’t idiomatic! How else could you eters or your class is too large. Fix that problem; don’t mask it avoid it? with silly variable names. www.StickyMinds.com SEPTEMBER 2008 BETTER SOFTWARE 17 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.