3

Our team is growing, and with it, discontent with common coding standards being imposed on developers with alternate (strong, bordering on religious) views on what constitutes a good coding style.

Examples of points of major contention:

  • Spaces vs tabs
  • Placement of braces (K&R, GNU, Linux kernel, Stroustrup etc)
  • The list goes on...

We would like to make this more flexible, allowing devs to adopt a style which suits their tastes.

Enforcing code in the repo conforms

We can install a pre-commit hook which will run a clang-format script on the changes about to be committed, enforcing all code in our repo conforms to a common style.

Allowing devs to work in their own style

Conceivably we could also install a post-checkout hook, allowing devs to apply their own style on the code.

The problem I see with this is that all the files will show up as "dirty" when compared with a git status or git diff etc.

Question:

Does tooling / a workflow exist whereby we can have the best of both worlds - a common style which is what files checked into the repo conform to, and user-specific styles which can be applied to local repos whilst under development, without "messing" with git?

1 Answers1

1

No. Although it might be technically possible converting the code between styles is never going to be 100% perfect.

So introducing an automated workflow which converts one way on check out and another on check in is going to be fraught with problems.

The way to deal with this problem is not to enforce a style. Everyone codes differently and styles change over time.

Devs have to learn to read, and work, in other people styles.

"I can't fix that bug because the code has tabs not spaces" is not an acceptable excuse.

"I corrected a spelling error.. and also refactored all the style to the way I like it" Is not an acceptable way to work.

"I wont accept the code you wrote because I don't like the style" Is just as bad.

All of these things waste time. Bitching about the best style down the pub is great fun. But spending hours enforcing it at work is a waste of time.

Ewan
  • 83,178