42 Tips to Writing __mainTainAble__ Code

Over the years, the Internet has given birth to hundreds of great programming practices. Unfortunately, there’s so many that it can be such a hassle to try to remember them all. Therefore, I’ve consolidated a list of 42 tips that will help your code be more maintainable. Follow these rules and you are sure to become a very successful programmer.

Naming Conventions

Be Overly General

Make frequent use of common and generic words that have zero descriptive properties like do, data, stuff, operate, method. For example, fuction1(), function2(), GetData(), find_it(), or OperateOnArgs() all make for great names.

Ignore All Established Language Conventions

Be a rebel. Ladies love a bad boy. When you see CreateFilesystem(), I see CreateFileSystem(). Even better, use a mix of both just to keep them guessing. This kind of practice is guaranteed to piss off everybody, thus preserving your rebel status.

Use Plenty of Underscores

Using lots of __underscores__ makes it clear that you’re really creative and artistic. You don’t want others to think you’re a boring ol’ frog on a log, so stand out from the crowd a little bit by making things fancy with lots of _under___score_s. The_more_underscores_the_better.

usE unconventionaL capitalizatioN

This is always good practice since it mimics the English language closely. In English, you always find words mashed up closely together but only with capitalization after the second word. poetsUseItAllTheTimeThatsWhyTheyGetAllTheLadies. If you encounter an A.C.R.O.N.Y.M., feel free to capitalize it at your pleasure. Have one function called generateHTML() and another called findHtml(). No big deal.

Never Use i in for-loops

It’s just not necessary. Use overly descriptive names like the_iterator, numberOfRows, or Counter. Use short identifiers like i for everything else.

Use Similar Names

Using descriptive names makes life boring for the reader. Instead, use names like command, commands, cmd, com, c to refer to five similar variables in the same function. This forces the reader to inspect your code with a magnifying glass to figure out what they’re for. Magnifying glasses are cool.

Hungarian Notation

Use it. Use it all the time.

Comments and Documentation

Only Document the Obvious

Be sure to sprinkle your code with lots of very explicit and obvious comments. Comments like /* This is an integer */ or /* End of file */ or /* Start of function */ are all great examples. Don’t worry about documenting the complex sections; leave it as an intellectual exercise to the reader.

Always Include the Filename

In case there’s a chance that the person reading your code might suddenly come down with a case of amnesia, always include a comment at the top of the file that has the filename in it. It happens all the time: you open up a file and as soon as you start reading it, you suddenly realize “Oh shit! What file is this again?” If they’re using Vim, they could just press Ctrl+G but chances are, they’re using Notepad and can’t see the top of the window.

It’s even more helpful to include a comment at the end of the file that says “End of file.” The reader could sit there at the last line for hours thinking “OMG! Where’s the end of this thing!?” You don’t want that so always make sure to tell them that the end of the file is the end of the file.

Don’t Update Comments

When you modify your code, just leave the same ol’ comments that were there before. Updating all your comments so that they’re accurate and helpful just takes too much time.

Good Design

Repeat Yourself

If it was good once, it’ll be good again, right? Therefore, always follow the WET philosophy: “Write Everything Twice”. For an extra bonus, follow the WETTT philosophy: “Write Everything Ten Thousand Times”.

Repeat Yourself

If it was good once, it’ll be good again, right? Therefore, always follow the WET philosophy: “Write Everything Twice”. For an extra bonus, follow the WETTT philosophy: “Write Everything Ten Thousand Times”.

Never Validate User Input

Trust is an important part of software development so always trust that users will input what you want them to. We’re all good people so there’s no reason anybody would input anything malicious.

Don’t Reuse, Just Copy/Paste

Don’t write modular or extensible code. Just use copy/paste instead. It’s much more time efficient. Promoting code re-use makes you look like a tree-hugging hippie that’s preachy about “recycling, man…you’ve got to recycle and reuse to save our precious earth, man…” No one will hire you as a hippie.

Provide Vague Error Messages

