Introduction
I have noticed that certain individuals persist in writing good clear code that is well documented and easy to understand. So I thought it was about time to draw the main techniques of really really bad programming together into a single reference document. Remember the most important two things when writing truly awful software are to include as many subtle bugs as possible and to make the code really confusing so that it is hard to track those devious little bugs down. That way you can annoy both users and programmers to the maximum extent.
If you follow these simple rules, I promise you that you will never be far from users’ and other programmers’ thoughts.
1. Turn Off All Compiler Warnings
If you want to write really awful code, this is a great place to start. After all, you do not want that pesky compiler nagging you all day. All real programmers turn the warnings off completely.
2. Variables
Beginners should ensure that all variables are global. It is much easier to keep them all together in one place. As you become more advanced, add local variables with the same names as the globals, this will allow you to create subtle bugs with ease.
3. Functions
Avoid using functions wherever possible. It is much easier to write one single enormous long passage of code than going through the tiresome process of trying to divide it into separate functions and having the tedious job of passing parameters to them.
4. Cut and Paste is your Friend
Avoid using loops at all costs, it might take longer to cut and paste a section of code over and over, but it is well worth it when you consider the hours of fun for anyone checking each and every repeat of that code for subtle variations.
5. Variable Names for Beginners
You can have so much fun with variable names, try using the most meaningless name that you can think of, Fred is one of my personal favourites. But always include a smattering of semi meaningful names to keep other programmers guessing.
6. Advanced Variable Name Techniques
Ideally try to think of names that are very similar for as many entirely different variables as you can. Another great idea is to create two variables with the same name, but one ending in ‘1’ and the other in ‘l’, these are very easy to confuse at a glance and should get other programmers really guessing. Example: Slopel and Slope1. However, you can achieve the best results by occasionally using a label to mean the exact opposite of what people would assume, a classic example is to use the label Horizontal to mean Vertical and vice versa, that will really please any reader of your code, causing hours of amusement and pleasure as they try to unravel it.
7. Initialising
Play programmers bingo by allowing all of your variables to start with whatever value the memory had in from the last application. Great fun!
8. Bounds Checking
Allow the user to enter whatever values they want, if they enter a stupid value the program may crash. So? What do they expect?
9. Comments
It is best for beginners to avoid comments at all times, they waste valuable space and take ages to type. As you become more advanced, you can begin by adding comments which are entirely useless, because they state the obvious such as:
i++;
However, the most advanced comments will be as cryptic as possible, such as:
i++;
10. Layout
It takes real dedication to make your software layout truly bad. The most important thing is NEVER EVER be consistent. Whatever layout philosophy you choose, be sure to change it regularly. Advanced programmers should remember to use the same layout for long enough for any other programmer to become accustomed to it before changing to something entirely different.
11. Hungarian Notation
This is entirely optional, but for best results use a smattering of Hungarian Notation, thus annoying everyone (those who like it AND those who don't) and of course include a few incorrect uses just to make things more interesting.
12. Lastly Never Ever Test
Don't bother to test your code, just wait for people to complain, that way you will find out which are the most commonly occurring bugs first! Brilliant!
I have tried to cover most aspects of Really Really Bad Programming, but I am sure many of you can think of a few more. And don't be down hearted if after a while you start to slip into good habits, it doesn't take much effort to get back to those bad bad ways.
Disclaimer
I am not in any way suggesting that I never write bad code, nor am I suggesting that anyone else at CodeProject does. Just having a little fun!
