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. – Bart van Ingen Schenau Nov 21 '16 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. – qwerty_so Nov 21 '16 at 10:09
  • Handling breaking API changes in lock-step seems like the biggest complication. – CodesInChaos Nov 21 '16 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 Nov 21 '16 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. – Harsha Jayamanna Nov 22 '16 at 6:12

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.

| improve this answer | |
  • 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. – Andrew Henle Nov 21 '16 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 Nov 21 '16 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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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