Don’t make your error messages useful in any way whatsoever. Simply acknowledging that the program failed is more than enough. Don’t bother the user with helpful details. Something like “an error has occurred” should suffice.

When You Fail, Fail Hard

Take everything down with you! Don’t try to recover and continue when an error occurs. It’s just not possible. Like the previous tip, provide a vague error message and then kill the entire program. Do lots of this:

send_http_request() or die("error");

Don’t Consolidate Literals

Programmers enjoy a good game of hide and seek so sprinkle those literal constants throughout your code. Don’t consolidate them into one place. That’s no fun! Stick a few at the beginning of the file, maybe a few after some random function definition, a couple more at the end of the file, and stick the rest in an unrelated header file.

Wield the Golden Hammer

Abraham Maslow got it right when he said “if the only tool you have is a hammer, treat everything as if it were a nail.” Always assume that your favorite solution is universally applicable. After all, you’re a programmer, you’re always gonna be right!

Switch Parameters Up a Bit

Never be consistent. That’s boring. If you’ve got a function called setPixel(int x, int y), make the next function getPixel(int y, int x) by reversing the parameters. This keeps your readers on the edge of their seat thinking, “Oh boy! What will happen next!?”

Global Variables are Your Friend

Exception handling is just too hard to understand. Instead, have your functions set a global variable like errno to indicate an error. That way, you have to check it in an if-statement after each function call. This adds a ton of redundant lines so it looks like you wrote a lot of code.

Keep Boat Anchors Around

Under no circumstance should you ever remove any obsolete, meaningless, or unusable code. Some losers refer to this as a “boat anchor” because they think it’s only use is to be thrown in the water as a moor. But they don’t realize that without an anchor, you’ll just drift away so that code is still important!

Optimize Prematurely

Donald Knuth one said that “premature optimization is the root of all evil.” Well that’s not true because everyone knows that money is the root of all evil! So feel free to sacrifice good design and perform optimization early in the development stage.

C/C++

Prefer void main() to int main()

This is a good practice that most programmers pick up early on. Don’t worry about the C standard: use void main() instead of int main(). The behavior of void main() is undefined and varies for different compilers. This will give the maintainer a nice little surprise after he’s had a dull and boring day.

Keep Pointers Hidden

One of easiest ways to ensure confusion is to hide your pointers with a typedef.

typedef int *MyPointer;

int an_iteger = 3;
MyPointer ptr;

ptr = &an_integer;

When the reader sees an_integer being assigned to ptr and that one is an int while the other is a user-defined type, you can effectively guarantee that perplexity will ensue. Always keep them guessing.

Use conio.h Instead of stdio.h

As I’ve made clear, you must always ignore any established standard. Since conio.h is not part of the ISO C standard, feel free to make heavy use of it. Better yet, make your program entirely dependent on it, failing horribly if it’s not present. The implementation of conio.h varies significantly between compilers so using it is a good way to break cross-platform compatibility.

Allocate Memory Using Both malloc() and new

Variety is a good thing. Sometimes programmers get tired of seeing the same old thing. Throw your readers a curve ball by making use of both malloc() and the new operator. No need to stick just one.

Be Secure With gets()

Another good habit that’s taught early on to new programmers is to use gets() instead of fgets(). Buffer overflows rarely occur in real life so the added security of fgets() is really unnecessary. Also, the “f” in fgets() stands for “fuck” so using it will surely offend the maintainer. Don’t be offensive.

Object-Oriented Programming

Sequential Coupling

Require that the methods of a given class be called in a very strict order. If they aren’t, remember to kill your program with a bang.

Some will say to use the template method pattern instead. This pattern demands that you define a skeleton algorithm in a method which defers some steps to the subclasses. Ignore this nonsense because skeletons are spooky.

Overuse Inheritance

To have just one class that has five field variables is bad practice. Instead, make a super class that only has one field and subclass it linearly four times. As an added bonus, place each class definition in a separate file.

Break Encapsulation

What the hell does that word mean anyway, right? Who cares. Use a good mix of public fields and accessor methods. Remember: secrets, secrets are no fun unless you share with everyone. If you’re trying to hide something, then you’re probably up to no good.

