Clean Code

Code that is readable and understandable by other humans, not merely executable by a machine. The underlying principle is that code is read far more often than it is written, so clarity and expressiveness are first-class concerns. 

A frequently cited standard comes from Martin Fowler: good programmers write code that humans can understand, not just code that a computer can run. Clean code tends to use meaningful names, small focused functions with a single responsibility, and no unnecessary duplication.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

• It expresses its intent clearly, meaning that variables, functions, and classes have descriptive names that tell you exactly what they do. Often following a naming and casing standard so that you cannot identify i ndividual authors.
• Functions perform a single action.
• Code adheres to the DRY principle (Don't Repeat Yourself). If you need to change a business rule, you should only have to change it in one place.
• It isn't longer than it needs to be, including comments. It contains no dead code, unused variables, or speculative features (YAGNI - you ain't gonna need it). 
• It handles errors gracefully such as network failure, missing files or bad user input, and handles those exceptions explicitly, leaving the system in a predictable state.
• It has minimal dependencies. Internally, code keeps connections between different parts of the software to a minimum and externally multiple packages aren't brought in for the same action (breaking DRY and increasing security surface area). 
• It is self-documenting. The code itself explains what it is doing and comments add why an approach was taken or the business logic being implemented, rather than explaining the lines of code they cover. 
• Similarly to self- documenting, clean code is verifiable. It is written in a way that makes it easy to test and it actually passes those automated tests consistently.