The principles of good programming are closely related to the principles of good design and
engineering. These programming principles have helped me become a successful programmer over the years, and I believe they will help any developer become more efficient and write code that is even easier to maintain and has fewer defects.
DRY - Don't repeat yourself - This is probably the most fundamental principle in programming, it is necessary to avoid repetition. Many software constructs exist solely for these purposes
(i.e. loops, functions, classes, etc.). As soon as you start repeating yourself (e.g. long expressions, a series of identical conditions, similar entities), create new abstractions
http://en.wikipedia.org/wiki/Don't_repeat_yourself
Abstraction Principle – Refers to the DRY abstraction principle: “Every significant piece of functionality in a program should be implemented in only one place in the source code”
http://en.wikipedia.org/wiki/Abstraction_principle_ (programming)
KISS (Keep it simple, stupid!) – Simplicity (and avoiding complexity) should always be a key goal. Simple code takes less time to write, has fewer errors, and is easier to change.
http://en.wikipedia.org/wiki/KISS_principle
Avoid Creating a YAGNI (You aren't going to need it) –
Don't create functionality that you don't need right now
http://en.wikipedia .org/wiki/YAGNI
Do the simplest thing that could possibly work (Look for the simplest solution that could work) – When programming, immediately ask yourself the question: “What is the simplest thing that could work right away?” This helps keep us on the path to ease of development
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
Don't make me think - This is actually the title of Steve Krug's book on web usability, which has directly related to programming
The point is that the code should be easy to read and understand with a minimum of effort. If the code is difficult to understand, then it probably needs to be simplified.
http://www.sensible.com/dmmt.html
Open/Closed Principle (Open/Closed Principle) - Software entities (classes, modules, functions) should be open for extension but closed for modification.In other words, don't write classes that people will change, create classes that people can extend
http:/ /en.wikipedia.org/wiki/Open_Closed_Principle
Write Code for the Maintainer –
Almost any code you write will have to be maintained in the future by you or someone else. In the future, when you return to the code, you will find that most of it is completely unfamiliar to you, so try to write as if for someone else.
“Write code as if it would be accompanied by a violent psychopath who knows where you live.” (Steve McConnell "The Perfect Code")
http://c2.com/cgi/wiki?CodeForTheMaintainer
Principle of least astonishment - The principle of least astonishment is typically referred to in relation to the user interface, but the same principle applies and to writing code. The code should surprise the reader as little as possible. This means that standard code formatting conventions must be followed, the code must do what it says in its title and comments, and side effects must be avoided as much as possible.
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
Single Responsibility Principle –
A code component (i.e. a class or function) must perform a single, clearly defined task.
http://en.wikipedia.org/wiki/Single_responsibility_principle
Minimize Coupling – Any piece of code (block code, function code, class code, etc.) should minimize dependencies on other pieces of code. This is achieved by using shared variables as little as possible. “Loose coupling is often a sign of a well-structured computer system and good architecture, and when combined with high cohesion, the main goals of high readability and maintainability are achieved.”
http://en.wikipedia.org/wiki/Coupling_ (computer_programming)
Maximize Cohesion - Code that has similar functionality should be in the same component.
http://en.wikipedia.org/wiki/Cohesion_ (computer_science)
Hide Implementation Details - Hiding implementation details allows you to make changes to a component's code with minimal impact to other modules that use that component.
http://en.wikipedia.org/wiki/Information_Hiding
Law of Demeter – Code components should only interact with their immediate relationships (e.g., the classes they inherit from, the objects they contain, objects passed in arguments, etc.)
http://en.wikipedia.org/wiki/Law_of_Demeter
Avoid Premature Optimization– Don’t even think about optimization if your code works, but it’s slower than you want. Only then can you start thinking about optimization, and only based on the experience gained.
We should forget about small efficiency improvements, say about 97% of the time: premature optimization is the root of all ills. © Donald Knuth
http://en.wikipedia.org/wiki/Program_optimization
Code Reuse is Good – Not very meaningful, but also a good principle like all the others. Code reuse improves reliability and reduces development time.
http://en.wikipedia.org/wiki/Code_reuse
Separation of Concerns – Different areas of functionality should be managed by different and minimally overlapping code modules.
http://en.wikipedia.org/wiki/Separation_of_concerns
Embrace Change - This is the subtitle of a book by Kent Beck that explores the principles of Extreme Programming and general agile development techniques. Many other principles are based on the concept that you should expect and welcome change. In fact, very old design principles, like minimizing coupling, are directly intended to make code easier to change. Even if you are not a fan of extreme programming, this approach to writing code still makes sense.
http://www.amazon.com/gp/product/0321278658
engineering. These programming principles have helped me become a successful programmer over the years, and I believe they will help any developer become more efficient and write code that is even easier to maintain and has fewer defects.
DRY - Don't repeat yourself - This is probably the most fundamental principle in programming, it is necessary to avoid repetition. Many software constructs exist solely for these purposes
(i.e. loops, functions, classes, etc.). As soon as you start repeating yourself (e.g. long expressions, a series of identical conditions, similar entities), create new abstractions
http://en.wikipedia.org/wiki/Don't_repeat_yourself
Abstraction Principle – Refers to the DRY abstraction principle: “Every significant piece of functionality in a program should be implemented in only one place in the source code”
http://en.wikipedia.org/wiki/Abstraction_principle_ (programming)
KISS (Keep it simple, stupid!) – Simplicity (and avoiding complexity) should always be a key goal. Simple code takes less time to write, has fewer errors, and is easier to change.
http://en.wikipedia.org/wiki/KISS_principle
Avoid Creating a YAGNI (You aren't going to need it) –
Don't create functionality that you don't need right now
http://en.wikipedia .org/wiki/YAGNI
Do the simplest thing that could possibly work (Look for the simplest solution that could work) – When programming, immediately ask yourself the question: “What is the simplest thing that could work right away?” This helps keep us on the path to ease of development
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
Don't make me think - This is actually the title of Steve Krug's book on web usability, which has directly related to programming
The point is that the code should be easy to read and understand with a minimum of effort. If the code is difficult to understand, then it probably needs to be simplified.
http://www.sensible.com/dmmt.html
Open/Closed Principle (Open/Closed Principle) - Software entities (classes, modules, functions) should be open for extension but closed for modification.In other words, don't write classes that people will change, create classes that people can extend
http:/ /en.wikipedia.org/wiki/Open_Closed_Principle
Write Code for the Maintainer –
Almost any code you write will have to be maintained in the future by you or someone else. In the future, when you return to the code, you will find that most of it is completely unfamiliar to you, so try to write as if for someone else.
“Write code as if it would be accompanied by a violent psychopath who knows where you live.” (Steve McConnell "The Perfect Code")
http://c2.com/cgi/wiki?CodeForTheMaintainer
Principle of least astonishment - The principle of least astonishment is typically referred to in relation to the user interface, but the same principle applies and to writing code. The code should surprise the reader as little as possible. This means that standard code formatting conventions must be followed, the code must do what it says in its title and comments, and side effects must be avoided as much as possible.
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
Single Responsibility Principle –
A code component (i.e. a class or function) must perform a single, clearly defined task.
http://en.wikipedia.org/wiki/Single_responsibility_principle
Minimize Coupling – Any piece of code (block code, function code, class code, etc.) should minimize dependencies on other pieces of code. This is achieved by using shared variables as little as possible. “Loose coupling is often a sign of a well-structured computer system and good architecture, and when combined with high cohesion, the main goals of high readability and maintainability are achieved.”
http://en.wikipedia.org/wiki/Coupling_ (computer_programming)
Maximize Cohesion - Code that has similar functionality should be in the same component.
http://en.wikipedia.org/wiki/Cohesion_ (computer_science)
Hide Implementation Details - Hiding implementation details allows you to make changes to a component's code with minimal impact to other modules that use that component.
http://en.wikipedia.org/wiki/Information_Hiding
Law of Demeter – Code components should only interact with their immediate relationships (e.g., the classes they inherit from, the objects they contain, objects passed in arguments, etc.)
http://en.wikipedia.org/wiki/Law_of_Demeter
Avoid Premature Optimization– Don’t even think about optimization if your code works, but it’s slower than you want. Only then can you start thinking about optimization, and only based on the experience gained.
We should forget about small efficiency improvements, say about 97% of the time: premature optimization is the root of all ills. © Donald Knuth
http://en.wikipedia.org/wiki/Program_optimization
Code Reuse is Good – Not very meaningful, but also a good principle like all the others. Code reuse improves reliability and reduces development time.
http://en.wikipedia.org/wiki/Code_reuse
Separation of Concerns – Different areas of functionality should be managed by different and minimally overlapping code modules.
http://en.wikipedia.org/wiki/Separation_of_concerns
Embrace Change - This is the subtitle of a book by Kent Beck that explores the principles of Extreme Programming and general agile development techniques. Many other principles are based on the concept that you should expect and welcome change. In fact, very old design principles, like minimizing coupling, are directly intended to make code easier to change. Even if you are not a fan of extreme programming, this approach to writing code still makes sense.
http://www.amazon.com/gp/product/0321278658