Shit-like bad code, do you love it?

There is a project on GitHub that describes nineteen key principles of "best garbage code". From variable naming to comment writing. These guidelines will guide you in writing the best bad code you can.

In order to maintain the same style as the original GitHub project, there is no conversion below. Readers can understand all points of view from the opposite perspective, which is a perfect way to avoid writing garbage code.

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

Of course , the following nineteen guidelines for writing junk code are not exhaustive. If readers find some unbearable bad coding habits, you can also express your opinions.

? First rule: The less you type, the better

If we type less, then The more time you have to think about code logic and other issues. As shown below, "Good" indicates examples that follow the rule, and "Bad" indicates examples that do not follow the rule.

? Article 2: Mixed naming style of variables/functions

We need to mix naming methods and variables so that the diversity of naming can be reflected.

? Article 3: Don’t write comments

I can understand the code anyway, why should I Write a note? In other words, no one is reading my code anyway, so why should I write comments?

?Rule 4: Write comments in your native language

If you violate rule 3 , then at least writing comments needs to be in your native language or other languages. If you are a native English speaker, you are also breaking this rule. Since most programming languages ​​​​are in English, why not use other languages ​​​​to comment?

?Article 5: Mix different formats as much as possible

Similarly, for code diversity, we need to mix different formats as much as possible, such as single quotes or double quotes. If they have the same semantics, they should be mixed.

?Article 6: Write the code in one line as much as possible

If a series of parameters and methods They are all implemented together, so the code must also be written together.

?Article 7: Keep silent when an error is discovered

When you find something wrong, others don't need to know about it, so there's no need to print out a log or traceback.

?Article 8: Use global variables extensively

Using global variables is an indispensable part of "globalization".

?Item 9: Build backup variables

Just in case, we need to create some Spare variables, call them anytime when needed.

?Article 10: Type needs to be used with caution

Generally do not specify the variable type or do it frequently Type checking, no type is the best type.

?Article 11: Prepare "Plan B"

#You need to prepare something that will not work Unreachable code, they can serve as your "Plan B".

?Article 12: Nested Triangle Rule

If the code has For some nested structures, or structures with indented blank lines, the triangle rule is the most beautiful.

?Item 13: Mixed Indentation

We need Avoid indentation, which makes complex code take up more space in the editor. If you must use indentation, use a mixed indentation strategy. Of course, this strategy doesn't work in Python, which relies on indentation to structure its code.

?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 the latest third-party code base at all times.

?Article 15: Long functions are better than short functions

Don’t use The overall logic of the program is divided into some code blocks. What if the IDE suddenly fails and it cannot find the necessary files or functions. Therefore, writing the code in a main function and no longer maintaining additional function imports or code files is the most stable method.

Ten thousand lines of code for a single file is no problem, and so is a thousand lines of code for a single function.

?Article 16: The code does not require specific tests

These tests are usually repetitive and meaningless work.

?Article 17: Try to avoid duplicating code

Write code according to your ideas, especially when In a small team, this is the principle of "freedom" after all.

?Article 18: README documents are not required to build new projects

In the early stages of the project, we can temporarily maintain this state.

?Article 19: Save unnecessary code

In the process of writing code, there are often Generate a lot of test code. These codes are also very important information, so they cannot be deleted and can only be commented out at most.

##

The above is the detailed content of Shit-like bad code, do you love it?. For more information, please follow other related articles on the PHP Chinese website!