Worship the God Object

This rule is the holiest of holiest. If you do not follow it or even worse, mock it, then “peaceful” programmers will set fire to your country’s embassy, riot in the streets, and suicide bomb random infidels unrelated to you. That’s how important this rule is.

The holy book states that you must combine all functionality into a single all-knowing object: the God object. This object holds so much data and requires so many methods that it will become God-like. Any other objects must not communicate directly among themselves. Rather, all objects must rely solely on the God object for any program data. To break down a large problem into a set of smaller problems is considered a sin.

Use Constant Interfaces

In order to have convenient access to certain arbitrary constants, create a separate interface to define them in. An added benefit of this is that since the implemented interfaces of a class are part of its exported API, using constant interfaces exposes implementation details to the API which is always a great idea.

Circular Dependencies

Whenever possible, make sure that two or more of your classes are mutually recursive and directly depend on each other. For instance, give this a try:

class B;

class A {
  public:
    B *b;
};

class B {
  public:
    A *a;
};

int main() {
    A a;
    B b;
    a.b = &b;
    b.a = &a;
}

Contrary to popular belief, circular dependencies have a very positive effect on your programs. They completely prevent code re-use from being a possibility which we already know is bad practice. By making the reader go round and round trying to follow dependencies, you make him feel like he’s on a merry-go-round which were always fun as a kid.

And Everything Else

Ignore Compiler Warnings

They’re just warnings, right? Not errors so just leave them alone for someone else to fix.

Use Proprietary ASCII Extensions

One of the best things you can do for your program is to make it as incompatible as possible. Screw GNU and their blasphemous cross-platform compatibility philosophies. It’s heresy. Ensure that your program is restricted to one system and one system only by using MCS character encoding. The DEC VT220 is making a comeback. Mac OS Roman is another good choice.

Besides, letters like Ÿ and Œ will force readers to copy/paste them from somewhere else; another good practice discussed previously. People love to see .

Use Slang

Lingo. Jargon. Vernacular. Lexicon. Call it what it will. Using lots of slang is a great way to show what a hipster you truly are. Use function names like frobnicate_bits(), deadbeef(), or derpadize(). Don’t know what that last one is? Because I made it up! That’s how hip I am! Use places like UrbanDictionary.com as a reference.

Use a Variety of Numeric Bases

Give the reader a nice surprise by mixing in a bit of decimal, some octal, or hexadecimal into an array of integers:

int foo[9] = { 84, 3, 115, 0x0c, 5, 93, 017, 0x1077, 2 };

Comparing Values to Variables

Don’t do this:

if (life == 42)

Do this:

if (42 == life)

Comparing Floating Point Numbers

Those who claim that comparing floating point numbers can be inaccurate are just worry warts. You have 24 bits reserved for precision with the float type and 53 with double. That’s always going to be more than enough so there’s no need to worry about rounding errors.

Loooooooooooooooooooooooooooooong Lines

Forget about the 80-chacter rule.  Readers love to scroll on and on, well past everything else. A good programmer can usually get to about 500 characters.

Use Huge Indentation

Indent your lines a good 10-12 spaces. Using 3 or 4 spaces just makes you look lazy.

Use a Word Processor Instead of a Text Editor

Text editors like Vim and Emacs are so old. They’re too hard to understand and that Monospace font is so 1970. Get with the times and use a word processor like Microsoft Office. This way you can use those fancy variable width fonts like Comic Sans and Impact. As a bonus, use Microsoft’s proprietary .docx extension so that FOSS word processors like OpenOffice.org or LibreOffice screw up any special formatting.

Conclusion

Overall, your goal as a programmer is to be as ineffective and counter-productive as possible. Fortunately, many universities and projects are already prepping people for this. However, remembering all these great tips can be difficult so if there were three things you should remember the most, they would be:

  1. Be inconsistent.
  2. Never follow any general standard.
  3. Make life hard for everyone but yourself.
Advertisements

Comments are closed.