On Being Stupid 16
This was posted originally to a mailing list, but is reproduced here essentially unchanged by request of a friend.
I frequently see code (written by others) that is completely double-spaced, heavily commented, loaded with many abbreviated or meaningless variable names, and hundreds of lines long. In order to read the function and understand what it’s doing, poor Tim must wear out a mouse, skip comments, and track the variables on paper. A “smarter” programmer could just load it into his head, I suppose, but not the simpleton who writes this email.
I’m not smart enough to just read it from top to bottom and understand it. Sadly, when I read through and understand what in the heck the thxIniFvt variable is doing, I will forget it by the time I figure out the purpose(es) of pszVbt. I can spend all day, or even a few days to figure out a method, and that’s an admission of feeble-mindedness to be sure. I guess I’m not up to the level of some of the rapid hackers. That’s a limitation I face most days.
I find that I can sometimes understand a method like that only if I just delete all the blank lines and comments first, then reformat to break lines, then inline all methods with seven or more parameters, and then start renaming variables, extracting explanatory variables, and extracting explanatory methods. I may have to break the method into classes even. I guess I’m not one of the smart kids.
I used to be one of the smart kids. I once built a module so complex and fragile that nobody but me could figure out what to do with it. It was all tables and indicators, and stunningly clever. I am so ashamed that I wrote it. It was such a mistake that they eventually disabled it rather than field it in such a state. That was years ago, but so memorable to me. Other programmers said it was like the inside of a swiss watch, all delicate and perfectly balanced, and scary to mess with unless you first knew exactly what each part was doing, and why.
I would like to be faster than I am both mentally and in the sense of quickly producing code. I’d like to be a little less intimidated at the start of a project. .But I would not want those things if it meant building crap that people who are not appreciably more talented than myself would trip over every day. Instead, I sometimes wish I could teach the really fast, smart kids how to dumb down the code for the rest of us morons to read.
The funny thing is that dumbing code to my level doesn’t make it harder for the smart kids to use it, and sometimes allows a compiler to do a better job with it. I guess stupid isn’t so stupid after all.
Hear, hear! Most programming languages (with the noteable exception of Whitespace) are easy to read. It’s what programmers do with them that make them hard.
I frequently advertise for this program: Code Browser. It’s a small editor that allows you to fold code (by inserting tags in comments). This can work as a non-destructive kind of refactoring by folding large pieces of redundant code. I use it mostly for mind maps and task lists and the like but it is actually quite neat for program understanding as well.
Thanks Tim,
It’s nice to read something and having a deja-vu feeling. I’m glad i’m on the moron side :-)
Well said.
Great email. I’m going to save this one.
I have to admit to being a “smart” programmer once or twice too. Odd how the longer you’re in this field, the dumber you get. :-)
Great post! It is really a pitty how few dumb developers i get to work with!
“I find that I can …” Sounds like the first thing you start doing is refactoring. Do you use coverage tests?
thats how i often see other people’s code
and sometimes, code solutions i did long ago
I am trying to get into some habits though:
- as simple as necessary - as elegant as possible - complexity if an advantage exists, and only if the complexity is managable - using meaningful variables (many people hat concepts about this, like hungarian notation, but what they dont ackknowledge is that var x,y,z,a,b,c isnt giving you any hints in 5000 lines of code anyway… for vars which disappear quickly anyway, i try to use _ or tmp as a name…)
@joseph
I try to, but there is a chicken-and-egg problem. Some legacy code I see, I have no idea what it is supposed to do and therefore can’t test it.
This is doubly true if it happens to have a lot of conditionals, and if the objects it receives as arguments are global hubs or god classes or big honking wads of conditionals.
A lot of the legacy code I see is truly beyond my ability to internalize. I have to fix it enough to be able to read it and test it. This is why I lament being dumb.
@She/foo
My take on meaningful names is at http://tottinge.blogsome.com/meaningfulnames/ By those rules I would never name anything _, and would almost never name anything tmp.
As you say, in 5000 lines, even good variable names are not enough.
Wow, could one be more passive-aggressive and self-pitying? His points are valid (communicating semantics through program structure rather than comments is hardly a new idea), but I could be spared all the smarmy, “Oh, but surely I’m not as smart as you, dear reader.”
I love hungarian notation. I can see something like “pszPsz” and know that not only is it a pointer to a null terminated string, but every time I see it I’ll have the leading “psz” to remind me of that fact. Oh, wait, what data is stored in that string? Dunno, the name doesn’t give me that information, but I can remember it easily, right?
(Also, sarcasm is useful – I don’t enjoy that sort of thing at all.)
Deja vu indeed. I recently took over a system that had been written by an ex-fellow-employee who was very smart, but quite junior. It was his first large-scale group project. He had been (rightly) experimenting with several potential solutions for months and had settled on one that should have been straightforward but somehow it never quite came together.
After he left, I spent two days rearranging jumbled whitespace and renaming functions and variables without changing any of the logic. After that exercise, it was clear that 4 lines needed to be changed to fix 4 bugs. The system has worked fine ever since.
No doubt much of the benefit was that in order to properly rename everything I had to figure out what each part actually did, but most of it was because the code no longer traumatizing to read. It was not randomly jumbled, it no longer contained dead code or variables whose function had changed but whose name had not or swaths of duplicated code where only the constants (and the whitespace) differed, etc…
I’ve always thought that it takes a really smart person to write bad code. Complexity is sometimes worn like a badge of honor for those of us with engineering backgrounds. “If it’s easy, then why did I take 4 semesters of calculus?”
Good article indeed !
Great post. You’ll probably like my new device, then: Smell# http://claudiolassala.spaces.live.com/blog/cns354.entry
I too cannot stand garbage code anymore…