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?

Steve Lorimer
  • 147
  • 3
  • 3
    Unrelated, but why are strong religious beliefs being placated here? There genuinely is not that much benefit in letting people do their own thing - common style standards exist to help new developers, and allowing user-specific styling defeats that purpose. It just seems like a lot of work for no net benefit - you may as well not have conventions at all. I fail to see how investing time in this approach helps your business (not just your team) in any way. – Akshat Mahajan Sep 22 '17 at 02:00
  • @AkshatMahajan the code in the repo will always be in the same common style. Additionally the presumption is that eventually people will converge on the common style which is used in the pre-commit hook, as that is the style they will see when pulling code, when looking at pull requests etc. However, for those who feel so strongly about it that they feel they must apply their own personal formatting on their local branches, I'm interested in finding a workflow which helps them achieve this - hence the question – Steve Lorimer Sep 22 '17 at 02:05
  • 3
    I suppose if that's what you feel is necessary, but if you have religious dogmatism in your team, you have a bigger problem than figuring out workflows... – Akshat Mahajan Sep 22 '17 at 02:07
  • @AkshatMahajan fair enough - I see your point - but if we can accommodate others' styles when they're working locally, whilst still achieving the ultimate aim which is a zero-pain automated common formatting in-repo, that would be first prize! – Steve Lorimer Sep 22 '17 at 02:09
  • You are trying to solve a social problem by dictating rules and strict unrelenting enforcement - there is only one way that will end. Common formatting though pre-commit or post-commit hooks should only be done for convenience, with agreement, once everyone agrees to the common format. – mattnz Sep 22 '17 at 09:12
  • 1
    You may find https://softwareengineering.stackexchange.com/questions/189274/is-imposing-the-same-code-format-for-all-developers-a-good-idea/189277#189277 helpful – mattnz Sep 22 '17 at 09:15

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
  • 70,664
  • 5
  • 76
  • 161
  • 3
    If devs have to learn to work in other people styles then it seems totally reasonable to enforce a style. At least the whole code will be consistent in style, which certainly isn't a waste of time since it reduces the effect of surprise when opening a piece of code for the first time. – Tim Sep 22 '17 at 09:51
  • untill you change project, or company, or the code was written before the style guide, or the style guide was updated or ignored. – Ewan Sep 22 '17 at 09:56