Top 12 Tips to Develop Unmaintainable Code
BY MARKUS SPRUNCK
This article describes how to write unmaintainable code and have an excellent paid job for the rest of your life. The key skill to unmaintainable code is the obfuscation of the code - besides poor design, no test cases and overly complex algorithms. If you really like to write well maintainable code, feel use this as input for things you shouldn't do in your next project.
Use Klingon for Naming in your Code
At the first glance a method like
void bortaSbIrjabluDIreHQaQqunay()
is difficult to understand, but for a developer with perfect knowledge of Klingon, it will be clear that you mean something like
void revengeIsADishBestServedCold()
If you are not fluent in Klingon [1], but familiar with other languages like Esperanto, French and/or elder dialects of Romulan you may also use these.
For all others - with less foreign language skills - there are still some other helpful techniques to obfuscate your code.
Extensive Use of Acronyms & Complex Abbreviations
As you can see, the method:
void revengeIsADishBestServedCold()
gets
void reIsADiBeSeCo()
Yes, this is a good starting point, but there is still a lot to improve. Please, ensure that nobody gets a glossary of your abbreviations and use same acronyms with different meaning in each class.
Synonyms are also helpful; just use a thesaurus to bring more variance in your naming. The target should be - never use the same word with the same meaning in more than one class.
Replace Single Characters with Others, Numbers or Just Nonsense
Starting from the quite good
void reIsADiBeSeCo()
you could now replace some characters with numbers like in
void re1sADiBeSeCo()
Use numbers and/or characters which are similar shape like in the following sample [2]
void _A_B_C_D_E_F_G_H_I_J_K_L_M_N_O_P_Q_R_S_T_U_V_W_X_Y_Z_()
void _4_3_C_D_E_F_6_H_1_J_K_L_M_N_0_P_Q_R_5_7_µ_V_vv_X_Y_2_()
You will save a lot of time if you suffer from dyslexia and/or poor typing skills (people like me). In this case you will write things like
void raedDada()
instead of
void readData()
Please, never refactor these typos.
CamElcase is a Good Programming Convention
The use of CamelCase writing is a common practice in Java, but never use the correct beginning of words for an upper character. You have to admit that myCamElcase() reads not so easy.
Keep in mind, that for Java compiler myCamElcase() and myCamELcase() are complete different signatures. Please, ensure that you have both in your class and the implementation should do completely different things.
Code Comments - Mature Like Good Red Wine
Some companies request extensive code comments. Fine, comments and especially JavaDoc is an excellent source for obfuscation and reduced maintainability.
The first rule is to ensure that all comments have no meaning, e.g. describe just what happens and not the why, use Eclipse Plugins to generate completely meaningless content. When you change the code never update the comments. Comments are like good red wine - they need "extended ageing in the bottle".
Another way is to spread fears amongst possible maintenance developers. Small inline comments like:
// Looks simple, but never ever change this or everything blows up later in production!
Clever Unit Tests Will Not Improve Maintainability
Yes, I know: "Unit test are really dangerous!" They could improve the maintainable if not carefully developed.
Let's assume in your company they have a policy that each code needs high code coverage and they measure it. No problem, just write:
a lot of test with no or useless asserts,
never test business logic,
test just the positive case,
always the getters and setters,
use mocking to test all the useless exceptions - that will never rise in production,
never ever do an integration test and
don't forget "never test business logic"
Cyclic Dependencies - Excellent Supporter for Acute Mental Confusion
In Java you need a lot of packages to create the illusion of a good architecture. At least 7 layers (from GUI to database) and with dozens of packages in each are helpful to convince the management about the worth of the design.
But ensure that each class is dependent from random packages in all directions. The best are cyclic dependencies over more packages. Don't forget "Cyclic dependencies are the GOTO's of the new millennium".
Code Clones Really Matter
From the scientific point of view - it seems not to be clear if code clones matter. But in practice, they can help to write unmaintainable code.
Two things are important (i) with clones you increase the size of software and (ii) inconsistent changes of behavior and/or bug fixing leads to confusion. The most crucial point is the code size, because the time you need to do a change is direct proportional to the lines of code you have.
Because of this, clones really matter.
Do Not Reinvent the Wheel! - Lean from the Bugs of Others!
Learn from others, every day! Spend 20 minutes per day in forums, discussion pages and/or read about common bugs. Study the warnings of FindBugs (or other static code analysis tools).
This inspiration will help you to write the clever bugs. Because, the obvious are not good for your reputation.
Be evil but don't be discoverable as a developer who writes unmaintainable code!
Never Share Know-How
Last but not least, never share your know-how. Write or better generate thousands of pages of documentation but never explain the architecture in two pages. If you have to train a potential successor just answer questions and explain nothing.
If you really shared some know-how, then you could refactor the application the next morning.
Do Dirty Workarounds that Sometimes Work
Especially when you have some unstable Selenium GUI Test Code you should always use Thread.sleep(...) with magic numbers to make your Selenium Tests sometimes successful. But the time should be short enough that some tests fail in the case the server is slower than during your demonstration to your boss.
void waitOneSecondBecauseSeleniumIsTooFastAndJustCantWaitTillThisFuckingElementIsVisable()
By the way long method names are also helpful to express emotions (the method name is from real code - thank you Robert for writing this today).
Yes, Test Code must be Unmaintainable!
Also the Tests should be as bitchy as your production code. They run just on Mondays and in the case the sun shines (see http://openweathermap.org/api).
And please repeat yourself.
Recommendations
To write unmaintainable code you have to be a really good developer and it is not easy. If you like to have fun, it will be a good idea to develop good maintainable code instead.
Share this tutorial with your colleagues and discuss how to improve your current project. A good starting point is static code analysis and unit testing. The best is - to do code reviews within the team to find out what can be improved.
This tutorial is inspired by the superb page "How To Write Unmaintainable Code" just have a look. [3]