Over the years of programming, most of these commandments came naturally to me and I didn’t even realize there was a term for some of them.  Code is not something you just write and it gets executed by the machine. Ok, yeah, it’s something that you just write and gets executed by the machine. But, Code is poetry. I always want it to be a beautiful piece to write, a joy to refactor and a pleasure to be executed by the machine. Technically, it’s me talking to the machine, right…? (E.T phone home?)

So after walking thru long miles in the desert, splitting the Red Sea, coming back from the Mount Sinai, I bring you the 10 Commandments of Programmers.  (For those who don’t know, I’m referencing Moses in the bible)

DRY: (Don’t repeat yourself)

It’s fundamental in programming that allows you to not repeat yourself. When the DRY principle is applied successfully, a modification of any single element of a system does not change other logically-unrelated elements

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

KISS: (Keep it Simple Stupid)

A common problem among software engineers and developers today is that they tend to over complicate problems. Simplicity (and avoiding complexity) should always be a key goal. Simple code takes less time to write, has fewer bugs, and is easier to modify.

http://people.apache.org/~fhanik/kiss.html

Separation of Concerns

Separation of concern is the process of separating a computer program into distinct features that overlap in functionality as little as possible.

http://developers.redventures.com/2011/02/on-the-to-changes-separation-of-concerns/

Open/Close Principle

Software entities (classes, functions, etc.) should be open for extension, but closed for modification. In other words, don’t write classes that people can modify, write classes that people can extend. This is especially valuable in a production environment, where changes to source code may necessitate code reviews, unit tests, and other such procedures to qualify it for use in a product: code obeying the principle doesn’t change when it is extended, and therefore needs no such effort.

http://en.wikipedia.org/wiki/Open_Closed_Principle

Abstraction Principle.

Related to DRY is the abstraction principle “Each significant piece of functionality in a program should be implemented in just one place in the source code.”

http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

Single Responsibility Principle

In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

The reason it is important to keep a class focused on a single concern is that it makes the class more robust. Continuing with the foregoing example, if there is a change to the report compilation process, there is greater danger that the printing code will break if it is part of the same class.

http://en.wikipedia.org/wiki/Single_responsibility_principle

Code Reuse

Related to the DRY principle. Code reuse is the idea that a partial or complete computer program written at one time can be, should be, or is being used in another program written at a later time. The reuse of programming code is a common technique which attempts to save time and energy by reducing redundant work.

http://en.wikipedia.org/wiki/Code_reuse

Maximize Cohesion:

Code that has similar functionality should be found within the same component. Cohesion is a measure of how strongly-related or focused the responsibilities of a single module are. As applied to object-oriented programming, if the methods that serve the given class tend to be similar in many aspects, then the class is said to have high cohesion. In a highly-cohesive system, code readability and the likelihood of reuse is increased, while complexity is kept manageable.

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Minimize coupling:

Any section of code (code block, function, class, etc) should minimize the dependencies on other areas of code. This is achieved by using shared variables as little as possible. “Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability”

http://en.wikipedia.org/wiki/Coupling_(computer_programming)

POLA: Principle of Least Astonishment

Code should surprise the reader as little as possible. The means following standard conventions, code should do what the comments and name suggest, and potentially surprising side effects should be avoided as much as possible.

http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Follow these commandments and your code will be like heaven…