原创 Dealing with unsightly code sores

Have you had those unsightly code sores? It’s not only the teenaged years that bring them on. All it takes is one developer with a bad code and suddenly everyone in the cubicle is hacking up nasty globs of code that’s sure to infect the entire repository. Often the culprit is a strain of MRSA (Madly Recursive unStructured Algorithms), which is especially common in teams working closely together in open spaces. MRSA has proven to be very resistant to even the most vigorous refactoring. To thwart its propagation it’s best to burn every instance found.

Here’s a few examples of code sores. I hope they’re not too contagious.
From the Linux kernel:



Don’t you just love those expressive variable names? There are no comments, of course, because those might give some vague hint as to the meaning of the function’s parameters.

From MQX:



The nice thing is that this misspelling will propagate into the Doxygen reports.

More from the Linux kernel:



No comments at all in or around the function, no description of what it does, nor is there the slightest hint what the arguments are.

I have seen the following general snippet too many times:



(No doubt it started as defining FIVE as 5 but successive attempts to fix the function led to this absurdity).

Apple’s SSL bug:



Had they followed MISRA rule 15.6 this threat, distributed to millions, could not have happened.

From a fellow who worked (briefly!) for me:



I dunno… is it right? You tell me! And what does “178” refer to?

Honesty is always the best policy:



The department of redundancy department:



One way to do a test:



An attempt to see if a number is odd:



Finally, this gem from the International Obfuscated C Coding Contest:



How is the health of your repository? Do you have favorite strains of code sores?