How to prevent a programmer from writing bad code

Once, in one stupid article, one stupid habrayuser told one stupid idea . Its essence was that in his company a system was set up that controls the code written by programmers at the time of trying to add it to the repository and rejects code that does not pass by some criteria. I liked the idea. I (and 3 others) asked the author to develop a thought and write an article about it, but it never appeared. And I decided to figure it out myself.

Preamble

In the beginning I will explain why this idea captured me so much. With all the simplicity, it gives a whole bunch of advantages:

• Categorical code quality requirements
  This is the main difference from Vorningov and compiler errors, colleagues' advice, conclusions of code analysis tools - you can spit on them all and write any nonsense. And then the programmer simply CAN NOT commit bad code. At the same time, he has no chance to “cheat”, there is no hope for “what if no one notices,” there is no anger against the boss, who still noticed and stuck his face at the monitor. Arguing with a robot is like talking to a TV.
• Lazy programmers finally read the company's internal coding conventions.
  After all, they wrote something for sometime! And one thing when it was “read, please, and stick to” and another when “and you can work here if you don’t read and do not stick”
• Diligent programmers finally do not have to remember by heart coding conventions
  This is a document that is incomprehensible, who is incomprehensible, when and incomprehensibly, why he wrote more on need to know in memory! If you write something wrong, you will be automatically informed about it. Cool.
• Disappears part of the dialogue of senior and junior programmers in the style of "Vasya, well, you're a fool, I told you to write here like this ..."
  Not all, of course, but the part disappears. This will tell the robot.
• The cycles "Vasya put a space after the comma disappear -> Petya removed -> Vasya set-> Petya removed ... Petya and Vasya filled their faces for each other"
  Less conflicts - healthier nerves. To be offended by the robot is pointless.
• Comments appear in the right places in the code.
  Just because you can refuse to accept to the repository a class, interface, or method, before which no comment is written.
• Unloading senior programmers
  In some cases, the junior programmer gets an answer to the question “How should I write: one way or the other?” From an automatic system, without distracting older comrades from warcraft more important matters.

Implementation

I already thought that I would have to fence my bike. Nothing like this. Everything has been stolen before us.
Meet SVNStyleCop

Pros : installation in 5 minutes, stable operation, configuration flexibility.
Minuses : only Windows and only C # (Perhaps there are solutions for other languages ​​and platforms, but since Windows and C # are my version, I did not dig further).
')

Installation

1. Download the archive and unpack it anywhere on the computer where you have installed the SVN server.
2. Edit the SVNStyleCop.exe.config file, setting the path to the svnlook.exe utility (it is located in the SVN-server folder).
3. Edit the file SVNStyleCop.exe.config, writing in it which files will be analyzed. I just wrote
< pathPatterns >
< clear />
< add value =".*\.cs$" />
</ pathPatterns >

4. Put the SVNSettings.StyleCop file previously created by the StyleCop utility (program known, I will not describe in detail) in the folder of the SVNStyleCop file based on the company’s code-writing agreements. If you have no such agreements - do not admit it to anyone. Be ashamed and repent! Sit down and do it. You can not - contact some clever people .
5. Set the hook to the pre-commit event. In the SVN server of the Visual SVN, this is done from the context menu of the repository by inserting the contents of the pre-commit.cmd file from the SVNStyleCop distribution into the “Pre commit hook” section (remember to write valid paths in this file!).
6. We do some kind of stupidity that violates the rules, we try to commit and see something like


Voila, it works!

findings

With this thing is objectively better than without it. Everything that I wrote at the beginning of the article can really help save time, nerves and get some better quality code. Of course, the system described here is not a panacea for all ills, and the code can still be:

• Classes, methods, and variables, named for naming rules, but meaningless
• Comments with incomprehensible rubbish
• Essential architectural glitches
• Minor software bugs
• A bunch of everything else

The ideal is unattainable, but having a well-formed code that is guaranteed to meet at least some requirements and rules is better than simply relying on the consciousness of various irresponsible individuals in such a conscious matter as programming.