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

Question

If you think it shouldn't, explain why.

If yes, how deep should the guidelines be in your opinion? For example, indentation of code should be included?

Answer 1

I believe having a consistent codebase is important. It increases the maintainability of ur code. If everyone expects the same kind of code, they can easily read and understand it.

Besides it is not much of a hassle given today's IDEs and their autoformatting capabilities.

P.S: I have this annoying habit of putting my braces on the next line :). No one else seems to like it

Answer 2

In my opinion I think it's highly necessary with standards and style guides. Because when your code-base grows you will want to have it consistent.

As a side note, that is why I love Python; because it already imposes quite a lot of rules on how to structure your applications and such. Compare that with Perl, Ruby or whatever where you have an extreme freedom(which isn't that good in this case).

Answer 3

I think that programmers should be able to adapt to the style of other programmers. If a new programmer is unable to adapt, that usually means that the new programmer is too stubborn to use the style of the company. It would be nice if we could all do our own thing; however, if we all code along some bast guideline, it makes debugging and maintenance easier. This is only true if the standard is well thought out and not too restrictive.

While I don't agree with everything, this book contains an excellent starting point for standards

Answer 4

Related question: Is Programming Style important? How Important?

Answer 5

Yes, but within reason.

All modern IDEs offer one-keystroke code pretty-print, so the "indentation" point is quite irrelevant, in my opinion.

What is more important is to establish best practices: for example, use as little "out" or "ref" parameters as possible... In this example, you have 2 advantages: improves readability and also fixes a lot of mistakes (a lot of out parameters is a code smell and should probably be refactored).

Going beyond that is, in my honest opinion, a bit "anal" and unnecessarily annoying for the devs.

---

Good point by Hamish Smith:

Style is quite different from best practices. It's a shame that 'coding standards' tend to roll the two together. If people could keep the style part to a minimum and concentrate on best practices that would probably add more value.

Answer 6

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 7

I think a team (rather than a company) need to agree on a set of guidelines for reasonably consistent style. It makes it more straightforward for maintenance.

How deep? As shallow as you can agree on. The shorter and clearer it is the more likely it is that all the team members can agree to it and will abide by it.

Answer 8

The company should impose that some style should be followed. What style that is and how deep the guidelines are should be decided collectively by the developer community in the company.

I'd definitely lay down guidelines on braces, indentation, naming etc... You write code for readability and maintainability. Always assume someone else is going to read your code. There are tools that will auto magically format your code , and you can mandate that everyone uses the tool.

If you are on .Net look at stylecop, fxcop and Resharper

Answer 9

Yes, I think companies should. Developer may need to get used to the coding-style but in my opinion a good programmer should be able to work with any coding style. As Midhat said: It is important to have a consistent codebase.

I think this is also important for opensource projects, there is no supervisor to tell you how to write your code but many languages have specifications on how naming and organisation of your code should be. This helps a lot when integrating opensource components into your project.

Answer 10

Sure, guidelines are good, and unless it's badly-used Hungarian notation (ha!), it'll probably improve consistency and make reading other people's code easier. The guidelines should just be guidelines though, not strict rules enforced on programmers. You could tell me where to put my braces or not to use names like temp, but what you can't do is force me to have spaces around index values in array brackets (they tried once...)

Answer 11

There are plenty of good reasons for the standards to define the way the applications are developed and the way the code should look like. For example when everyone use the same standard an automatic style-checker could be used as a part of the project CI. Using the same standards improve code readability and helps to reduce the tension between team members about re-factoring the same code in different ways. Therefore:

• All the code developed by the particular team should follow precisely the same standard.
• All the code developed for a particular project should follow precisely the same standard.
• It is desirable that teams belonging to the same company use the same standard.

In an outsourcing company an exception could be made for a team working for a customer if the customer wants to enforce a standard of their own. In this case the team adopts the customer's standard which could be incompatible with the one used by their company.

Answer 12

Yes.

Coding standards are a common way of ensuring that code within a certain organization will follow the Principle of Least Surprise: consistency in standards starting from variable naming to indentation to curly brace use.

Coders having their own styles and their own standards will only produce a code-base that is inconsistent, confusing, and frustrating to read, especially on larger projects.

Answer 13

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 14

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 15

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

Not in a top-down manner. Developers in a software company should agree on a common coding style.

If yes, how deep should the guidelines be in your opinion?

They should only describe the differences from well-known conventions, trying to keep the deviation minimal. This is easy for languages like Python or Java, somewhat blurry for C/C++, and almost impossible for Perl and Ruby.

For example, indentation of code should be included?

Yes, it makes code much more readable. Keep indentation consistent in terms of spaces vs tabs and (if you opt for spaces) number of space characters. Also, agree on a margin (e.g. 76 chars or 120 chars) for long lines.

Answer 16

I would agree that consistency is key. You can't rely on IDE pretty-printing to save the day, because some of your developers may not like using an IDE, and because when you're trawling through a code base of thousands of source files, it's simply not feasible to pretty print all the files when you start working on them, and perform a roll-back afterwards so your VCS doesn't try to commit back all the changes (clogging the repository with needless updates that burden everyone).

I would suggest standardizing at least the following (in decreasing order of importance):

• Whitespace (it's easiest if you choose a style that conforms to the automatic pretty-printing of some shared tool)
• Naming (files and folders, classes, functions, variables, ...)
• Commenting (using a format that allows automatic documentation generation)

Answer 17

The best solution would be for IDEs to regard such formatting as meta data. For example, the opening curly brace position (current line or next line), indentation and white space around operators should be configurable without changing the source file.

Answer 18

My opinion:

• Some basic rules are good as it helps everyone to read and maintain the code
• Too many rules are bad as it stops developers innovating with clearer ways of laying out code
• Individual style can be useful to determine the history of a code file. Diff/blame tools can be used but the hint is still useful

Answer 19

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 20

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.

Answer 21

Every company should. Consistent coding style ensures higher readibility and maintainability of the codebase across whole your team.

The shop I work at does not have a unified coding standard, and I can say we (as a team) vastly suffer from that. When there is no will from the individuals (like in case of some of my colleagues), the team leader has to bang his fist on the table and impose some form of standardised coding guidelines.

Answer 22

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 23

Coding standards: YES. For reasons already covered in this thread.

Styling standards: NO. Your readable, is my bewildering junk, and vice versa. Good commenting and code factoring have a far greater benefit. Also gnu indent.

Answer 24

I like Ilya's answer because it incorporates the importance of readability, and the use of continuous integration as the enforcement mechanism. Hibri mentioned FxCop, and I think its use in the build process as one of the criteria for determining whether a build passes or fails would be more flexible and effective than merely documenting a standard.

Answer 25

I entirely agree that coding standards should be applied, and that it should almost always be at the team level. However there are a couple of exceptions.

If the team is writing code that is to be used by other teams (and here I mean that other teams will have to look at the source, not just use it as a library) then there are benefits to making common standards across all the teams using it. Similarly if the policy of the company is to frequently move programmers from one team to another, or is in a position where one team frequently wants to reuse code from another team then it is probably best to impose standards across the company.

Answer 26

Like others have mentioned, I think it needs to be by engineering or by the team--the company (i.e. business units) should not be involved in that sort of decision.

But one other thing I'd add is any rules that are implemented should be enforced by tools and not by people. Worst case scenario, IMO, is some over-zealous grammar snob (yes, we exist; I know because we can smell our own) writes some documentation outlining a set of coding guidelines which absolutely nobody actually reads or follows. They become obsolete over time, and as new people are added to the team and old people leave, they simply become stale.

Then, some conflict arises, and someone is put in the uncomfortable position of having to confront someone else about coding style--this sort of confrontation should be done by tools and not by people. In short, this method of enforcement is the least desirable, in my opinion, because it is far too easy to ignore and simply begs programmers to argue about stupid things.

A better option (again, IMO) is to have warnings thrown at compile time (or something similar), so long as your build environment supports this. It's not hard to configure this in VS.NET, but I'm unaware of other development environments that have similar features.

Answer 27

Style guidelines are extremely important, whether they're for design or development, because they speed the communication and performance of people who work collaboratively (or even alone, sequentially, as when picking up the pieces of an old project). Not having a system of convention within a company is just asking people to be as unproductive as they can. Most projects require collaboration, and even those that don't can be vulnerable to our natural desire to exercise our programming chops and keep current. Our desire to learn gets in the way of our consistency - which is a good thing in and of itself, but can drive a new employee crazy trying to learn the systems they're jumping in on.

Like any other system that's meant for good and not evil, the real power of the guide lies in the hands of its people. The developers themselves will determine what the essential and useful parts are and then, hopefully, use them.

Like the law. Or the English language.

Style guides should be as deep as they want to be - if it comes up in the brainstorm session, it should be included. It's odd how you worded the question because at the end of the day there is no way to "impose" a style guide because it's only a GUIDE.

RTFM, then glean the good stuff and get on with it.

Answer 28

I don't believe a dev team should have style guidelines they must follow as a general rule. There are exceptions, for example the use of <> vs. "" in #include statements, but these exceptions should come from necessity.

The most common reason I hear people use to explain why style guidelines are necessary is that code written in a common style is easier to maintain that code written in individual styles. I disagree. A professional programmer isn't going to be bogged down when they see this:

for( int n = 0; n < 42; ++42 ) {
 // blah
}

...when they are used to seeing this:

for(int n = 0; n < 42; ++42 )
{
 // blah
}

Moreover, I have found it's actually easier to maintain code in some cases if you can identify the programmer who wrote the original code by simply recognizing their style. Go ask them why they implemented the gizmo in such a convoluted way in 10 minutes instead of spending the better part of a day figuring out the very technical reason why they did something unexpected. True, the programmer should have commented the code to explain their reasoning, but in the real world programmers often don't.

Finally, if it takes Joe 10 minutes backspacing & moving his curly braces so that Bill can spend 3 fewer seconds looking at the code, did it really save any time to make Bill do something that doesn't come natural to him?

Answer 29

There are two types of conventions.

Type A conventions: "please do these, it is better"

and Type B: "please drive on the right hand side of the road", while it is okay to drive on the other side, as long as everyone does the same way.

There's no such thing as a separate team. All code in a good firm is connected somehow, and style should be consistent. It's easier to get yourself used to one new style than to twenty different styles.

Also, a new developer should be able to respect the practices of existing codebase and to follow them.