Should I expect programming teams to follow a strict coding standard? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

I am personally a very big fan of following internal coding standards when working with a group of developers. I feel like it brings continuity to the code and allows people to more easily expand the code base, switch off work, and assist each other with difficult tasks. On the other hand I am aware that a large set of people are of the belief that as long as the coding gets done on time and it works that we should embrace the differences in the individual coder’s style.

Seeing both sides of the coin I find it hard to decide if somewhat stifling a programmers style is worth the (sometimes marginal and sometimes grand) benefit gained by having a fairly standards compliant code base. Especially when working within the Agile development framework where speed is important I think it becomes an even more important question.

To exacerbate the situation I am a PHP programmer, so you are very rarely going to meet two coders with t开发者_JAVA百科he same style since it is largely a self-taught discipline.

Is it better to have a loose set of standards as suggestions and only mandate the very important items (Like restricting Hungarian notation in variable names) or is it better to be iron fisted and require indents be tabs and not spaces and that brackets always be on a line of their own.

Edit:

Should have seen my mistake in the question--I guess I am interested in how strict the standard should be--should they have a lot of latitude or should I lock it down tight?

---

In practice, I've found that it's far more important to be strict when it comes to naming than to be strict about formatting.

Luckily, it's far easier to put together a set of standards for naming.

As long as someone's code isn't way off the beaten path as far as readability goes, I don't see why it would be necessary to restrict their own personal style.

---

Whatever you say your standards are, your actual standards are what you enforce.

No one's creativity is harmed by rules about how many spaces nor where the braces go. On the other hand, it may be worthwhile to get an editor that will replace tabs with spaces (or vice versa).

One problem with allowing all developers to express their creativity through formatting is that that's what they'll do: spend time reformatting stuff to match their ideas, rather than refactoring.

You don't want that.

Make sure that code is reviewed and that part of the review is format. If you have developers who get bent out of shape by this, they're probably not so spectacular as they think themselves.

---

Yes, a team (let it be a professional or open source team or hobby group, or other) should have its coding rules which each and every member follow, otherwise it will be a big mess; Even more if you don't use a source control system (which, even as a single developer, is helpful anyways).

edit to reflect OPs edit

There are certain areas you don't have to be that strict (e.g. formatting, spaces, which you can "enforce" by a piece of software in your source control commits, so while they are coding, they can do however they like, but the moment it reaches source control, it gets normalized), but other areas, especially naming conventions need to be very strict, as this is not changeable by a program that easily. For example, use descriptive names instead of single letter

for (int i = 0; i<int.MaxValue;i++)

vs

for(int count = 0; count<int.MaxValue;count++).

The latter is way more readable and descriptive than the first.

Whatever shape or form your conventions are, be sure that everybody can give their own oppinion when you implement them, but don't spend too much time discussing it. That way, people can state their own oppinion and don't feel stepped over.

---

Firstly, since you bring up Hungarian notation, here is the obligatory link to Joel's Making Wrong Code Look Wrong article. :-) It discusses using Hungarian in what Joel considers good and bad ways.

In principal, I'll agree that a group standard is a good thing. In practice, my experience has been that they're difficult to agree to - e.g. one person will get religious about opening parens being at the end of the line while another will be just as religious about having them on a line by themselves. They're also difficult to enforce, especially if there are no code reviews or other mechanism for making sure the code conforms to the standard. I'd say strive for what works best; e.g. in my previous example, either method seems reasonably readable, so maybe let that slide, but if you're using a variable naming convention don't let it slide when someone tries to use 'a' for a variable containing a customer name!

---

I'm not sure that anybody covered this yet, but in my experience the most important aspect of coding standards is that everyone in the team agrees with them. Yes, it is really hard to get a group of smart programmers to all agree on something as contentious as coding standards but I find out it pays dividends to discuss it until something workable is agreed.

In a previous role, I had a variety of skilled programmers using a number of different platforms for development on a variety of targets. The work was mostly C-based and was complex. We agreed things like:

