How can I write codes that cannot be maintained-someone else studies this, washing or tragedy?

Address: http://coolshell.cn/articles/4758.html

I think there are a lot of cool ShellsArticleBut the most visited part is the article "6 abnormal Hello World", and it can be on the right side of the site"Popular"," How to encrypt source code ", and programming is really difficult. It can be seen that the reader's preferences on this site, and I also believe that you are all "treasure"ProgramMember. Therefore, we recommend this article to you today. I believe it will touch your attention.

The original Article is here (http://mindprod.com/jgloss/unmain.html), I want to say after reading --

1. What is "creativity"? creativity is the ability to be so beautiful and creative even if you want to do something bad.
2. What is "crazy"? Crazy is -- pushing you to the verge of collapse with a calm, sophisticated, indomitable, serious spirit of 1.1.

I have excerpted some articles, but I have not fully translated them. I simply translated them and added some ridicule. If you have the following programming habits, please check your account. In addition, you are dead !!

If builders built buildings the way programmers write programs, then the first woodpecker that came along wowould destroy civilization. (If an architect builds a house just like a programmer writes a program, then the first woodpecker will destroy our civilization)

~ Gerald weberger (born: 1933-10-27 age: 77) weberger's second law

Program name

• Easy to enter name. For example, Fred and ASDF.
• Variable name with single letter. For example: A, B, C, x, y, z (Chen Hao Note: if not enough, consider A1, A2, A3, A4 ,....)
• Creative spelling mistakes. For example, setpintleopening and setpintalclosing. This makes it difficult to searchCode.
• Abstraction. For example: processdata, doit, getdata... The abstraction is the same as nothing.
• Abbreviations. For example, WTF, rtfsc ...... (Chen Hao Note: pinyin abbreviations are also powerful, such as BT, TMD, and tjjtds)
• Random uppercase letters. For example, getnumber ..
• Reuse naming. Using the same variable name in the embedded statement block has an odd effect.
• Use accent letters. For example: int í NT (Note: The second í NT is not int)
• Underline. For example :_,__,___.
• Use different languages. Such as English, German, or Chinese pinyin.
• Use character naming. For example: Slash, Asterix, comma...
• Use irrelevant words. For example: God, Superman, iloveu ....
• Obfuscation of L and 1. The letters l and number 1 are sometimes invisible.

  Disguised fraud

• Link comments with codes.

 For  (J  =  0  ; J  <  Array_len; j  +     =  8  )  {  Total  + =  Array [J  + 0  ];  Total  + =  Array [J  +  1  ];  Total  + =  Array [J  +  2  ];  /*  Main Body  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  ];  } 

• Hide macro definition. For example: # define a = B A = 0-b. When people see a = B, no one can think of it as a macro.

• Line feed. As shown below, it is difficult to search for xy_z in the following example.

 
# DefineLocal_var XY \
_ Z//Local_var OK
 

Inconsistent code and display . For example, your interface is postal code, but zipcode is indeed in the code.

• Hide global variables. Pass the global variable to the function as a function parameter so that the variable is not a global variable.

• Use consent words. For example:

# DefineXxx global_var//In File STD. H & nbsp;
# DefineXy_z xxx//In file .. \ other \ substd. H & nbsp;
# DefineLocal_var xy_z//In file .. \ codestd \ Inst. h
 

Use a similar variable name . For example, the word is similar. The character Mer and the character ner have the same letter: ili1 | or oo08. Parselnt and parseint, d0calc and docalc. In addition, these groups are xy_z, XY _ z, _ xy_z, _ xyz, xy_z, xy_z, and xy_z.

• Overload Functions. Use the same function name, but its function has nothing to do with the specific implementation.

• Operator overload. The overload operator can make your code strange. Thanks to CCTV and C ++. This can improve the chaotic code to an artistic form. For example, reload a class! Returns an integer instead of an inverse operator. So, if you use it! ! Operator, so interesting things happen-first, call the class overload! Returns an integer to! A boolean variable. If yes !!! What about it? Haha.

• # Define. After reading the messy code articles on this site, you will know the significance of macro definition and pre-compilation for writing unreadable code. However, an imaginative thing is to use pre-compilation in the header file to check whether the header file has been included several times. When the header file is included for different times, the function definitions are completely different.

 # Ifndef done
# Ifdef twice
  //  Put stuff here to declare 3rd time around void g (char * Str); # define done  
  # Else     //  Twice 
# Ifdef once
  //  Put stuff here to declare 2nd time around und <void g (void * Str); # define twice  
  # Else     //  Once  
  //  Put stuff here to declare 1st time around und  
  Void  G (STD ::  String Str );
  # Define  Once  
  # Endif     //  Once  
  # Endif     //  Twice  
  # Endif     // Done 

Documents and notes

• Lie in comments. You don't have to lie. You only need to update comments when you change the code.
• Comment on obvious things. For example:/* Add 1 to I */. (Refer to the "five notes to be avoided" on this site ")
• Only comment on what it is, not why.
• Do not comment on secrets. If you develop a flight system, make sure that each new flight is added, You have to modify the program at more than 25 locations. Never write this in the document.
• Focus on details. When you design a complicatedAlgorithmYou must write down all the detailed designs. If there are no 100 pages, you cannot stop. The section must have more than 5 levels, and the section number must have more than 500. For example: 1.2.4.6.3.13-display all impacts for activity where selected mitigations can apply (short Pseudo Code 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 out the measurement unit. For example, the time is in seconds or milliseconds, the size is in pixels or inches, and the size is MB or kb. And so on. In addition, you can mix different weights in your code, but do not comment.
• Gotchas. Do not comment on the traps in the code.
• Venting dissatisfaction in comments and documents. (Refer to the "five notes to be avoided" on this site ")

Program Design

• Java casts. The type transformation of Java is a godlike thing. Every time you get an object from the collection, you need to convert it back to the original type. Because, these transformation operations will appear in n more places. If you change the type, you may not change everything. The compiler may or may not.
• Java Redundancy. For example, bubblegum B = new bubblegom (); and timer mer = runner ner + 1; pay attention to the nuances between variables.
• Never verify. The input data is never verified, and the return value of the function is never verified. This will show you how much you trust the company's devices and other programmers.
• Do not encapsulate. The caller needs to know all the details of the call.
• Clone and copy. For efficiency, you must learn to use copy + paste. You almost don't need to understand other people's code, so you can program efficiently. (Chen Hao Note: A lot of code bugs come out of copy + paste)
• Huge listener. Write a listener and make all your button classes use this listener. In this way, you can compile a lot of if... Else... Statement.
• Use 3D Arrays. If you think 3D is not enough, try four-dimensional.
• Mix. Use the get/Set Method of the class and directly access the public variable. The advantage of doing so is that maintenance personnel can be greatly frustrated.
• Packaging, packaging, packaging. Pack all your APIs six to eight times, with a depth of more than four layers. Then, similar functions are packaged.
• No secret. Declare all Members as public. In this way, it will be difficult for you to restrict the use of the code in the future, and this will lead to more coupling with other code, so that your code can survive for a longer time.
• Arrangement and obstruction. Change drawrectangle (height, width) to drawrectangle (width, height). After several versions of release, change it back. In this way, programmers who maintain programs will not be able to quickly understand which one is right.
• Change the variable name. For example, change setalignment (INT alignment) to setleftalignment, setrightalignment, and setcenteralignment.
• Packratting. Keep all unused and obsolete variables, methods, and code.
• That's finaL. Final is the class of all your child nodes. In this way, when you finish this project, no one can extend your class through inheritance. Is this not true for Java. Lang. String?
• Avoid using interfaces. In Java, BS interface, BS uses virtual functions in C ++.
• Avoid Layout. In this way, we can only use absolute coordinates. If your boss forces you to use layout, you can consider using gridbaglayout and then place the grid coordinate hard code.
• Environment Variable. If your code needs to use environment variables. (Getenv ()-C ++/system. getproperty ()-Java), you should use environment variables instead of constructors for the initialization of your class members.
• Use magic numbeR. See an episode in Linux.
• 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 maintenance staff can do just like a detective job. 2) using global variables can reduce the number of parameters of your function.
• Configuration File. The configuration file is mainly used for parameter initialization. In programming, we can make the parameter names in the configuration file different from those in the actual program.
• Expand your class. Let your class have as many bloated and obscure methods as possible. For example, your class only implements one possibility, but you need to provide all possible methods. Do not define other classes and place all functions in one class.
• Subclass. Object-oriented is a godsend that fails to maintain code. If you have ten classes (variables and methods), you can consider writing 10 levels of inheritance, and then put these ten attributes in these ten layers. If possible, place the ten classes in ten different files.

Confusing your code

• Use XML. XML is incredibly powerful. With XML, you can change the code of 10 lines to 100 lines. In addition, it also forces others to have XML. (See. Believe in XML to survive forever, and believe in XML to be confident)
• Messy C code. Some methods have been mentioned in "How to encrypt source code". I will add some more here.
• Use different hexadecimal. For example, 10 and 010 are not the same. For example, array = new int [] {111,120,013,121 ,};
• Try to use void *. Convert it to various types
• Implicit Transformation. The C ++ constructor allows you to complete the transformation without knowing it.
• Decomposition condition expression. For example, divide a = 100 into a> 99 & A <101
• Learn to use semicolons. For example: if (a); else; {int D; D = C ;}
• Indirect Transformation. For example, convert double to string and write it as new double (d). tostring () instead of double. tostring (d)
• Extensive use of nesting. An Nb programmer can use parentheses () with more than 10 layers on a line of code, or use nested statements with more than 20 layers in a function {}, convert nested if Else [? :] Is also a very Nb thing.
• Use a variant array of C. Myarray [I] can be changed to * (myarray + I) or * (I + myarray), which is equivalent to I [myarray]. Let's look at a function call example. function declaration: int myfunc (int q, int p) {return P % Q;} function call myfunc (6291, 8) [array];
• Long code line. The longer a line of code, the better. In this way, when others read, they need to go back and forth.
• Do not return earlier. Do not use goto or break. In this way, you need at least five layers of IF-else to handle errors.
• Do not use {}. Do not use {} in the IF else, especially when you use the IF-else nesting by weight, you can even unindent the code in it. In this way, even the most experienced programmers will step on the trap.
• Use macro definition. Macro definition is definitely the best tool for confusing C/C ++ code. This is how the veteran teaches new programmers.
• Trivial Encapsulation. It encapsulates a bool class and does everything in the class. It is a bool.
• Loop. Never use for (INT I = 0; I <n; I ++) instead of for, exchange N and I, change <to <=, and use I-to adjust the pace.

Test

• Never test. Do not test any error handling and never detect the return values of system calls.
• Never perform performance tests. If it is not fast enough, tell the user to change to a faster machine. If you do a test, you may need to modify your algorithm, or even redesign and re-architecture.
• Do not write Test Cases. Do not perform code coverage tests or automated tests.
• Testing is a coward's behavior. A brave programmer does not need this step at all. Too many programs are too afraid of their boss, fear of losing their jobs, fear user complaints, and even be sued. This fear directly affects productivity. If you have strong confidence in your code, what tests do you need? Real Programmers do not need to test their own code.

Others

• Your boss knows everything. No matter how many Sb your boss has, you must strictly follow His will, so that you will learn more about how to write codes that cannot be maintained.
• Subvert Help Desk. Make sure that your bug-filled program is never known by the maintenance team. When a user calls and writes an email to you, you can ignore it. It is a standard answer to let the user redo the system or tell the user that there is a problem with the account.
• Shut up. For some big bugs like Y2K, you must learn to keep your mouth secure and do not tell anyone, including your friends and family members, as well as company colleagues and management personnel. By that day, you can use this bug to make money.
• Fudao. You will learn to be fooled. Even if your code is poorly written, you should also add a gof Design Pattern tag for it, even if your project is worse, you also need to add agile labels for them. Only by learning to cheat like thoughtworks consultants in China can you learn more dazzling and cool methods for the entire team and company, even the entire industry is starting to stir up, so as to pave the way for the code that is truly difficult to maintain.

There are a lot more in this document. It's so powerful as TMD. Let's take a look. If you are energetic and competent, you may wish to translate it into Chinese.

In short, our slogan is --

Write everywhere, read nowhere