The original article is here (mindprod.com/jgloss/unma…

After reading, I want to say —

What is “creativity”? Creativity is — the ability to do a bad job well and creatively.

What is “crazy”, crazy is — in a calm, sophisticated, indomitable and serious spirit to push you to the edge of the breaking point.

Also, maintenance program friends, you are dead!!

If architects built houses like programmers wrote programs, then the first woodpecker to arrive could destroy our civilization

Program named

  1. A name that is easy to type. For example: Fred, ASDF
  2. Single-letter variable name. For example: A, B, C, X,y,z (if not enough, consider A1, A2, A3, A4… .).
  3. Get creative with your spelling mistakes. For example: SetPintleOpening, SetPintalClosing. This makes it hard to search the code.
  4. Abstract. For example: ProcessData, DoIt, GetData… It’s as abstract as not saying anything at all.
  5. Abbreviations. For example, WTF, RTFSC… (It’s also useful to use pinyin abbreviations, such as BT, TMD, TJJTDS)
  6. Random capital letters. Such as: gEtnuMbER..
  7. Reuse naming. Using the same variable name in an embedded block works wonders.
  8. Use accented letters. For example: int int (the second int is not an int)
  9. Use underscores. For example, _, __, ___.
  10. Use different languages. Like mixing English, German, or Chinese pinyin.
  11. Use character names. Slash, Asterix, comma…
  12. Use extraneous words. For example: God, Superman, Iloveu… .
  13. Confuse l with 1. The letter L and the number 1 are sometimes invisible.

Camouflage fraud

  1. Interweave comments with code.
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 ];
}
Copy the code
  1. Code and display inconsistent. For example, you might have postal Code in your interface, but zipCode in your code.
  2. Hide global variables. Passing the use of a global variable to a function as a function parameter makes it appear that the variable is not global.
  3. Use similar variable names. Such as: word similarity, swimmer and swimner, letters: ilI1 | or oO08. Parselnt and parseInt, D0Calc and DOCalc. And this group: xy_Z, XY__z, _XY_z, _XYZ, xy_Z, xy_Z, xy_Z.
  4. Overloaded functions. Use the same function name, but its functionality has nothing to do with the implementation.
  5. Operator overloading. Overloaded operators can make your code creepy, thanks CCTV, thanks C++. This is something that can take messy code and turn it into an art form. For example: reload a class! Operator, but the actual function is not to return an integer. So if you use! ! Operator, then something interesting happens — first the class is overloaded! Operator, and then returns the integer to! Becomes a Boolean variable if it is!! ? Ha ha.

Documentation and comments

  1. Lying in comments. You don’t really have to lie, just don’t update comments when you change the code.
  2. Annotation inside write nonsense. /* add 1 to I */
  3. Only comment on what, not why.
  4. Don’t annotate secrets. If you are developing a flight system, make sure that every time a new flight is added, you have to change the program for more than 25 positions. Don’t put that in your document.
  5. Attention to detail. When you design a very complex algorithm, you must write down all the details of the design, not stop until 100 pages, paragraphs should be more than 5 levels, paragraphs should be more than 500 numbers, for example: 1.2.4.6.3.13 — Display all impacts for activity where selected mitigations can apply (short pseudocode omitted). This way, when you write code, you can keep your code consistent with documentation, e.g. Act1_2_4_6_3_13() never comment on units of measurement. Time in seconds or milliseconds, size in pixels or inches, size in MB or KB. And so on. Also, in your code, you can mix different units of measurement, but don’t comment them out.
  6. Gotchas. Traps. Never comment out traps in your code.
  7. Vent your frustration in comments and documentation.

