Category: Coding Style

The Zen of Python

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Coding style guide

Clean Code Meaningful Names


The following article is a summary of the tips given in choosing meaningful names for things in our code. The tips are taken from Robert C. Martin Called Clean Code.

Clean code meaningful names

Clean Code. Chapter 2:  Meaningful Names.

Why do we need Meaningful Names in our Code?

Names are everywhere in software. Names are given to variables, functions, arguments, classes and packages. Our source files have names. We name so many things it is important to choose names that contribute to cleaner code and maintain a consistent meaning.

Rules for Clean Code Meaningful Names

1. Use Intentional-Revealing Names

If a name requires a comment, then the name does not reveal intent. Apart from localised variables, a single character variables is not adequate.

int d; //elapsed time in days


int elapsedDays;

2. Avoid Disinformation

Do not use the lower-case L or uppercase o as variable names.

3. Make Meaningful Distinctions

If names should be different, they should also mean something different. The word variable should never appear in a variable name. The word table should never appear in a table name.

4. Use Pronounceable Names

Humans are good at words.

5. Use Searchable Names

Single letter names can ONLY be used as local variables inside short methods. The length of a name should correspond to the size of its scope.

6. Avoid Mental Mapping

Clarity is king. Professionals use their powers for good and write code that other can understand.

In general programmers are pretty smart people. Smart people sometimes like to show off their smarts by demonstrating their mental juggling abilities. After all, if you can reliably remember that r is the lower-cased version of the url with the host and scheme removed, then you must clearly be very smart.

7. Class Names should be nouns.

Class names should be nouns, not verbs.

8. Method Names should be verbs.

Method names should be verbs, not nouns. Accessors, mutators and predicates should be names get, set and is respectively.

9. Don't be cute

Choose clarity over entertainment value.

10. Use Solutions Domain Names

Where applicable use solution based names, that is computer science terms used by your fellow programmers, be as technical as needs be.

11. Use Problem Domain Names

Problem domain names are names relating to the project requirements that the client and project manager are familiar with. Separating solutions and problem domain concepts is part of the job of a good programmer and designer.

12. Add Meaningful Context

Where applicable refactor your code into classes, to avoid repetition and provide a context for each problem.