Slashdot Mirror
How To Write Unmaintainable Code
/ writes "Roedy Green of Canadian Mind Products has written an essay entitled "How To Write Unmaintainable Code". Following his 54 tips, you too can guarantee job-security by becoming irreplaceable. If that weren't good enough, it's even available in Spanish. "
Now I write good code. Maintainable. Well commented. Meaningful variable names. Nothing fancy. I know what it's like to revisit my code ten years later.
There is a problem, though.
Nobody else seems able to maintain my code. They just can't understand it.
Despite high-level pseudo-code algorithm descriptions, threaded comments, good up to date written documentation, they just can't wrap their tiny little heads around how I do things.
I can go back to something I wrote 15 years ago and fix problems without generating new ones. My code is robust enought that I can shovel out a few thousand lines and jam in another 10,000 lines, test it for a day or two and release it... and get no bug reports for another 5 years. I consider this to be maintainable code!
Go ahead... break all the rules suggested in the article. You may still produce code that other, lesser programmers simply can't cope with. The code is an expression from the mind of the person who wrote it... and sometimes writing to the lowest common denominator simply isn't possible.
And then they blame you for writing unmaintainable code.
-Eldurbarn
- Put all your code into a single function. (I've seen functions over 2000 lines in length.) After all, those nasty functions generate overhead on each call, and you want your code to be efficient right?
- Use hungarian notation for variables. Then instead of the overly verbose you have the nice and compact
- Don't indent your code uniformly. (This is a variation on #11 from the article.) Use Windoze or vi editors, with non-standard tab widths, for tabbing and indenting, which means that no one can see your code indented properly unless they use the same tools you use, with your same editing configuration.
- If using C or C++, don't use memory analysis tools like Purify, or its open source equivalents. After all, if you find your bugs too quickly, you might lose your job.
- On large projects with several programmers, make sure you change global header files that cause everybody else's code to break but yours. Do this late in the afternoon, so all hell breaks loose breaks right before people are going home, or late at night, so that everybody comes in fresh the next morning and wonders what the hell happened to the code that compiled perfectly when they left the day before. Either way, make sure you are not around when they find out! Otherwise you spare them the joy of figuring out what you changed, and why.
- Do really stupid stuff that you were taught from day 1 not to do, but everyone seems to do anyway: don't check for NULL, fix array sizes where you hardcode the max size everywhere, don't check for invalid or oversized input, etc.
- Use preprocessor macros. Lots of them. (I was actually on a project where someone suggested using cpp to define macros. For Java. Absolutely brilliant!) The key is to use a single macro for multiple statements, in effect using macros as function calls. Example: Notice the "hidden" use of external variables and functions. Remember, you want to avoid those expensive subroutine calls! And think of the joys of setting breakpoints and stepping through a debugger on that code!
- Don't use source code control. Or, use it, but never unlock or checkin your files. Feel free to steal locks on others, though.
And finally, one of my favorites, for all the young and aspiring hacker types out there:BONUS: With compact hungarian notation, you can become even more descriptive! So really the above becomes:
So much more descriptive information, all in the same amount of space. I've been on projects using this, and the sheer of joy of it cannot be accurately described in words.BONUS: Write extremely long lines of code, well over 80 characters per line.
BONUS: Do this right before a major deadline.
BONUS: Don't use the all uppercase convention in macro names; use the same naming convention as function calls. It's even more fun to debug when you have to spend time actually figuring out do_stuff() isn't even a function call!
MORE BONUS: Nest macro calls. Use the naming convention above.
EVEN MORE BONUS: Use macro calls as variables. Make sure the expanded macro makes function calls. Or uses other macros.
- Write code only for yourself. Assume no one will ever need to figure out how to use your code without poring through it in painstaking detail. Do not make it easy to use, interface with other code, or even compile. Include 30 caveats that would take you only a few minutes to fix, but you're just too lazy to. In other words, write as if no one will every look at or use your code, yet release it to everyone to look at and use. Defend your laziness, which is causing thousands of lost hours of work to others, by uttering useless and stupid "cool hacker" mantras like "Real Programmers don't write documentation" and "If it was hard to write, it should be hard to understand."
Phew. That little tirade made me feel good.----------
In a real emergency, we would have all fled in terror, and you would not have been notified.
Good evening class. I'll be your exorcizer of idealistic nonsense for the evening. Just call me Bruce.
Now... preach all you like about how hard it'll be for the next guy, but like customizing my car or my house... I don't worry about what the next guy will think about my code. Do you care if the next owner of your car might not like it if you paint it red? Do you care if the next owner of your house disapproves of you converting the garage into a pool room? Heck no. Well, it's the same with me. I work for my own benefit, pleasure, and satisfaction. And to do that I've gotta do the best damn job I can at work. Otherwise; no money; no fun. This philosophy is reflected in my code as well. I've cranked out some godawful nasty kluges that confuse even me when I look at them a year later... but I got the job done, by the deadline, while some of the junior programmers seem to wanna rewrite everything to make it clean rather than break the nice design of the code. Feh. That's why they're junior programmers. They Just Don't Get It (tm). Their plan would send the company under. Stuff's gotta be done now and ship next week or there's no profit for the company and no salary for the programmers. Junior programmers always seem to be self-delusional with grand plans of redesigning everything. It never happens. Requirements change *ALL* *THE* *TIME*. Any static plan is doomed to fail. Once they realize this they make the transition from dreaming programmer to master hacker... or they can't keep up with the pace of real world business and disappear. You've got to be able to deal with old crusty projects written by long gone staff with more bags and bells and whistles and ornaments hanging off the side and kluged into it, written by more people you've never met, and you've got to be able to quickly and successfully hack more stuff into it and hack it and rehack it and change old stuff and keep it all running. Successful, on the fly, under the gun kluging is what distunguishes the Senior Programmers driving the big smog polluting, shitty mileage, comfy luxury cars into the front, covered parking space and getting the stock options and profit sharing and 401Ks from the idealist larval dreamers driving their small car becuase "it's good for the environment". Self-spirit-lifting-and-self justification-bull. Given the Big Bucks, you'd ditch that Civic for a gas guzzling SUV or Corvette too. So forget the dream. Getting a clean slate to build on is a rare event. 99% of all programming jobs you'll ever be hired for will be holding together someone else's code. Insane deadlines, getting the jump on the competition mid project, reamping of requirements (many times over), decision reversals by management, your latest self-gratifying achievement being abandoned and dumped because it's not needed anymore. These will all eventually break your spirits. On the plus side, once you realize this, you will be able to succeed and advance within your company or find it easy to get hired at the next comapny. because quick thinking master hackers who can do the magic again and again despite laying waste to the original vision and still keep on kluging and have it keep on working are what companies want. If you can do this, you will succeed. Getting back to the original question... do I obfuscate my code? It may certainly look that way to the idealist, but not so. True brilliance is messy. Remember the famous comment preceeding the task switching code in Unix... /* You are not expected to understand this */ But if you can, you'll be a god... or root... what's the difference again? Anyway, class dismissed.