[Note] 19 Coding Rules that every coder must knowby@peterchang_82818
6,083 reads
6,083 reads

[Note] 19 Coding Rules that every coder must know

by March 14th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

1. Beautiful is better than ugly — be consistent.

Company Mentioned

Mention Thumbnail
featured image - [Note] 19 Coding Rules that every coder must know
 HackerNoon profile picture

This is a note quoted from ‘Mastering Machine Learning with Python in Six Steps’ by data scientist Manohar

1. Beautiful is better than ugly — be consistent.

2. Complex is better than complicated — use existing libraries.

3. Simple is better than complex — keep it simple and stupid (KISS).

4. Flat is better than nested — avoid nested ifs.

5. Explicit is better than implicit — be clear.

6. Sparse is better than dense — separate code into modules.

7. Readability counts — indenting for easy readability.

8. Special cases aren’t special enough to break the rules — everything is an object.

9. Errors should never pass silently — good exception handler.

10. Although practicality beats purity — if required, break the rules.

11. Unless explicitly silenced — error logging and traceability.

12. In ambiguity, refuse the temptation to guess — Python syntax is simpler; however, many times we might take a longer time to decipher it.

13. Although that way may not be obvious at first unless you’re Dutch — there is not only one of way of achieving something.

14. There should be preferably only one obvious way to do it — use existing libraries.

15. If the implementation is hard to explain, it’s a bad idea — if you can’t explain in simple terms then you don’t understand it well enough.

16. Now is better than never — there are quick/dirty ways to get the job done rather than trying too much to optimize.

17. Although never is often better than *right* now — although there is a quick/dirty way, don’t head in the path that will not allow a graceful way back.

18. Namespaces are one honking great idea, so let’s do more of those! — be specific.

19. If the implementation is easy to explain, it may be a good idea — simplicity.