We have several teams in our section of the organization and each will be give features of the system to develop and deploy.

A feature includes back-end work as well as front-end work. All the teams will be using two code bases. Those are back-end code base and front-end code base.

Requirement is to create set of guide lines to follow when coding.

  1. Rules to follow when committing. Styles and standards to follow when coding.
  2. Instruction to follow when branching.
  3. Styles and standards to follow when putting comments in the code.
  4. Styles and standards to follow when changing the structure of the code and etc.

Purpose of these rules will be to maintain the quality of the code.Are there any guide lines to follow when setting up these kind of rules?

  • 1
    Main guideline: Try to keep the style & process as close as possible to what the developers are currently used to. Commented Nov 21, 2016 at 9:50
  • 1
    Finding a common sense here can be quite annoying. Get the picture of what @BartvanIngenSchenau talks about and set it in concrete. Get the management to sign and authorize the rules.
    – user188153
    Commented Nov 21, 2016 at 10:09
  • Handling breaking API changes in lock-step seems like the biggest complication. Commented Nov 21, 2016 at 10:19
  • 1
    If several team working on single code base then it shouldn't be a several it should be a one team. What's the point making different kind of team if all team will be working on one code base?
    – kirie
    Commented Nov 21, 2016 at 11:22
  • @kirie we follow agile and management has decided to create several teams, each containing few members. Currently we have two teams with so many members. And also we we are moving to method where a team will be responsible for a feature of the system(fornt-end work and back-end work) rather than a single team taking over the back-end or the front-end. Commented Nov 22, 2016 at 6:12

2 Answers 2


Are there any guide lines to follow when setting up these kind of rules?


  1. Don't impose eg one team's rules on everyone else, or make up brand new rules that no team currently uses. Try to reach a consensus on any current practices and use those as your rules

  2. Automate everything (as no one will read your rules)

For example, you might want your branching policy to be "create a branch named with the task number", in which case create a simple internal app that every can use that does this correct naming for them.

Likewise with coding standards, as much as possible use automated tools to enforce them and have them run automatically on check-in, or straight after via a CI process.

To clarify enforcing code format rules. Whilst automatic tools for formatting exist, they should be treated with care. Many languages though have "linting" tools that can analyse code for conflicts with formatting rules. I'd personally favour them instead, but that's very much a personal preference thing.

  • I'm not sure I like the idea of running automatic code-formatting tools on code at check-in. Some corner cases might result in some strangely-formatted code that might never get noticed until the next developer checks it out. Perhaps run such a formatter to create a copy of the file being checked in, and block/fail the check-in if the formatter produces any difference between its output file and the candidate check-in file? That would prevent any input the formatter can't handle from being preserved as a mess in the code base. Commented Nov 21, 2016 at 15:57
  • @AndrewHenle, ah good point. My answer wasn't clear on that point. Like you, I'd be wary of automatic formatting tools and would favour linting tools that report format violations as code errors and the like. I've updated my answer to reflect that.
    – David Arno
    Commented Nov 21, 2016 at 16:27

In addition to David Arno's excellent answer, use existing conventions when the team lacks a firm opinion. For example, on how to comment, hopefully your language has conventions as clear as python's PEP 257.

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.