I have been an ACM member since 1972. Founded in 1947, the Association for Computing Machinery (yes the early focus was on hardware and software, I just call the organization ACM because it is focused on topics beyond just hardware). ACM focuses on improving the skills of information technology professionals and students.
One of the ACM publications I read is ACM’s queue magazine. Queue’s tagline is "tomorrow’s computing today". Queue magazine is focused on the problems and challenges presented by emerging and potentially disruptive technologies.
One of the monthly columns is Dear Kode Vicious. Readers write to Kode Vicious (actually George V. Neville-Neil) with questions and problems to solve. In the November 2004 issue, Kode breaks from the Dear Kode Vicious mode to write about his "Top Five Coding Peeves". He lists them as
- 5. Crappy comments - putting a comment like "set I to 1" before the statement i := 1;
4. Dangling else clauses
3. Magic numbers - constant values (instead of constant variables) used in array bounds declarations
2. Code dingleberries - "a huge chunk of commented out code"
1. Global variables - failure "to make a proper abstraction, add another global variable"
This got me thinking. Do I have any coding peeves? What coding examples really get my blood pressure rising? I remember back in 1973 when I was first out of college. I went to work at TRW as a real-time assembly language programmer on Data General Nova minicomputers. I ran into several coding practices that really drove me nuts (but at the same time actually made me laugh too). Those of you who might remember the Nova computer, it had an interesting architecture where every bit pattern was a valid instruction and every instruction could also be used as a bit pattern.
This everything can be code and data brings me to my first coding peeve from way back when - using a code sequence (that actually did work) also as a constant lookup table. I used to trace through programs looking for problems and would run into one of these sets of instructions and another section that indexed through the code to get bit patterns for an algorithm. I think I remember that a -1 was also a NEGCZ instruction that came in handy at times. Going along further with fun things you could do with the Nova architecture - you could write self modifying code that also would serve as a data storage area (we were usually squeezing programs into 4 or 8k of core memory).
Another set of coding peeves I ran into were assembly language statement labels that were meaningless to me, but memorable to the original programmer. Four especially interesting labeling schemes included 1) using all 50 United States names as labels in a piece of code, 2) using all of the programmers past girlfriend names as labels, 3) using drug names for labels, and 4) using "bad words" as labels. When I was a college student, a friend told me that the Stanford computer would flush card decks that contained program names, labels, or variables that were bad words. All you would get back was a print out telling you why your job was flushed and why you shouldn’t use bad words in your programs.
A category of coding peeves relates to where you should put the beginning and ending block marks in different programming languages. Should you put the open curly brace on the same line or the next line in C, C++, C#, and Java? Should you put the begin on the same line as a if, while, or repeat statement in Delphi/Pascal? I’ve read at least three or more indentation and open/close brace/keyword style guidelines.
A few quickies (maybe obvious, maybe not) - failure to use descriptive function and variable names, code with hard-coded paths, negatively named logical variables, and arbitrarily sticking with the 80 column code per line limit (what are you going to use that large LCD and plasma screen for?).
Does anyone out there have their own, I’m sure there are millions? Send them along to me either as comments to this blog entry, or you can email them to davidi.
{ 5 } Comments
You really shouldn’t get me <a href="http://www.bsdg.org/2004/11/more-coding-peeves.shtml">started</a>">http://www.bsdg.org/2004/11/more-coding-peeves.shtml">started</a>.
http://www.bsdg.org/2004/11/more-coding-peeves.shtml
Oops, I guess it doesn’t like anchor tags. I’ll remember that for next time. <g>
Implicit dependencies. It’s in my blog. Like Jim above, I’d like to say: don’t get me started…
Here’s mine. I’m working in a legacy code base that has jewels like this:
function TSomething.Doit : Integer;
begin
result := ERR_UNEXPECTED;
if FFoo then Exit;
if FBar then Exit;
if FMoby and not FBlurgh then Exit;
if FMumble then
begin
.
.
.
result := S_OK;
end;
end;
Mine is more of a design issue; I despise when object-oriented purists assume that they’re deities and insist on making all member variables and member functions "private". By doing so, you are assuming that you are all-knowing and that you are fully aware of every potential way your class might be derived and used in the future. I can’t tell you how many times I wanted to tweak how something was done in the base class but couldn’t because all the "goods" were hidden away by an over-zealous coder who thought they were protecting me from myself. Here’s a hint. Use ‘protected’. Assume that if I AM you (referring to what role an inherited class plays with regards to the base class), that I’m either smart enough to know what I’m doing or crazy enough to take on the risks.
Post a Comment