How to write code that cannot be maintained by colleagues?

Yes, you read that right, this article teaches you how to write code that your colleagues cannot maintain.One, program naming

How to write code that cannot be maintained by colleagues

• Variable names that are easy to enter . For example: Fred, asdf
• Single-letter variable name . For example: a, b, c, x, y, z (if not enough, you can consider a1, a2, a3, a4,…)
• Spelling mistakes creatively . For example: SetPintleOpening, SetPintalClosing. This can make it difficult to search the code.
• Abstraction . For example: ProcessData, DoIt, GetData… It’s as abstract as saying nothing.
• Abbreviation . For example: WTF, RTFSC… (The use of pinyin abbreviations is also great, such as: BT, TMD, TJJTDS)
• Random capital letters . For example: gEtnuMbER..
• Reuse naming . Using the same variable name in the embedded statement block has a miraculous effect.
• Use accented letters . For example: int ínt (the second ínt is not int)
• Use underscores . for example:_, __, ___.
• Use different languages . For example, mixing English, German, or Chinese Pinyin.
• Use character names . For example: slash, asterix, comma…
• Use unrelated words . For example: god, superman, iloveu…
• Confusing l and 1 . The letter l and the number 1 are sometimes invisible. 

Second, fake fraud

• Weave comments and code together.

for(j=0; j<array_len; j+ =8)
{
    total += array[j+0 ];
    total += array[j+1 ];
    total += array[j+2 ]; /* Main body of
    total += array[j+3]; * loop is unrolled
    total += array[j+4]; * for greater speed.
    total += array[j+5]; */
    total += array[j+6 ];
    total += array[j+7 ];
}

How to write code that cannot be maintained by colleagues?

• The code and display are inconsistent . For example, your interface is called postal code, but it is called zipcode in the code.
• Hide global variables . Pass the used global variable to the function as a function parameter, so that it can make people feel that the variable is not a global variable.
• Use similar variable names . For example: similar words, swimmer and swimner, similar letters: ilI1| or oO08. parselnt and parseInt, D0Calc and DOCalc. There is also this group: xy_Z, xy__z, _xy_z, _xyz, XY_Z, xY_z, Xy_z.
• Overload functions . Use the same function name, but its function has nothing to do with the specific implementation.
• Operator overloading . Overloading operators can make your code weird, thanks to CCTV, thanks to C++. This thing can improve the messy code to a form of art. For example: overloading the! Operator of a class, but the actual function is not to reverse, let it return an integer. So, if you use the!! Operator, then something interesting will happen-first call the overloaded! Operator of the class, and then give the integer returned by it! It becomes a boolean variable. What if it is!!!? Ha ha.

Three, documents and notes

• Lie in the comments . You don’t really need to lie, just don’t update the comments when you change the code.
• Write nonsense in the comment . For example: /* add 1 to i */
• Only comment on what it is, not why .
• Don’t comment secrets . If you develop a flight system, you must ensure that every time a new flight is added, you have to modify the program for more than 25 locations. Do not write this thing in the document.
• Pay attention to details . When you are designing a very complex algorithm, you must write down all the detailed design. There are no 100 pages and you can’t stop. The paragraphs must have more than 5 levels, and the paragraph numbers must have more than 500, for example: 1.2.4.6 .3.13 – Display all impacts for activity where selected mitigations can apply (short pseudocode omitted). In this way, when you write code, you can make your code consistent with the document, such as: Act1_2_4_6_3_13() Do not comment on Duheng unit. For example, is the time in seconds or milliseconds, the size in pixels or inches, and the size in MB or KB. and many more. In addition, in your code, you can mix different measurement units, but do not comment.
• Gotchas. Pitfalls , never comment the traps in the code.
• Vent your dissatisfaction in comments and documentation . 

Four, program design