1. Tabs rather than spaces.
2. C++ bracing style (separate lines)
3. Always putting braces for code blocks.
4. Function naming is Module_VerbObject[Adjective], e.g. GraphicsContext_DrawRectangle()
5. include statements in a specific order
6. Comments where functions more than 10 lines
7. Specific keywords in comments (OPTIMISE, DONOTTOUCH, etc)
8. No swearing, naming/shaming/blaming in code or comments

The benefits were:

1. Harmony - every could read everybody elses' code.
2. New hires could get started on any part of the code - not just the 'good stuff'.
3. We could use version control check-in hooks to look for issues across multiple platforms (this was days before continuous integration)
4. Better build times (include statement ordering, etc)
5. An awesome piece of Perl script looked for common errors likes failing to check for malloc() failure, etc. This would not have been possible without consistent coding styles.

In newer roles, I have found that it is nigh on impossible to 'enforce' coding standards, it has to be done gently.

---

Depending on the language you are using, you can buy intelligent reformatters off-the-shelf that will take source code in and massage it, WITHOUT changing the actual meaning (DUH!), to just about any "coding standard" (read: arbitrary rules about indentation, brace style, and whatnot) that you want.

One I looked at the other day costs about US$35 qty 1, US$1000 for a site license. That's chicken feed. You're probably spending more than that on toilet paper.

Make running the reformatter part of your source code checking procedure and don't worry about it.

---

I would stick with loose standards. No programmer I've ever worked with has had problems adapting to the coding style used by another, so it's not worth irritating everyone by trying to be draconic. The important things to enforce are consistent naming conventions and sane indentation, because code readability is important. Of course, code correctness and maintainability are even more important, so code reviews, which can cover all aspects of code quality, are essential.

---

For what it's worth, I've found that when you have limited time and energy to dedicate to a team's code quality, it can be more effectively spent on code reviews. Properly named, neatly spaced poor code is still poor code. If you have time for both, by all means do both. But if you had to choose...

---

Coding standards or any other type of process is no replacement for skill. If your team is skilled and is getting the job done (and by done I also mean that what they produce is maintainable), then the coding standards aren't really getting you anywhere.

---

Yes, they should follow the standard. Otherwise it's a mess.

If you starting a team — you can create a document based on your coding style.
If it's any existing team, then you better come up with the standard that everyone is agreed with by discussing it first.

---

I agree that there should be standards. I chose a particular set of auto-formatting options in Visual Studio 2008 and had all other developers import those settings.

Among the issues you can easily encounter with differing styles is the infamous spaces vs tabs. In VS 2008, sometimes there is a situation where you can have mixed indentation styles and hitting Ctrl-E, D to format the entire document can cause VS to crash.

Having an enforced style similarity also keeps commits in your favorite source control manager cleaner, since you don't have developers changing each others' formatting back and forth constantly.

Edit: Regarding latitude, I have some guidelines for my developers regarding naming conventions and readability, but not strict rules except for formatting (what line an opening brace goes on and so forth). I wouldn't mind if one of them put private fields at the bottom or the top. If I added a new one, I'd mimic.

Your question is simply vague and general, so you'll get general answers. I say judge each aspect of individual style separately and what its consequences are.

---

You can use the code formatting option in eclipse if reading code formatted different than you are used to is important.

---

Jon (above) is absolutely right that naming is the important thing to standardize. But there needs to be a fair degree of standardization in the codebase for any given product. To support new developers on the team.

If you aren't hung up on a really fast build, and there are "auto formatters" available for your language you can create meta-code as part of the build.

You can keep two distinct trees, one for reference only and one for actually working. Developers write in whatever style they want (as long as they name things in a standard way) and their code is pushed through a "standardizer" into another tree that is used by the compiler. This allows individuals to maintain their own styles and strangers to the project to start from the "reference version" if they take over code that's in a foreign style.

Another tool I've found useful in code reviews is reflector for .net which lets me choose the language to view a decompiled assembly in. I'm not usually interested in private variable names and this ensures that i'm only ever reviewing "compilable code"