Code specification contention--[personal WEEK2 jobs]

all four of these questions are from http://goodmath.scientopia.org/2011/07/14/stuff-everyone-should-do-part-2-coding-standards/ .

I have a rebuttal to these four questions, and here's my reason.

Q1: These codes are all things that are wasted in the bureaucratic system that waste everyone's programming time, affect people's development efficiency, and waste time.

A1:

In fact, it is simple, because the unified coding specification can create code-style consistency. The code that every developer in the team sees, whether written by themselves or written by others, will have a unified code structure with the same naming conventions. This code gives people the pleasure of reading the source code: You look at other people's codes just like your own code! of course, good comments are necessary, otherwise the code of others, even if they write their own code, one months later estimated that only God can understand.

I think there is a good thing to do in this way is "once made, for life". such as the development of a large commercial software, if the beginning of the unified code specification, then even if the original developer left, the new people can be taken from the unified specification of the rapid start and the same specifications under the source code modification. By following a consistent style, This specification enables other developers to intervene, help, maintain, or develop new developments efficiently and in an orderly way . and code specifications with very high reusability, in the continuous practice of summing up a set of good set of norms, can be in many large-scale software development before the constraints and provisions, so that in the future of each software development process has a very good impact.

Also, a unified style facilitates the search for bugs. In the process of code review, standardized code is a great help in improving the efficiency of the review. Imagine how good you feel when you look at this pile of code review that you think is like crap. Do you still want to look for bugs seriously? Look don't want to see, still can let a person good review!

In the end, I think it's a personal gain for programmers. The unification of coding norms is more advantageous to the development of the programmer's own sense of ownership , which I think is one of the major differences between engineers and yards farmers (purely personal opinion). Being able to take responsibility for your own code enables you to develop higher-quality code, which is also an exercise for the ability of the engineer itself. If developers never care about the code's subsequent maintenance, regardless of the source's readability, code code can only be counted as a job and never an art.

Q2: I am an artist, a craftsman, I have my own norms and principles. A2:

The coding specifications followed in the code writing process sometimes seem to be a writer's style of writing in a book. What they have in common, of course, is that they tend to be overlooked, and only a handful of people can follow them strictly, and they are often successful in the end. But of course they are also very different: writers write books as one-man combat, and engineering pushes most of the time to team work.

The scenario described in the question is common in many software development processes. Many programmers are proud of their coding style, some even for code. Writing a logically clear code is complicated and difficult to understand--and that could make a big contribution to his position in the department manager's mind. or just to install X (cover your face)? ... Just teasing: D. Complex obscure code, or syntactic quirks, the basic unreadable code, is difficult to get the approval and maintenance of others. The ability to be creative and whether to stick to the quirks of their own norms does not have a half-dime relationship.

Of course, the traditional software engineering development There are many examples of individual combat, such as Ken Thompson, Linus Torvalds, and Donald Ervin Knuth professor "Typesetting does not make a Tex," the people relish the story. Indeed, the world-renowned hacker that emerged in the last century are indeed examples of programmers who have shocked the world with their own power and are real programmers.

However, they are artists, but we are not . Artists are often inspired and creative, but artists have a premise: they have to have enough for the day and more practice. In other words: first you need to be a craftsman, then you may be an artist.

As a solo developer, eager to become a superhero and independent development software, in the complexity of modern software engineering, the basic is not feasible. At the beginning of the development, we may feel very efficient because we can develop norms and principles at will: do not need to be coupled with the module developed by others, do not need to "forced" to write comments, do not need to spend "a lot of time" to change their original coding specifications to adapt to the team coding standards, do not need to do a lot of "

but one of the biggest benefits of being an independent developer may be that the biggest downside is two words: freedom. the longer the time, the more difficult it is for a standalone developer to publish a software. Unless the developer itself has a detailed knowledge of the technology, feasible solutions and extensive development experience. But the reality is often cruel, everyone will have their own blind spots of thinking, in the development of this can not be avoided. My point of view is not that someone cannot develop a small software, I mean, before a person is paying enough to become an "artist," the software development process is often forced to stop because of the limitations of the design and the inaccuracy of the solution.

Moreover, for the development process of the software, unless the developer is a very self-disciplined person, you may encounter a big bug developers will lose the follow-up development and maintenance ideas. But if you are in a team, you can solve the bug together, at least without losing the confidence of the developer to follow up.

So, every developer needs to seriously consider whether he or she is really an "artist" in engineering development before they want to keep "their own rules and principles". if not, then you have to follow the code of the team, and if you wait until you become an "artist," the developer should understand the importance of the consistency of the team coding specifications.

Not finished ...

Code specification contention--[personal WEEK2 jobs]