Do you think a software company should impose developers a coding-style? [closed]

Answer 1

These are the coding standards for a company I used to work for. They're well defined, and, while it took me a while to get used to them, meant that the code was readable by all of us, and uniform all the way through.

I do think coding standards are important within a company, if none are set, there are going to be clashes between developers, and issues with readability.

Having the code uniform all the way through presents a better code to the end user (so it looks as if it's written by one person - which, from an End Users point of view, it should - that person being "the company" and it also helps with readability within the team...

Answer 2

Modern IDEs let you define a formatting template. If there is a corporate standard, then develop a configuration file that defines all the formatting values you care about and make sure everyone runs the formatter before they check in their code. If you want to be even more rigorous about it you could add a commit hook for your version control system to indent the code before it is accepted.

Answer 3

Ever language has general standards that are used by the community. You should follow those as well as possible so that your code can be maintained by other people used to the language, but there's no need to be dictatorial about it.

The creation of an official standard is wrong because a company coding standard is usually too rigid, and unable to flow with the general community using the language.

If you're having a problem with a team member really be out there in coding style, that's an excellent thing for the group to gently suggest is not a good idea at a code review.

Answer 4

You want everybody reading and writing code in a standard way. There are two ways you can achieve this:

1. Clone a single developer several times and make sure they all go through the same training. Hopefully they should all be able to write the same codebase.
2. Give your existing developers explicit instruction on what you require. Tabs or spaces for indentation. Where braces sit. How to comment. Version-control commit guidelines.

The more you leave undefined, the higher the probability one of the developers will clash on style.

Answer 5

A common coding style promotes consistency and makes it easy for different people to easily understand, maintain and expand the whole code base, not only their own pieces. It also makes it easier for new people to learn the code faster. Thus, any team should have a guidelines on how the code is expected to be written.

Important guidelines include (in no particular order):

• whitespace and indentation
• standard comments - file, class or method headers
• naming convention - classes, interfaces, variables, namespaces, files
• code annotations
• project organization - folder structures, binaries
• standard libraries - what templates, generics, containers and so on to use
• error handling - exceptions, hresults, error codes
• threading and synchronization

Also, be wary of programmers that can't or won't adapt to the style of the team, no matter how bright they might be. If they don't play by one of the team rules, they probably won't play by other team rules as well.

Answer 6

Yes in terms of using a common naming standard as well as a common layout of classes and code behind files. Everything else is open.