Design Principle: principles that excellent programs should follow

This article explains the principles that programming should follow.
I just want to give a rough translation, or take a closer look at the English language so that it will not be misled by others.

The principles of good programming
By Christopher Diggins

Today's post is a lightly edited repost from my blog at the area, a web-site dedicated to users of Autodesk
Media and entertainment products. I came up with this list of principles to help with a recent C # training I gave, and I thought that members of the artima.com community cocould appreciate these principles and have some interesting insights to share.

Principles of Good Programming

The principles of good programming are closely related to principles of good design and engineering. the following programming principles have helped me over the years become a better programmer, and I believe can help any developer become more efficient
And to produce code which is easier to maintain and that has fewer defects.

Avoid repetition Principle

Dry-Don't repeat yourself-This is probably the single most fundamental tenet in programming is to avoid repetition. extends programming constructs exist solely for that purpose (e.g. loops, functions, classes, and more ). as soon as you
Start repeating yourself (e.g. A long expression, a series of statements, same concept) Create a New Login action. http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstract principles

Export Action Principle-Related to dry is the role action principle "each significant piece of functionality in a program shocould be implemented in just one place in the source code." http://en.wikipedia.org/wiki/Abstraction_principle_ (programming)

KISS Principle, keep the code simple

Kiss (Keep it simple, stupid !)-Simplicity (and Avoiding complexity) shocould always be a key goal. Simple code takes less time to write, has fewer bugs, and is easier to modify. http://en.wikipedia.org/wiki/KISS_principle

Avoid creating unnecessary functions, and avoid superfluous image painting.

Avoid creating a yagni (you aren't going to need it)-You shocould try not to add functionality until you need it. http://en.wikipedia.org/wiki/YAGNI

Simplify design by doing the simplest thing

Do the simplest thing that cocould possibly work-A good question to ask one's self when programming is "what is the simplest thing that cocould possibly work ?" This helps keep us on the path towards simplicity in the design. http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Keep code as common

Don't make me think-This is actually the title of a book by Steve Krug on web usability that is also relevant in programming. the point is that code shocould be easily read and understood with a minimum of effort required. if code requires
Too much thinking from an observer to understand, then it can probably stand to be simplifiedhttp: // www.sensible.com/dmmt.html

The principle of opening/closing: opening/closing the modification and opening the extension.

Open/closed Principle-Software entities (classes, modules, functions, etc .) shocould 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. http://en.wikipedia.org/wiki/Open_Closed_Principle

Ensure code maintainability

Write code for the maintainer-Almost any code that is worth writing is worth maintaining in the future, either by you or by someone else. the future you who has to maintain code often remembers as much of the Code, as a complete stranger,
So you might as well always write for someone else. A memorable way to remember this is "always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live. http://c2.com/cgi/wiki? Codeforthemaintainer

Do not make things that surprise users, such as a gorgeous interface.

Principle of least astonishment-The principle of least astonishment is usually referenced in regards to the user interface, but the same principle applies to written code. Code shocould surprise the reader as little as possible. The means
Following standard conventions, code shocould do what the comments and name suggest, and potentially surprising side effects shocould be avoided as much as possible. http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsibility Principle

Single Responsibility Principle-A component of code (e.g. Class or function) shocould perform a single well defined task. http://en.wikipedia.org/wiki/Single_responsibility_principle

Low Coupling

Minimize Coupling-Any section of code (code block, function, class, etc) shocould 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)

High Cohesion

Maximize cohesion-Code that has similar functionality shocould be found within the same component. http://en.wikipedia.org/wiki/Cohesion_ (computer_science)

Maximum possible hidden Implementation Details

Hide Implementation Details-Hiding Implementation Details allows change to the implementation of a code component while minimally affecting any other modules that use that component. http://en.wikipedia.org/wiki/Information_Hiding

Dimit Law

Law of Demeter-Code components shocould only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.) http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature code optimization

Avoid Premature Optimization-Don't even think about optimization unless your code is working, but slower than you want. only then shoshould you start thinking about optimizing, and then only with the aid of empirical data. "We shoshould forget
About small efficiencies, say about 97% of the time: premature optimization is the root of all edevil "-Donald knuth. http://en.wikipedia.org/wiki/Program_optimization

Code reusability

Code reuse is good-Not very pithy, but as good a principle as any other. reusing code improves code reliability and decrease development time. http://en.wikipedia.org/wiki/Code_reuse

Functions in different fields should be composed of different codes and minimum overlap modules.

Separation of concerns-Different Areas of functionality shocould be managed by distinct and minimally overlapping modules of code. http://en.wikipedia.org/wiki/Separation_of_concerns

Adapt to changes

Embrace change-This is the subtitle of a book by Kent Beck, and is also considered a tenet of extreme programming and the Agile Methodology in general. export other principles are based on the concept that you shoshould perform CT and welcome change.
In fact very old software engineering principles like minimizing coupling are related directly to the requirement of making code easier to change. whether or not you are an extreme programming practitioner, this approach to writing code just makes sense. http://www.amazon.com/gp/product/0321278658