loading...

How to write Unmaintainable Code

flaviocopes profile image flavio ⚡️🔥 Originally published at flaviocopes.com on ・2 min read

In this tutorial I want to illustrate how to write unmaintainable code.

By writing unmaintainable code you can make sure you will never get fired because you’ll be the only one capable of understanding what the code does, and most importantly why.

Please note: this post is ironic

  1. Assign weird, fantasy and casual names to your variables, functions and objects. There should be no correlation between the name and what the item does or how it behaves.
  2. Prefer abbreviations and acronyms over descriptive names. One-letter variables are great.
  3. Favor reuse of variables in the code. Always use i in your loops.
  4. Use your own language for names. After all, there’s no need to all use English.
  5. Same applies to comments. Feel free to write them in whatever language you speak, who cares if the next developer is from another country?
  6. As for comments, I was joking. Do not write any comments.
  7. If you really want to write comments, do not bother to update them when you change the code that they describe.
  8. Prefer global variables over getting too clever with scoping
  9. Never test your code. You are good, your code is good too.
  10. Prefer overcomplicating than being too simplistic. No one was ever fired for creating a complex and ego-fulfilling architecture that required a 3-months long useless rewrite of code that was perfectly working.
  11. Optimize whatever you can in clever ways. Computers are slow, we should avoid overheating them and help fight climate change. Rewrite your code in assembly is often a good idea.
  12. Relatively unknown languages and frameworks are always better than popular and battle tested solutions. Prefer them over the solution everyone else uses.
  13. Better yet, create your own framework.
  14. Never use 3rd party libraries
  15. Overuse 3rd party libraries
  16. Use every design pattern you read about, and try to fit it into your design even if it’s not, really
  17. Use tools built by large corporations because they know it better and your 1-person startup will surely benefit from the thousands of man hours that went into building them. Bonus points if they are very complicated to use and have their own set of clever-sounding naming conventions.
  18. Do not use version control, and do not even version the code at all. After all there’s just one right version of the program. You can easily remember all the changes you perform and most importantly why a change was made. No need to track it in an external repository.
  19. Freely copy and paste code from Stack Overflow or random blogs without understanding it first
  20. Indentation does not matter. At all. Mix spaces and tabs, too.
  21. Freely overuse abstractions. Abstractions are great. Make everything reusable and overthink things like a king.
  22. Perhaps you’ll reuse this library in every project you’ll make in the next 20 years, who knows? Better think about all the possible edge cases first.
  23. Always implement every single great idea you have
  24. 2000-lines functions are a great idea
  25. Assume there’s a 10x engineer watching over your shoulders while you code.

Discussion

pic
Editor guide
Collapse
paulasantamaria profile image
Paula Santamaría

26 Getting an unhandled exception? Just wrap that troublesome code with try and an empty catch, that'd do the trick.

Collapse
ghost profile image
Ghost

about 20, if you ask me, if you use tabs, you already are mixing tabs and spaces. 2 and 3 with coution, don't give a long name to a to variable for a 3-line for loop, i and j are just fine; we don't like 30-long variable names either, just adding two of them takes the whole line, and average_of_anual_income_after_taxes is way too much, good judgement is always required.

Collapse
stereobooster profile image
stereobooster

21 - 23 perfecto 👌

I saw research which showed there is no significant difference in speed of bug-fixing for abbreviated and full names. The difference was in the approach.

The point about English - I get it, but the other point of view is that we losing the diversity of languages.

Collapse
vlasales profile image
Vlastimil Pospichal

Names i and j are good for local integer indexes. I use short variable names, no acronyms. When you want join more than two words for make a variable name, you need shorter method body. When you have long method name, you need split the class to more pieces. One verb is enought for method name.

Collapse
cecilelebleu profile image
Cécile Lebleu

I suggest adding the tag jokes. It was really funny 😂

Collapse
vlasales profile image
Vlastimil Pospichal

What is a comment?

Collapse
integerman profile image
Matt Eland

Having different files for different pieces of code is inefficient and causes artificial delays for navigating to a different file.

Collapse
alinp25 profile image
Collapse
fanchgadjo profile image
Francois K

My former lead-dev cowoker checks too many boxes !