In a bad mood, I just write code like this

stay GitHub There's a project on , It describes the 「 The best garbage code 」 19 key principles of . From variable naming to annotation writing , These guidelines will guide you to write the most brilliant bad code .

In order to keep up with the original GitHub Project consistent style , There is no conversion below . Readers can understand all points of view in the opposite way , This is the perfect way to avoid writing junk code .

Project address ：
https://github.com/trekhleb/state-of-the-art-shitcode

Of course , The following 19 garbage code writing guidelines are not comprehensive , If readers find that there are some unbearable bad code habits , You can also express your views .

Article 1 with a ： The less you type, the better

If we type less , So the more time you have to think about code logic . As shown below ,「Good」 Indicates an example of following this rule ,Bad An example of not following the rule .

Second ： Variable / Function mix naming style

We need to mix naming methods and variables , In this way, we can reflect the diversity of naming .

Article 3 the ： Don't write notes

Anyway, the code can understand , Why write notes ？ Or say , No one's looking at my code anyway , Why write notes ？

Article 4. ： Write notes in your native language

If you break rule three , At least you need to write notes in your native language or other languages . If your native language is English , Then you're violating the rule . Since most programming languages are in English , So why don't you use other languages to comment on ？

Article 5. ： Mix different formats as much as possible

Again , For the diversity of the code , We need to mix as many different formats as possible , For example, single or double quotation marks . If they have the same semantics , Then we should mix .

Article 6. ： Write the code as one line as much as possible

If a series of parameters and methods are implemented together , So the code has to be written together .

Article 7. ： Keep quiet when you find mistakes

When you find something wrong , Others don't need to understand it , So there's no need to print out logs or Traceback.

Article 8. ： Global variables are widely used

Use global variables , It's for 「 Globalization 」 An indispensable part .

Article 9. ： Build standby variables

In case of a one thousand , We need to create some spare variables , Call them whenever you need them .

Article 10. ：Type Use with caution

Generally, do not specify variable type or do type checking frequently , No type is the best type .

Article 11 ： Get ready 「Plan B」

You need to prepare some code that you can't run （unreachable code）, They can be your 「Plan B」.

Twelfth article ： Nested trigonometry

If the code has some nested structure , Or the structure of indenting empty lines , The triangle rule is the most beautiful .

Article 13 ： Mixed indent

We need to avoid indenting , Because indenting makes complex code take up more space in the editor . If you have to indent , Then use a mixed indentation strategy . Of course , This strategy Python It doesn't work , Because it determines the structure of the code by shrinking in .

Article 14 ： Don't lock dependencies

Every time you install a new library , Update existing dependencies . Why maintain the previous version , We need to keep up-to-date with third-party code bases .

Article 15 ： Long function is better than short function

Don't divide the whole logic of the program into code blocks , If IDE Suddenly not , It can't find the necessary files or functions . So write the code in a body function , And no longer maintain additional function imports or code files , So this method is the most stable .

There's no problem with 10000 lines of code in a single file , A thousand lines of code for a single function is no problem .

Article 16 ： The code doesn't need to be tested specifically

These tests are often repetitive and meaningless work .

Article 17. ： Try to avoid duplicate code

Write the code as you want , Especially in small teams , It is, after all, 「 free 」 Rules .

Article 18 ： Building a new project doesn't require README file

In the early stages of the project , We can keep it for a while .

Article 19 ： Save unnecessary code

In the process of writing code , A lot of test code is often generated . These codes are also very important information , So you can't delete , At most, it can only be commented out .

END

edit ：Jack-Cui

source ： Almost Human

---

The copyright belongs to the original author , If there is any infringement , Please contact to delete .