Coding Standards and Other IT Practices

You have to read and discuss various 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). In relation to C / C ++, the most famous coding standards are MISRA , HICPP , Google C ++ Style Guide . An article on Habré about 10 rules is also interesting , which allows NASA to write millions of lines of code with minimal errors .

Under the cut a bit of humor and serious reasoning about the application of various project management practices.

Allegedly, these standards allow you to write cleaner and easier to read code. They allow you to avoid some 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 team work, effective communication between people is no less important for the success of the project. Misunderstanding, incorrect interpretation of what was said, difficult to understand comments in the source code ultimately affect the quality of the software product.

In order to fill this gap, I propose introducing 10 rules that would allow us to avoid the most annoying situations arising from an unclear presentation of our thoughts:

  1. Do not use sentences longer than 15 words.
  2. Do not use more than three definitions for one noun.
  3. Do not use complex sentences.
  4. Each sentence should have a subject and a predicate.
  5. In one sentence, more than one participle turnover is not allowed.
  6. A list of the 5000 most common words of the Russian language and professional terms should be prepared. Words and abbreviations not included in this list may be used only by agreement with the project management.
  7. The names of competing organizations can only be used in a negative context. In a written speech, the mention of a competing organization must be accompanied by an explanation in brackets: “(competes with us, contacts with this organization should be limited).”
  8. During working hours, discussion of company policy is not allowed. There is a lot of injustice in the world, including injustice can come from our company. But this does not mean that the company should pay for the time spent discussing this injustice.
  9. In the event that communication is unacceptable from the point of view of these rules, the project management must be notified in writing.
  10. Taboo vocabulary may only be used for clarity and clarity of presentation of one’s thoughts. Taboo vocabulary is not allowed:
    • If its use violates the previous 9 points.
    • To express your attitude to the content of the previous 9 points.

And now, absolutely seriously.

There are rules that have universal and universal application. These are criminal and civil codes, safety rules, etc. Compliance with these rules can sometimes 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 quick. But few take this seriously. There are no seriously taken rules or instructions guaranteeing success of a project or success in personal life.

Does this mean that coding standards that are different from practices (SCRUM, Continues Integration, Code Review, etc.) should not be taken seriously? Not at all. But you need to understand that none of the practices in IT is 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 some manager talks about the need to use unit tests and argues this with beautiful diagrams, convincing that the cost of the bug exponentially depends on what stage of the development of the project this bug is found in - run from this project or from this company. I have nothing against unit tests. However, the decision about whether to use them or not, and how to implement them, should be based on the specifics of this project. Here is an incomplete list of questions that must be answered before deciding:

  • How effective could unit tests be at a reasonable cost to implement them?
  • Are there other ways to test the application, and to what extent could they take on the goals pursued by unit tests?
  • To what extent are unit tests necessary for effective quality assurance?
  • Are there any necessary funds in the project budget?
  • How the implementation of unit tests will affect the timing of the project and to what extent is it critical?
  • Is there a consensus in the team on this issue? If it is not, then what is the priority: maintaining the motivation of individual team members or the need to insist on the decision that managers consider the right one?

If I need to chop something, I'm looking for an ax. But if I have an ax, and I know how to use it well, this does not mean at all that I will run and look for something to cut. Similarly, with the rules / practices in programming. If I have a good command of any practice, I will not demand that it be applied everywhere.

Also popular now: