Principles - samuelkripto/styleguide GitHub Wiki

Principles

Table of Contents:

Principles

UNIX

The following Unix philosophy are very applicable here:

- Write programs that do one thing and do it well.
- Write programs to work together.
- Write programs to handle text streams, because that is a universal interface.

Zen

The following 18 Python design principles are very applicable here:

 1. Beautiful is better than ugly.
 2. Explicit is better than implicit.
 3. Simple is better than complex.
 4. Complex is better than complicated.
 5. Flat is better than nested.
 6. Sparse is better than dense.
 7. Readability counts.
 8. Special cases aren't special enough to break the rules.
 9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one-- and preferably only one --obvious way to do it.
14. Although that way may not be obvious at first unless you're Dutch.
15. Now is better than never.
16. Although never is often better than *right* now.
17. If the implementation is hard to explain, it's a bad idea.
18. If the implementation is easy to explain, it may be a good idea.

SOLID

SOLID acronym stands for:

More info: educative.io

Additional Principles

DRY (Don't Repeat Yourself)

DRY is a basic principle of software development aimed at reducing repetition of information. The DRY principle is stated as, “Every piece of knowledge or logic must have a single, unambiguous representation within a system.”

Divide your code and logic into smaller reusable units and use that code by calling it where you want. Don’t write lengthy methods, but divide logic and try to use the existing piece in your method.

KISS (Keep It Simple Stupid)

KISS is a design principle which states that designs and/or systems should be as simple as possible. Wherever possible, complexity should be avoided in a system — as simplicity guarantees the greatest levels of user acceptance and interaction.

Each method should only solve one small problem (the S from SOLID), not many use cases. If you have a lot of conditions in the method, break these out into smaller methods. It will not only be easier to read and maintain, but it can help find bugs a lot faster.

Twelve-Factor App

The twelve-factor app is a methodology for building and deploying modern, scalable, and maintainable software applications. It provides a solid guideline for building modern applications that can run on numerous environments without breaking or losing performance.