Today's rumination is not for the weak of heart. It's from the venerable C2 Wiki page Code For The Maintainer:
given the hiring policies in this place, it’s not so much a guideline as a rule.
I has very bad memory, and I don’t even remember codes I wrote 2 weeks ago. So I always design first, and try to make the structures simple, refactor the codes every half hour, review design every 1 or 2 days through reverse-engineering of UML tools, and supplement more comments. With simple and clear structures, and consistent design patterns for similar stuffs, I leave traces to myself for the future maintenance, because, in 2 week time, I will become a fresh programmer touching codes left by the other (actually me).
I wish some of the code I am maintaining was written by someone who followed that guideline. Sometimes I feel like becoming a violent psychopath and hunting someone down. Here is an example from today:
// Goto used to enhance simplicity and readability.
label GOTO_NEXT;
That is the original comment used to explain the use of the GOTO. I would think GOTO and Readability are mutually exclusive.
I’m an obsessive commenter in my own code, and almost every few lines of code comes with painfully detailed documentation on what kind of stuff the code does to each variable, so I think the psychopath code maintainer would still come after me: for commenting too much
Being a student I’ve never had the pleasure of dealing with real-world code, but maintaining what some students write in their projects brings me ever closer to slamming my own head through my monitor in despair. There’s a fine line between not being able to code well and having better things to do than to code well, and when some people write awful code just so they can leave early to watch TV it really bugs me.
Oh man, I so want to axe murder some of the people who wrote the god-awful code I have to maintain.
Jeff, why couldn’t you tell this to the person who wrote the shit I am currently working on?!
Heh, I first heard that advice today, but from a completely unrelated source (a guy giving a talk on typing systems for scripting languages at ITA software). I think it’s good advice: “Throwaway code” often isn’t and good documentation is key (especially in weakly-typed languages).
lol! This is perfect advice for myself as I prepare to hand off a little VBA ‘app’ I’ve been working on - I think I’ve commented to code and even supplied a semi-detailed design doc to go along with it. It’s not complex code, just a ton of it, mostly revolving around form validation.
Maybe next week I’ll get to take the training wheels off :S
I heard that quote first from the missed Kathy Sierra. I have an even better quote:
“Always code as if the person who ends up maintaining your code is going to be yourself, because at first it will always be”
Sorry Jim, just need to vent a bit
What up with everyone hating GOTOs? There’s a good reason why they are still here. Sometimes there just isn’t a nicer way to show that without taking a horrible lag-hit.
GOTOs are like OO, like functions, like everything in programming a tool that has it’s moment and use, rare indeed, but it’s still there. And believe me, I’ve seen spaghetti code built entirely with objects (can you imagine having to jump up and down in object hierarchies to see how a function works? WHY?)
Dijkstra talked about misuse of GOTOs to jump all over that code which made it impossible to read and didn’t even help for efficiency that much. Thinking that means GOTO should never be used is like thinking that the word like should never ever be used, not even on similes, because your english teacher said that people shouldn’t use like as much as they do.
Most of the code I have to work with is always written partly the old way, partly the new way, partly “I thought we got rid of all that”, and partly stuff that doesn’t do anything, but looks like it does, and basically a mess. I’m sure it was coded well in the first place, it just got blended together with “better” code.
A very good habit I was taught in university was to comment first, code later. What approaching a programming task, write out the comments for the code that you haven’t written yet. Helps you plan and you end up with detailed comments when you’re done.
Oh, boy! Is it just me or is everyone else also scared [insert vulgar slang for feces here] by this picture? If the world had more zombies, we’d all be better coders. Right, Jeff? 
I just got my first coding job, and it is maintaining and bug fixing. Its hard to get used to. I feel you.
Code is in maintenance from the second it’s checked-in, just like software is legacy the minute it’s in production.
Poor choice in picture my friend. I comment my code generously and coherently… not sure programmers that document well deserved this. 
Hell is other people’s code!
I choose to write code in such a way that the person who ends up maintaining the code believes that I am a psychopath and likely know where he lives. I achieve this by leaving threatening comments dispersed throughout the lines, as well as short bits of prose that details my abused childhood. This way I can pretend to do my job and after I’m gone he will be too afraid to tell anyone out of fear of me murdering his cat.