Coding standards and other IT practices
Many have to read and discuss different coding standards that limit the use of certain language constructs (goto, multiple class inheritance in C ++) or programming techniques (recursion, dynamic memory allocation after application initialization). With reference to C / C ++, the most well-known coding standards are MISRA , HICPP , Google C ++ Style Guide . Interesting is the article on Habré about 10 rules that allow NASA to write millions of lines of code with minimal errors .
Under the cut a bit of humor and serious reasoning about the use of various project management practices.
As stated, these standards allow writing cleaner and more readable code. They avoid certain types of coding errors, and facilitate the support of a software product.
However, in my opinion, undeservedly little attention is paid to how team members interact with each other. Well coordinated teamwork, effective communication between people is no less important for the success of the project. Misunderstanding, misinterpretation of the above, difficult to understand comments in the source code ultimately affect the quality of the software product.
')
In order to fill this gap, I propose to introduce 10 rules that would allow to avoid the most annoying situations arising from the unclear presentation of their thoughts:
And now absolutely serious.
There are rules that have universal and universal application. These are criminal and civil codes, safety rules, etc. Compliance with these rules sometimes allows you to avoid a certain kind of trouble, but these rules are in no way an instruction on how to achieve success.
There are also books and psychological courses on how to get rich quickly. But few people take it seriously. There are no seriously perceived rules or instructions guaranteeing the success of a project or success in personal life.
Does this mean that coding standards, which is different for practitioners (SCRUM, Continues Integration, Code Review, etc.) should not be taken seriously? Not at all. But we must understand that none of the practices in IT is not universal. No practice leads to a guaranteed increase in project efficiency. Only the accumulated experience, intuition and professionalism of managers and leading developers helps to make the right decision in each specific situation. Otherwise, our profession would not be so difficult and interesting.
If a manager talks about the need to use unit tests and argues this with beautiful diagrams, convincing that the cost of a bug exponentially depends on what stage of the project’s development this bug is found in - run away from this project or from this company. I have nothing against unit tests. However, the decision on whether to use them or not, and how to implement them, must proceed from the specifics of this project. Here is a partial list of questions that must be answered before making a decision:
If I need to cut something, I'm looking for an ax. But if I have an ax, and I know how to use it well, then this does not mean at all that I will run and look for what to cut. Similarly, with the rules / practices in programming. If I have a good practice, I will not demand that it be used everywhere.
Under the cut a bit of humor and serious reasoning about the use of various project management practices.
As stated, these standards allow writing cleaner and more readable code. They avoid certain types of coding errors, and facilitate the support of a software product.
However, in my opinion, undeservedly little attention is paid to how team members interact with each other. Well coordinated teamwork, effective communication between people is no less important for the success of the project. Misunderstanding, misinterpretation of the above, difficult to understand comments in the source code ultimately affect the quality of the software product.
')
In order to fill this gap, I propose to introduce 10 rules that would allow to avoid the most annoying situations arising from the unclear presentation of their thoughts:
- Do not use sentences longer than 15 words.
- Do not use more than three definitions to one noun.
- Do not use compound sentences.
- Each sentence must be subject and predicate.
- In one sentence is not allowed more than one parting turnover.
- A list of the 5000 most common words of the Russian language and professional terms should be prepared. Words and abbreviations that are not included in this list can be used only in agreement with the project management.
- The names of competing organizations can only be used in a negative context. In writing, reference to a competing organization must be accompanied by an explanation in brackets: “(competing with us, contacts with this organization must be limited)”.
- During business hours is not allowed to discuss company policy. There are many injustices in the world, and injustice, among other things, can come from our company. But this does not mean that the company should pay the time spent discussing this injustice.
- In case of inadmissible from the point of view of these rules of communication, the project management must be notified in writing.
- Taboo vocabulary is allowed to be used only for clarity and clarity of the presentation of their thoughts. Tabbed vocabulary is not allowed:
- If its use leads to a violation of the previous 9 points.
- To express your attitude to the content of the previous 9 points.
And now absolutely serious.
There are rules that have universal and universal application. These are criminal and civil codes, safety rules, etc. Compliance with these rules sometimes allows you to avoid a certain kind of trouble, but these rules are in no way an instruction on how to achieve success.
There are also books and psychological courses on how to get rich quickly. But few people take it seriously. There are no seriously perceived rules or instructions guaranteeing the success of a project or success in personal life.
Does this mean that coding standards, which is different for practitioners (SCRUM, Continues Integration, Code Review, etc.) should not be taken seriously? Not at all. But we must understand that none of the practices in IT is not universal. No practice leads to a guaranteed increase in project efficiency. Only the accumulated experience, intuition and professionalism of managers and leading developers helps to make the right decision in each specific situation. Otherwise, our profession would not be so difficult and interesting.
If a manager talks about the need to use unit tests and argues this with beautiful diagrams, convincing that the cost of a bug exponentially depends on what stage of the project’s development this bug is found in - run away from this project or from this company. I have nothing against unit tests. However, the decision on whether to use them or not, and how to implement them, must proceed from the specifics of this project. Here is a partial list of questions that must be answered before making a decision:
- How effective could unit tests be at a reasonable cost to implement them?
- Are there any other ways to test the application, and to what extent could they assume the goals that are pursued by the unit tests?
- To what extent are unit tests needed to effectively manage product quality (quality assurance)?
- Are there necessary funds in the project budget?
- How will unit test implementation affect the timeline for project implementation and to what extent is this critical?
- Is there a consensus in the team on this issue? If there is none, then what is more important: preserving the motivation of individual team members or the need to insist on the decision that managers consider correct?
If I need to cut something, I'm looking for an ax. But if I have an ax, and I know how to use it well, then this does not mean at all that I will run and look for what to cut. Similarly, with the rules / practices in programming. If I have a good practice, I will not demand that it be used everywhere.
Source: https://habr.com/ru/post/303786/
All Articles