Here gives the 10 shouldn't criticize others coding style:

1. Open source code is in order to satisfy the needs and interests, not for beautiful.

2. The code may be subject to the developer to use the language, or the most familiar language.

3. Since there are different thinking way, might not have the same code and design style.

4. Not an absolute standard.

5. Open source code writers should remain modest and keep the work respect for others.

6. Don't take people to code.

7. Refactoring is very effective, but not for the reconstruction and refactoring.

8. Let the program work properly is more important than let the program to read.

9. Even in the industrial development of code review, code style also is not the most important.

10. Instead of blaming others, start work as oneself."

CodePudding user response:

Unified the majority of them, the code style is unified, in many cases is habit problem, there is no relative problems
But the article 8, the readability of the code is very important, especially in the case of engineering project management

CodePudding user response:

CodePudding user response:

1. Open source code is in order to satisfy the needs and interests, not for beautiful.
//open source is a means, not the goal, the purpose is to promote technological progress, open source is the most important attitude and sincerity, so you should take care of most people,
//"standardization" as far as possible, as the product of the documents are written in English, because want to take care of the most people understand English, on the other hand, the use of "standard"
//the most groups they identify themselves as beneficiaries,

2. The code may be subject to the developer to use the language, or the most familiar language.
//each language coding style is to follow the same concept, which is readable, easy maintenance,

3. Since there are different thinking way, might not have the same code and design style.
//code "writing" and "design" or discriminating, follows the logical design, write normative,


4. Not an absolute standard.
//as long as can achieve "readability, easy maintainability" idea, if your code style is more in line with the group concept,
//that people will naturally to be near you, to need to stress is that "readable, easy maintenance" is not a hard sell,
Is//that the requirements from the instinct and yearning,

5. Open source code writers should remain modest and keep the work respect for others.
//modesty and respect is a code of conduct, without specifically,


6. Don't take people to code.
//should go to tell the interviewer,


7. Refactoring is very effective, but not for the reconstruction and refactoring.
//agree that refactoring is means is not an end, but the reason why the same at that time understand up again?


8. Let the program work properly is more important than let the program to read.
//code to work is the premise of it, that doesn't work the code name code name is not garbled, since this is the code you can't have readability,
//valuable code, half the time running, half the time in the maintenance, that is to say, program consists of two parts, complete the work and maintenance,
//and maintenance costs are generally higher than the cost of production, incredibly so disdain readability, is really a wonderful work,


9. Even in the industrial development of code review, code style also is not the most important.
//that I have no right to speak,


10. Instead of blaming others, start work as oneself.
//should go to tell your boss,

CodePudding user response:

Mark

CodePudding user response:

Have no problems in view of the open source code is

If company for product code style to unification, must ask readability,
3. Since there are different thinking way, might not have the same code and design style . It is as unity,

CodePudding user response:

Team programming, design problems can speak, ideas can also tell, code style, of course, also can speak; Just don't as a key,

Don't tolerate only a code style, it is like not only to understand a programming language, but will not tolerate bad code, especially that of a see see bad code, the code is good or bad, in many cases associated with ideas (implementation),

Together to discuss common growth of the group, and their code style naturally tend to be close, because he write code group personnel to see,

Hate only speak style (not only the code specification, documentation, including linguistic behavior specification) and task, don't discuss design interface and implementation approach of the team,
Hate messy code, still has more than one thousand lines of function, although sometimes have to face,