19 Hilarious Rules for Writing the Worst Code (And How to Avoid Them)

If we talk about good code, we can list many rules such as consistent formatting and indentation, clear variable and method names, proper documentation and comments, and avoiding over‑shortening code. But do you have a clear idea of what constitutes bad code?

On GitHub there is a new project that describes "the best garbage code" in nineteen key guidelines, covering everything from variable naming to comment writing. These guidelines are meant to help you write the most eye‑catching bad code, and by reading them from the opposite perspective you can perfectly avoid writing garbage code.

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

1. Type as little as possible

Typing less gives you more time to think about code logic. Below are examples of Good (following the rule) and Bad (violating the rule).

2. Mix variable/function naming styles

We need to mix naming methods and variables to reflect naming diversity.

3. Do not write comments

Since the code is understandable, why write comments? Or if nobody reads your code, why bother with comments?

4. Write comments in your native language

If you break rule 3, at least write comments in your mother tongue or another language. If your native language is English, you also break this rule. Since most programming languages use English, why not use another language for comments?

5. Mix different formats as much as possible

For code diversity, mix different formats such as single or double quotes. If they have the same semantics, they should be mixed.

6. Write code on a single line whenever possible

If a series of parameters and methods are implemented together, the code should also be written together.

7. Stay silent when you discover errors

When you find some errors, others don’t need to know, so you don’t need to print logs or tracebacks.

8. Use global variables extensively

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

9. Build backup variables

In case of emergencies, create some backup variables that can be called when needed.

10. Use types cautiously

Generally avoid specifying variable types or frequent type checks; having no type is the best type.

11. Prepare a "Plan B"

You need to prepare some unreachable code that can serve as your "Plan B".

12. Nested triangle rule

If code has nested structures or indented blank lines, the triangle rule makes it look beautiful.

13. Mixed indentation

We should avoid using indentation because it occupies more space in the editor. If indentation is necessary, use a mixed indentation strategy. This does not work in Python, which relies on indentation for structure.

14. Do not lock dependencies

Every time you install a new library, update existing dependencies. Keeping old versions is unnecessary; we should always keep third‑party libraries up to date.

15. Long functions are better than short ones

Do not split program logic into many code blocks; if the IDE crashes, it won’t find necessary files or functions. Therefore, write code in a single main function without extra imports or files. A single file with ten thousand lines or a single function with a thousand lines is acceptable.

16. Code does not need specific tests

These tests are usually repetitive and meaningless.

17. Avoid duplicate code as much as possible

Write code as you wish, especially in small teams, because this is a "freedom" principle.

18. New projects do not need a README document

In the early stage of a project, we can temporarily keep this state.

19. Keep unnecessary code

During coding, many test codes are generated. These are important resources and should not be deleted; at most they can be commented out.