The program design

  1. Java Casts. Java’s type transformation is a godsend. Every time you retrieve an object from a Collection, you need to revert it back to its original type. Therefore, these transformation operations can occur in N more places. If you change the type, then you can’t change everything. The compiler may or may not be able to check.
  2. Take advantage of Java’s redundancy. Bubblegum b = new Bubblegom(); And swimmer = swimner + 1; Note the subtle differences between variables.
  3. Never validate. The input data is never validated, and the return value of the function is never validated. Doing so shows everyone how much you trust the company’s devices and other programmers
  4. Do not encapsulate. The caller needs to know all the details of what is being called.
  5. Clone and copy. To be efficient, you should learn to use copy + paste. You can program efficiently with almost no understanding of other people’s code.
  6. Huge listener. Write a listener and use it for all your button classes. Then you can write a whole bunch of if… The else… Statement, quite stimulating.
  7. Use a three-dimensional array. If three dimensions aren’t enough for you, you can try four.
  8. Mix. Use both the class’s get/set methods and access the public variable directly. The advantage of doing this is that it can greatly frustrate maintenance personnel.
  9. Package, package, package. Wrap all of your apis six to eight times, up to four or more layers deep. And then wrap up similar functionality.
  10. There are no secrets. Declare all members as public. This will make it harder to restrict its use later, and it will cause more coupling with other code, which will make your code last longer.
  11. Alignment and obstruction. Change drawRectangle(height, width) to drawRectangle(width, height), and then change it back after a few releases. The programmers who maintain the program will soon lose track of which one is right.
  12. Change the variable to the name. For example, change setAlignment(int alignment) to setLeftAlignment, setRightAlignment, setCenterAlignment.
  13. Keep all of your unused and stale variables, methods, and code.
  14. Final All of your children’s classes, so that when you’re done with the project, no one can extend your class by inheritance. Isn’t the same with java.lang.String?
  15. Avoid using layouts. This leaves us with absolute coordinates. If your boss forces you to use layout, you can consider using GridBagLayout and then hard code the grid coordinates.
  16. Environment variables. If your code needs to use environment variables. Well, you should initialize the members of your class using environment variables, not constructors.
  17. Use global variables. 1) Placing initialization of global variables in a different function, even if the function has nothing to do with the variable, allows our maintainers to do detective work. 2) Use global variables to make your functions take fewer arguments.
  18. Configuration file. The configuration file is used to initialize some parameters. In programming, we can make the parameter names in the configuration file different from the names in the actual program.
  19. Expand your class. Let your classes have as many bloated and obscure methods as possible. For example, your class implements only one possibility, but you provide methods for all of them. Don’t define other classes; put all functionality in one class.
  20. Use subclasses. Object orientation is a godsend for writing unmaintainable code. If you have a class with ten attributes (variables and methods) you can consider writing ten levels of inheritance, and then putting the ten attributes in each of those ten levels. If possible, put these ten classes in ten different files.
  21. Clutter up your code using XML. XML is more powerful than anyone else. With XML you can turn 10 lines of code into 100 lines. Also, force others to have XML. (See: Believe XML, live forever, believe XML, be confident)
  22. Decompose the conditional expression. For example, a==100 is decomposed into a> 99&&a <101
  23. Learn to use semicolons. If (a); else; { int d; d = c; }
  24. Indirect transformation. For example, to convert double toString, write new double (d).tostring () instead of double-.tostring (d)
  25. Use nesting extensively. An NB programmer can use more than 10 layers of parentheses () on a single line of code, or more than 20 layers of nested {} statements in a single function. Converting nested if else to [? :] is also a great thing.
  26. Long lines of code. The longer a line of code is, the better. So that people have to read back and forth
  27. Don’t return too soon. Do not use breaks, as you will need at least 5 more layers of if-else to handle errors.
  28. Do not use {}. Don’t use {} on if else, especially if you’re heavily nested with if-else. You can even indent code around it, and even the most experienced programmer will fall into the trap.
  29. Trivial encapsulation. Comparison encapsulates a bool class, which does everything, which is a bool.
  30. Cycle. For (int I =0; i

test

  1. Never test. Never test any error handling, and never test the return value of a system call.
  2. Never do performance testing. If not, tell the user to switch to a faster machine. If you do a test, you might want to change your algorithm, or even redesign it.
  3. Don’t write test cases. Don’t do code coverage testing, automate testing.
  4. Testing is cowardly. A brave programmer doesn’t need this step at all. Too many apps are too afraid of their bosses, of losing their jobs, of users complaining, or even being sued. This fear directly affects productivity. If you have strong confidence in your code, what kind of tests do you need? Real programmers don’t need to test their code.

other

  1. Your boss knows everything. Follow your boss’s instructions to the letter, no matter how stupid he is, and you’ll learn more and how to write more unmaintainable code.
  2. Subvert Help Desk. Make sure your bug-ridden program is never known by the maintenance team. When a user calls or emails you, you ignore them, and if they do, asking them to redo the system or telling them there’s a problem with their account is the standard response.
  3. Shut up. For some big bugs like Y2K, learn to keep your mouth shut and not tell anyone, including your family, friends, colleagues and management, so that when the day comes, you can make money from the bug.
  4. Fool. You learn to fool your code into putting a GoF design pattern label on it even if it sucks, and you put an Agile label on it even if it sucks, so that the team, the company, and the industry start to get agitated, paving the way for really hard code to maintain.

There’s so much more in this document, it’s so damn powerful, check it out for yourself. Friends who have energy and ability might as well translate it into Chinese.

Anyway, our slogan is — Write Everywhere, Read Nowhere

(Full text)