I like to write code. It isn't the best way to solve every problem, but when it is the correct solution, I love to lose myself in code. Unfortunately, I seldom start from a clean slate. Most tasks involve correcting, extending or interacting with "other people's code."
This is why the post My Personal Pet Peeves I See in Other People’s Code by Ramon Leon was so much fun to read. I know where he's coming from, and I enjoyed his ho holds barred ranting. Sometimes you just gotta' let it out.
Still, I found myself arguing with Ramon in my head, "Hey, that's the way I write code. There ain't nothin' wrong with that!" Except, maybe, just maybe, there is, unless there isn't. My point is that while we all have opinions, it is a slippery slope to create too may concrete rules regarding style. Like the pirate's code, "they're more like guidelines."
So, what follows is my rant about Ramon's rant. If I don't argue with one of his points, then the reader should assume that I share it. Let's get started:
Ignorant Prefixing: I agree, except in cases where there is already a large code base using this style of naming. Then the rule for consistent style takes precedence.
Single Exit Points: I largely disagree. If a method is small enough to fit on a single screen, it is simple enough to have a single exit point. My one exception is to put something like the following at the top of a method:
If (noChanceInHell) return false
1000 Line Methods: I like the rule of not having to scroll when reading a method, although in practice, I break the rule as often as I comply. I wholly agree that the method name should be the only documentation needed about the purpose of a properly atomic method. In fact, more developers need to read chapter seven of Steve McConnell's excellent Code Complete to learn how to properly name routines.
Declaring Variables at the Top of a Method: I agree with the dictum to declare variables at the minimum scope, but when the minimum scope is the method, as opposed to a loop, then I like to see them declared, and initialized, if reasonable, at the top.
Error Code and Switch Statements: I like to return a bool from my methods. Many routines are just initializing some environment for the Main Event®. In such cases I will use the following structure:
LOCAL returnVal as Boolean returnVal = .F. DO CASE CASE NOT DoThis() CASE NOT DoThat() CASE NOT DoTheOther() OTHERWISE returnVal = .T. ENDCASE RETURN m.returnVal
LOCAL returnVal as Boolean
returnVal = .F.
DO CASE
CASE NOT DoThis()
CASE NOT DoThat()
CASE NOT DoTheOther()
OTHERWISE
returnVal = .T.
ENDCASE
RETURN m.returnVal
The reason I can do this, is that I program primarily in Visual FoxPro. You just can't do this in VB and C# switch statements. I am bitterly reminded of this every time I work in either of those languages.
I admit to ignorance of the Samurai Principle, and I can definitely see it's application, but there are many cases where I would rather check for a boolean result than do yet another try catch (YATC).
Overall, Mr. Leon's rant is well informed, entertaining, and educational. Highly recommended.
++Alan