• Java Casts . Java’s type transformation is a godsend. Every time you get an object from the Collection, you need to convert it back to its original type. Because of this, these transformation operations will appear in N places. If you change the type, you may not be able to change everything. The compiler may or may not be able to check it.
• Take advantage of Java’s redundancy . For example: Bubblegum b = new Bubblegom(); and swimmer = swimner + 1; Note the subtle differences between the variables.
• Never verify . Never verify the input data, never verify the return value of the function. Doing this can show everyone how much you trust the company’s equipment and other programmers
• Don’t encapsulate . The caller needs to know all the details of being called.
• Clone and copy . For efficiency, you have to learn to use copy + paste. You hardly need to understand other people’s code, you can program efficiently.
• Huge listener . Write a listener, and then make all your button classes use this listener, so that you can make a lot of if…else… statements in this listener, which is quite exciting.
• Use three-dimensional arrays . If you think 3D is not enough, you can try 4D.
• Mix . At the same time use the get/set method of the class and directly access the public variable. The advantage of this is that it can greatly frustrate maintenance personnel.
• Packaging, packaging, packaging . Pack all your APIs 6 to 8 times, with a depth of more than 4 layers. Then pack a similar function.
• There are no secrets . Declare all members as public. In this way, it will be difficult for you to restrict its use by others in the future, and it can cause more coupling with other codes, which can make your code survive longer.
• Arrange and obstruct . Change drawRectangle(height, width) to drawRectangle(width, height), and then change it back after several versions have been released. So programmers who maintain the program quickly don’t understand which one is right.
• Change the variable to the name . For example, change setAlignment(int alignment) to setLeftAlignment, setRightAlignment, setCenterAlignment.
• Keep all your unused and obsolete variables, methods, and code .
• Final all your child node classes , so that when you finish this project, no one can extend your class through inheritance. Isn’t the same with java.lang.String?
• Avoid using layout . This makes us only use absolute coordinates. If your boss forces you to use layout, you can consider using GridBagLayout, and then hard code the grid coordinates.
• Environment variables . If your code needs to use environment variables. Then, you should initialize the members of your class using environment variables, not constructors.
• Use global variables . 1) Put the initialization of global variables in different functions, even if this function has nothing to do with this variable, so that our maintainers can be like detective work. 2) Using global variables can make your function parameters less.
• Configuration file . The configuration file is mainly used for the initialization of some parameters. In programming, we can make the parameter name in the configuration file different from the name in the actual program.
• Inflate your class . Let your class have as many bloated and obscure methods as possible. For example, your class only implements one possibility, but you have to provide all possible methods. Don’t define other classes, put all functions in one class.
• Use subcategories . Object orientation is a godsend for writing unmaintainable code. If you have a class with ten becomes (variables and methods), you can consider writing 10 levels of inheritance, and then put these ten attributes in these ten levels. If possible, put these ten classes in ten different files.
• Confusing your code. Use XML. The power of XML is unmatched. Using XML, you can turn a code that originally only takes 10 lines into 100 lines. Moreover, we have to force others to also have XML. (See, believe in XML to live forever, believe in XML to be confident)
• Decompose the conditional expression . Such as: decompose a==100 into, a>99 && a<101
• Learn to use semicolons . Such as: if (a ); else; {int d; d = c;}
• Indirect transformation . For example: to convert double to string, write new Double(d).toString() instead of Double.toString(d)
• Use nesting extensively . A NB programmer can use more than 10 levels of parentheses () on a line of code, or use more than 20 levels of statement nesting {} in a function, and turn the nested if else into [? :]. A very NB thing.
• Long lines of code . The longer a line of code, the better. So that others need to go back and forth when reading
• Don’t return too early . Don’t use break, so you need at least 5 layers of if-else to handle errors.
• Do not use{}. Don’t use {} in if else , especially when you heavily use if-else nesting, you can even indent the code randomly, so that even the most experienced programmers will step on the trap.
• Trivial package . Comparing to encapsulate a bool class, everything in the class is a bool.
• Loop . Never use for (int i=0; i<n; i++) to use while instead of for, exchange n and i, change <to <=, use i to adjust the pace. 

Five, test

• Never test . Never test any error handling, and never check the return value of a system call.
• Never do performance testing . If it is not fast enough, tell the user to change to a faster machine. If you do a test, you may have to change your algorithm, or even redesign and re-architect.
• Don’t write test cases . Don’t do code coverage testing, automated testing.
• Testing is a cowardly act . A brave programmer does not need this step at all. Too many programs are too afraid of their boss, afraid of losing their job, afraid of users complaining, or even being sued. This fear of fear directly affects productivity. If you have strong confidence in your code, what test do you need? Real programmers don’t need to test their own code.

Six, other

• Your boss knows everything . No matter how madness your boss is, you must act strictly according to his will. In this way, you will learn more knowledge and how to write more unmaintainable code.
• Subvert Help Desk . You want to make sure that your buggy program is never known by the maintenance team. When a user calls or writes an email to you, you just ignore it. Even if you do, asking the user to redo the system or tell the user that there is a problem with their account is the standard answer.
• Shut up . For some big bugs like y2k, you have to learn to be tight-lipped and don’t tell anyone, including your relatives, friends, company colleagues and management, so that when that day comes, you can use this bug to make money.
• Flicker . You will learn to fudge, even if your code is badly written, you have to label it with GoF design pattern, and even if your project is bad, you have to label it agile to let the whole team And the company, and even the entire industry are starting to restlessly, so that we can really pave the way for the hard-to-maintain code.

How to write code that cannot be maintained by colleagues? In short, our slogan is- Write Everywhere, Read Nowher