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?

Improve this question
6
  • 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, 2017 at 2: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, 2017 at 2: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, 2017 at 2: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, 2017 at 2:09
  • 1
    You may find softwareengineering.stackexchange.com/questions/189274/… helpful
    – mattnz
    Sep 22, 2017 at 9:15

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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, 2017 at 9: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, 2017 at 9:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.