Over time, some programming habits become so ingrained that they extend a language’s syntax into a personal dialect. For example, one gets so used to certain variable names that you know at a glance exactly what they mean, whenever they’re deployed. For example, I overuse rizlen to mean the length of a string or array returned from a function call. Results length, rizlen. I’ve been doing it so long, it’s become brainless habit.
What programming idioms have you incorporated into your style? Which ones do you regret? Are they a force for good? Do they hamper communications with other programmers? Let me know in the comments. I’m curious to find out how other people have (or have not) developed their own idiom.
I'm a big fan of self-documenting code and I'm a C++ programmer. I have a single header file with probably 100 "simple" typedefs in it for describing the meaning of a variable of a given type. E.g., `ul_length` indicates an unsigned long which stores the length of something. Whenever I need one I don't have yet, I just dump in that file. (Ok, not really "dump"; they're organized.)
And like every other C++ developer on the planet, I have my own personal library of resuable classes and functions. Many of my classes get the same typedef treatment (though not exorbitantly).
The net result: A *tremendously* more descriptive coding style. It makes my code look a hell of a lot more like, say, the pseudo-code I start with, and it facilitates highly expressive generic "algorithmic" programming and template design.
Generic != unexpressive. (At least, it shouldn't.)
I tend to have variables named "retVal" in many of my functions. It holds the return value.
I used to encode the type in the variable name, until someone asked me why I had a variable named "retch". ;-) [ Actually "retCh" ]
Mostly design patterns. I also tend to encode scope in variable names, though this is probably more pragmatic than ideal (due large code files that should be refactored). Also do not encode type in variables names when using C++ as it is pretty clear that this is not a good practice for a statically typed language.
Well I do almost all of my coding in functional languages like OCaml, so my big tendency is to see the world in terms of folds and unfolds. It makes the code nice and clean and compact, but can confuse people not familiar with the concepts.
A programming idiom I have is a hangup on curly brace style. (I use the "one true brace style" and so many don't seem to anymore. It's such a shameful thing to admit, but it was a factor in turning me against Visual Studio 2003.
Not sure if it counts as an idiom, but I am an advocate of not abbreviating any identifier names. I find that using fully descriptive names effectively can make the code read more like english and increase it's explicitness. An example of this would be a function that calculates the length of a string having 'return lengthOfString;' instead of 'return retVal;'. I try not to 'code' in computer terms unless I can't relate it to a more real world concept.
return lengthOfString;
Me? I'm more a return lengthor return len kind of girl. It's still obvious to the casual eye what it means, it's different enough to strlen() so the two wont get confused, and it avoids the so-long-and-Englishlike-that-it's-easy-to-start-introducing-typos thing. But that's just me.
I don't code a whole lot, except in Python as a hobby, so I haven't picked up any habits yet. However, as a "counter-idiom" I refuse to use extremely verbose variables, function names, etc.
For example, at my work several programmers use VB.NET. Looking over the shoulder of a programmer when I first arrived at the shop, I noticed method calls (or variable names, I don't know which) that had like 8 "."'s and 12 "mico-sentences"; something like "xmlDataReturn.FromMerge.CallingEditorScript.xml".
Now, I don't know if this is a feature of VB.NET since I've never used it, but it looks like a horrible way to do things, even if Visual Studio tries to complete your work for you. I prefer to make names that are short yet descriptive and maybe add a comment about what it does. That way you don't have to keep typing long names over and over but you can add extra information as needed.
I have a (mostly) set way of grouping Objective-C methods. I'll spare you the verbosity of describing it in deteail, but roughly it is: init methods, then accessors, then other class-specific methods, then action methods, then methods that are overrides or that satisfy a protocol, then private methods. This helps with information overload when a class has lots of methods.
Oh, and I use long lines of dashes to separate the sections of the file. I've considered using #pragma mark as well so that the sections are easier to navigate to in Xcode.
And I do similar method grouping in Java.
No argument or supplement discussion about it. The fact is that people do have their own style and that proves that every language is like a body that evolves through its speakers. That happens with the software language as well, not to mention the instant messaging one.