Jeff, you scared my kids with that pic. now they’re turbo crying. thanks a lot.
That said, legitimate uses for GOTO are extremely rare and should always be well thought out (how else would I remember what I used it for and when I used it?).
Jon on June 19, 2008 08:48 AM
@Jon your solution was reasonable and correct. The next programmer will surely be happy that you didn’t use some half baked 70’s era feature from C such as setjmp/longjmp to solve the problem…
The problem of non maintainable code can only be solved if you take the onus away from the programmer who wrote it, who primarily, sees coding as his profession and not his hobby. Only a small percentage of programmers are truly passionate about what they do.
After all, 9 spoons of dirt + 1 spoon of pudding = 10 spoons of dirt.
It is impossible to get a decent percentage of the task force to comply with the comments rule for it to make a difference.
Make the computer do more (automation, dev environments, magic…). Make the coder do less.
I make videos to explain what my code does and then just put a YouTube link for the comment.
A little phoned in today, isn’t it? 
For writing maintainable code you need to have roghly this order of priorities:
good design well factored code good variable, function, and class names good comments (written at the level of intent concentrated around the most complex elements)
Ideally you want to aim for self-commenting code first, which is code that is so well designed, so well factored, and uses such descriptive naming that just reading it is sufficient for others to understand it. Where that fails and ONLY where that fails, typically where complex or kludgy design elements are unable to be avoided, write good comments describing the tricky bits. Write comments at the level of intent, don’t translate the code into English. Explain what the code is doing, for example: instead of saying “increment variable foo” say “keep track of number of retries”, even better, use a variable name descriptive enough so that you know what the use is.
Also, avoid over commenting your code with obvious comments that add no value. This is a huge waste of effort on both the part of the commenter and the part of the code reader / maintainer, because it distracts from commenting the parts of code that need it the most. More so, commenting alone is not sufficient. You can’t improve badly designed and badly written code much by expending great efforts to comment it, down that road is the way to turd polishing, sometimes refactoring (especially renaming) and rewriting is the only way to improve readability.
As always, “Software is a conversation. Be Polite.”
This applies to your source code as well as your interface, (source code being just another kind of interface).
I know courtesy isn’t in, especially if you’re younger, but no matter who you are, you’ll be on the receiving end of someone else’s work, or they yours. You can make it easy or hard. Your choice. Which would you like to deal with?
This makes me wonder about something. If maintenance is “99% of the coding work in this world” (which I don’t dispute), then why is 99% of the information and discusion in books, blogs, etc on the act of coding and designing and not supporting?
@Mark, because the software industry is still young, because the state of education does not mesh with the state of practice in this field, and because it’s easier and often more interesting to talk about designing. Consider that at most colleges the only route to software engineering is a computer science degree (not the same thing at all) and that it’s possible to obtain a 4 year college degree in such without ever touching a source control or bug tracking system and without ever writing or using automated tests. Consider that the number of software engineers who do their jobs well and represent the best practices of the industry is a tiny, tiny percentage of the number of people who earn a living coding.
Other people’s code is crap. My code becomes “other people’s code” within approx. two months.
Now you scared me so bad that I’m going to “go dark”. 
The uses of goto are not rare. Most programmers use them every day, and don’t even realize it. We’ve just given the generally accepted uses of GoTos special names to hide the fact that they are GoTos. Want an example, try the “Continue” keyword in .Net. In .Net 1.1, you didn’t have Continue in VB.Net. So, if you wanted to accomplish the same thing, you had to use a GoTo. All of a sudden, as soon as they created the continue keywork, it was alright to just around to the next iteration of a loop. But if you had to use a GoTo, then it was wrong? I highly disagree. Same thing goes for “Exit For/While” statements. They are essentially gotos, but nobody says that you shouldn’t use them.
There is no reason not to use GoTos, and sometimes you can make your code a lot more readable just by using them. Obviously you can use GoTo badly, and make spaghetti code using them. But the same could be said for any programming construct.
I’m not recognizing where the image is from - let us know so I can put the film on my Netflix queue!
Production programmers where I work simply copy forward programs from old jobs and add to them; it’s a nightmare, why don’t people like clean readable code???
Jeff must have taken that picture of me while I was programming one morning without my coffee!!
Now there’s a good idea for a post! What are some things programmers do that give them a boost (best practices, eh!) I.E. coffee, soda, chewing gum, listening to music, etc.
Patrick - you know the picture’s not real, right?
oups man the picture is quiet bad !!
I’m not really understanding your post or what it’s aiming to!
I think you have to review some of the articles your are publishing here
yeah! keep us motivated!