Formatting code before committing to GIT

According to my understanding, when two developers are working on the same project, but using different coding styles, the built-in GIT method does not have built-in sources for combining. Please correct me if I am wrong.

Should I ask all developers to format the code with the same style?

Can I ask GIT to somehow format the code according to the same style? Can I get automatic code format using BitBucket?

+5
source share
3 answers

Should I ask all developers to format the code with the same style?

Yes, that's a good idea.

Projects usually have coding style rules to reduce the likelihood that this is a problem. They can vary from very loose to very strict. Guidelines include but are not limited to layout and formatting.

Most of the developers I worked with are happy to take the style of the project at hand, even if it is not their personal style. This is for the greater good. This facilitates readability and reduces the likelihood that “formatting fixes” will be mixed with real changes. If I edit code that does not have specific style rules, I will try to adhere to the existing style as much as possible.

The worst thing your developers can do is run all the source files using automatic formatting with their own layout rules before committing. This can lead to radical changes in places that were not actually related to the work they performed, and invariably lead to painful merge conflicts when you work across multiple branches.

Can I ask GIT to somehow format the code according to the same style? Can I get automatic code format using BitBucket?

I am going to answer this, disputing why you want to do this. Be careful about locking hooks that automatically format or reject based on the “wrong” style.

This is what code reviews are, and there are always exceptions in the code where a person will do it better (for example, in C ++, clang-format basically does an excellent job, but it sucks up almost everything related to a non-trivial list initializer). Forcing everyone to accept the interpretation of the machine is likely to just get in the way.

+4
source

As far as I know, BitBucket does not show this.

But I find it nice to find a common style to provide quick excange.

To do this, it is sometimes useful to use an IDE with built-in formatting functions and share settings, if possible. I think Eclipse would be a good solution, as many languages ​​are supported.

In my team case, we use MS Visual Studio and Allmann Style, as they are supported by autoformatting.

+1
source

You can install pre-commit- hook on each development machine and run one option of your choice that prevents the developer from committing if the source code does not comply with team standards.

The disadvantage is that these mechanisms can be crossed out by developers simply by not locating the hook locally.

Thus, linter must be started as part of the build process and make the build unsuccessful if the code is not formatted properly.

+1
source

Source: https://habr.com/ru/post/1257733/


All Articles