How to Write Unmaintainable Code (1999)
📰 Hacker News (AI)
Tips on how to write unmaintainable code, including lying in comments and avoiding encapsulation
Action Steps
- Avoid keeping comments up-to-date with the code
- Use unclear method names and avoid documenting the overall purpose of a package or method
- Avoid encapsulation and use cut/paste/clone/modify instead of reusable modules
- Remove white space and comments on variables to make the code harder to understand
Who Needs to Know This
Software engineers and developers can benefit from understanding these anti-patterns to avoid writing difficult-to-maintain code and to improve their overall coding skills. Team leads and managers can also use this to educate their team members on best practices
Key Insight
💡 Writing unmaintainable code can have serious consequences, including making it difficult for others to understand and modify the code, leading to increased maintenance costs and decreased productivity
Share This
💡 Bad coding practices can lead to a lifetime of employment... for you, but headaches for others!
Key Takeaways
Tips on how to write unmaintainable code, including lying in comments and avoiding encapsulation
Full Article
Published Time: Fri, 19 Nov 1999 10:28:46 GMT
# How To Write Unmaintainable Code
# How To Write Unmaintainable Code
[](https://www.doc.ic.ac.uk/~susan/475/index.html) Last updated Thursday, 18-Nov-1999 20:27:28 PDT by [Roedy Green](https://www.doc.ic.ac.uk/~susan/475/index.html#CONTACT) ©1997-1999 Canadian Mind Products.
This essay is also available in [Spanish](http://web.jet.es/jrevusky/rollo.html).
In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee **yourself** a lifetime of employment, since no one but you has a hope in hell of maintaining the code.
## General Principles
To foil the maintenance programmer, you have to understand how he thinks. He has your giant program. He has no time to read it all, much less understand it. He wants to rapidly find the place to make his change, make it and get out and have no unexpected side effects from the change.
He views your code through a tube taken from the centre of a roll of toilet paper. He can only see a tiny piece of your program at a time. You want to make sure he can never get the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely **ignore** anything.
## Specific Techniques
1. Lie in the comments. You don't have to actively lie, just fail to keep comments as up to date with the code.
2. Pepper the code with comments like /* add 1 to i */ however, never document wooly stuff like the overall purpose of the package or method.
3. Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.
4. Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically.
5. In the interests of efficiency, avoid encapsulation. Callers of a method need all the external clues they can get to remind them how the method works inside.
6. If, for example, you were writing an airline reservation system, make sure there are at least 25 places in the code that need to be modified if you were to add another airline. Never document where they are. People who come after you have no business modifying your code without thoroughly understanding every line of it.
7. In the name of efficiency, use cut/paste/clone/modify. This works much faster than using many small reusable modules.
8. **Never never**put a comment on a variable. Facts about how the variable is used, its bounds, its legal values, its implied/displayed number of decimal points, its units of measure, its display format, its data entry rules (e.g. total fill, must enter), when its value can be trusted etc. should be gleaned from the procedural code. If your boss forces you to write comments, lard method bodies with them, but never comment a variable, not even a temporary!
9. Try to pack as much as possible into a single line. This saves the overhead of temporary variables, and makes source files shorter by eliminating new line characters and white space. Tip: remove all white space around operators. Good programmers can often hit the 255 character line length limit imposed by some editors. The bonus of long lines is that programmers who cannot read 6 point type must scroll to view them.
10. Cd wrttn wtht vwls s mch trsr. When using abbreviations inside variable or method names, break the boredom with several variants for the same word, and even spell it out longhand once in while. This helps defeat those lazy bums who use text sea
# How To Write Unmaintainable Code
# How To Write Unmaintainable Code
[](https://www.doc.ic.ac.uk/~susan/475/index.html) Last updated Thursday, 18-Nov-1999 20:27:28 PDT by [Roedy Green](https://www.doc.ic.ac.uk/~susan/475/index.html#CONTACT) ©1997-1999 Canadian Mind Products.
This essay is also available in [Spanish](http://web.jet.es/jrevusky/rollo.html).
In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee **yourself** a lifetime of employment, since no one but you has a hope in hell of maintaining the code.
## General Principles
To foil the maintenance programmer, you have to understand how he thinks. He has your giant program. He has no time to read it all, much less understand it. He wants to rapidly find the place to make his change, make it and get out and have no unexpected side effects from the change.
He views your code through a tube taken from the centre of a roll of toilet paper. He can only see a tiny piece of your program at a time. You want to make sure he can never get the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely **ignore** anything.
## Specific Techniques
1. Lie in the comments. You don't have to actively lie, just fail to keep comments as up to date with the code.
2. Pepper the code with comments like /* add 1 to i */ however, never document wooly stuff like the overall purpose of the package or method.
3. Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.
4. Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically.
5. In the interests of efficiency, avoid encapsulation. Callers of a method need all the external clues they can get to remind them how the method works inside.
6. If, for example, you were writing an airline reservation system, make sure there are at least 25 places in the code that need to be modified if you were to add another airline. Never document where they are. People who come after you have no business modifying your code without thoroughly understanding every line of it.
7. In the name of efficiency, use cut/paste/clone/modify. This works much faster than using many small reusable modules.
8. **Never never**put a comment on a variable. Facts about how the variable is used, its bounds, its legal values, its implied/displayed number of decimal points, its units of measure, its display format, its data entry rules (e.g. total fill, must enter), when its value can be trusted etc. should be gleaned from the procedural code. If your boss forces you to write comments, lard method bodies with them, but never comment a variable, not even a temporary!
9. Try to pack as much as possible into a single line. This saves the overhead of temporary variables, and makes source files shorter by eliminating new line characters and white space. Tip: remove all white space around operators. Good programmers can often hit the 255 character line length limit imposed by some editors. The bonus of long lines is that programmers who cannot read 6 point type must scroll to view them.
10. Cd wrttn wtht vwls s mch trsr. When using abbreviations inside variable or method names, break the boredom with several variants for the same word, and even spell it out longhand once in while. This helps defeat those lazy bums who use text sea
DeepCamp AI