// Here there be magic. See datasheet for details; they explain it
// almost as well as I just did.
/* bad code */
To this day I do not know if this was a comment on the quality of the code that came after it, or if the developer was reprimanding the code.
In those times when you have to do it the Fast and Ugly (tm) way, it's nice to make a comment that you really don't like the code. It adds some humor, and lets the maintainer know that there is no emotional attachment to that section of code.
Of course, this is the first thing that everybody says. And since everybody says it, everybody thinks it must be true. But my experience has been that if you really want to do good work, it turns out not to be true (say) 80% of the time. So the next time you find yourself making a mess because you believe you "have to", you could try stopping and questioning that assumption. You might surprise yourself. How do you think I learned this? Certainly not by following what the majority of programmers believe.
Edit: Rather than using phrases like "the Right Way", I'd suggest toning things down and looking for a way. There are many ways. If you get in the habit of thinking there's only one, and it's capitalized and trademarked, the bar seems a lot higher than it really is.
Every once in awhile we're stuck at 3 days to code freeze (the product isn't a website, so we physically send out a DVD with our product on it, so quietly pushing out hotfixes isn't an option) and come across a bug that almost no user will care about that has two solutions:
1) Fix the problem the correct way. We don't know exactly what the correct way is, but we know it'll take a month or longer to code.
2) Apply some hack that gets it to work. This is usually something ugly and imperfect, but it's possible to do in 2 hours. We can tackle the problem again and attempt to get at a better solution.
If we don't ship on time, we lose piles of money. Guess which one we end up choosing ;)
Option 2 is fairly rarely chosen, but all it takes is for it to happen once or twice to have comments like the above in code, and forgotten.
Right... that whole Right Way (tm) thing is mostly tongue in cheek. It almost always refers to the way I want it done, and is a fairly flexible way.
I've made my living writing code for the last 12 years. How likely do you really think that is?
There's a deep streak of passivity among a lot of programmers. That's part of why they (we) tend to be downtrodden. The belief that one must do shoddy work unless "given the go-ahead" to do good work is as much a part of the problem as anything else.
Sometimes doing it The Right Way would necessitate a big refactoring of the supporting code or learning a concept in more depth and I can't afford all that overhead (which might break flow also).
Also, sometimes a far-reaching refactoring might be carried out in stages over a number of hours or days and to go from where you are to The Right Thing you'll have to pass through a number of less-than-optimal stages. But I always find it easier and faster to use an incremental approach where I accept suboptimal solutions, most of which will be quickly overwritten anyway than trying to do The Right Thing all at once.
While I'm sure it'd be nice to know all of the answers all the time, some of us mere mortals can continue to try to notify other people that extra attention should be paid to the code following those comments.
Sometimes I think I should make a macro out of //HACK: