Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am currently studying computer science and was wondering how strict coding styles are in industry, how much it differs between industries and if it is true that a stricter coding style is always better?

share|improve this question

migrated from stackoverflow.com Jan 30 '11 at 0:23

This question came from our site for professional and enthusiast programmers.

add comment

10 Answers

The stricter and longer the coding style guidelines, the less likely employees will follow them.

share|improve this answer
8  
I once helped write a coding standard doc, the first thing we decided was that the doc could be no longer than 3 pages. –  Zachary K Feb 14 '11 at 16:16
1  
If a programmer has to think about coding styles, that's a portion of their brain that is being distracted from potentially thinking about solving the problem. Human brain resources are almost certainly non-infinite. –  hotpaw2 Mar 17 '11 at 21:00
1  
-1. Wrong. The ability to follow the style guidelines depend on many factors, among which the quantity of rules is not even close to being one of the most important. Example: StyleCop has plenty of rules. With its nice integration into version control and Visual Studio, easy to understand rules, good documentation etc., I have no problems writing code which follow the guidelines. On the other side, I have a badly written set of guidelines for PHP (I wrote myself), which are not enforced during commits nor integrated into the IDE. I often violate them, even if there are only a few rules. –  MainMa Dec 7 '11 at 12:55
1  
@ZacharyK Three pages -- that's at least one page too many! –  quant_dev Dec 7 '11 at 15:15
1  
@quant_dev No, that's 3 pages too many! :) In our team we've set up an addon (StyleCop) that makes following a coding style a cakewalk. That way we don't even think about it (it underlines wrong formats and a simple key-press and it fixes the issue). –  Amadeus Hein May 31 '12 at 12:31
show 2 more comments

I work in the financial sector and have worked for a range of banks etc... Coding styles vary considerably from place to place, some have very precise and strict rules, others have none.

Coding styles have various pros and cons.

The pros of a strict coding style are:

  • Consistency, makes it easier for developers to follow each others code
  • Coding styles favor good practices in coding techniques

The cons are:

  • It is easy to over emphasize coding style and forget about what is really important, good design.
  • Following a strict style can be quite time consuming.

Personally in my teams I encourage light-weight coding styles mostly because it looks good to the client. I believe code-review and design-review are MUCH more important.

share|improve this answer
1  
+1 - I think this summarises the pros and cons pretty well. –  AAT Jan 29 '11 at 21:01
    
Another con can be that forcing particular coding standards on developers can be bad for morale if they conflict with the persons own personal opinions or what they're used to. I've had some co-workers significantly frustrated by this. –  Alb Jan 30 '11 at 1:33
    
@Alb: Bad for morale? Ha! These people need to grow up. –  James May 31 '12 at 13:12
1  
@Alb I disagree, having coding standards within an organization makes it much easier for developers to modify other people's code later on. The hardest part of changing code is usually reading it first; having a consistent style makes that easier –  briddums May 31 '12 at 18:02
    
@James Bad Hungarian Notation was, for a while, quite popular (and probably still is at some companies). However, it is also quite a bad style, which is definitely going to reduce morale - especially for programmers used to Good/Original Hungarian Notation. –  Izkata Mar 6 '13 at 17:56
add comment

It's a trade-off.

Strict coding styles can slow a product to market, especially if there is no complete or useful spec.

But coding styles can also help prevent a development effort from failing to get to market at all, as well as from some significant failures and costs after it gets there.

The basic reason is that many of these coding style rules are based on statistical evidence, not any logical necessity. Some are based on psychological principles that apply to typical programmers, not to every programmer (although they often seem most applicable to the very programmers who don't think these rules apply to themselves.) There is absolutely no reason why those old classic apps written in Fortran using gotos, global variables, and almost no comments can't still function perfectly well in some limited environment.

share|improve this answer
add comment

Eclipe, NetBeans and Visual Studio (the IDEs I have used the most) all have a "Format" button that formats the code a certain way (depending on the IDE and the plugins used).

In a consistent development environment all developers should use the same IDE, and, I believe follow the IDE's formatting style. This can allow the code to be uniformly formatted while not wasting the developer's time.

We can regret though that formats are not more easily customizable... Some modules (I think specifically about Eclipse STS's HTML formatter) just create unreadable documents.

share|improve this answer
add comment

While it's possible to cite all sorts of benefits and efficiencies by having one style, it's important to note that it's an entirely different matter to enforce one style.

The problem that Hungarian notation was intended to solve, (deriving a variable's type without seeing the declaration) was rendered moot once the IDEs started supporting cursor-hover-popup descriptions.

Quite frankly I'm surprised people worry about it beyond: CTRL-SHIFT-F, commit.

share|improve this answer
add comment

More developers are involved in a project, more valuable strict coding style is required. Too many "dialects" will mess up communication.

Because coding style is useful to people other than machine.

share|improve this answer
    
They're more like accents than dialects, but I agree. –  Jon Purdy Feb 14 '11 at 17:16
add comment

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.
-Ralph Waldo Emerson

Generally speaking, overly strict coding styles come from managers, tech leads, and architects who can't think of any better way to justify their existence to their organization. When you're in school, professors might preach them for similar reasons: they can't think of any better ways to teach students the things they will need to know in industry.

In general, coding guidelines should be just that: guidelines. When they become hard and fast rules is when things go wrong. Let me give you an example. In a C-like language, many projects might have a rule that each curly brace should be on its own line in a method definition. Like this:

void some_func()
{
    do_something();
    do_something_else();
    do_another_thing();
}

This works in most cases. But what if the method definition is trivial? Which is better?

int calculate() {return 1;}

int calculate()
{
    return 1;
}

I would argue that the first is better. Some might feel the second is better, which is fine. If someone defines the method the first way, is it really worth your time to convince them to rewrite their code the second way? Probably not. There are usually better ways to spend your time. Like actually figuring out if their code works the way it's supposed to or determining if their design is good.

share|improve this answer
    
There's no need to convince them to change because they won't have written it the first way because the coding standard says do it the second way and we do it that way so that we don't have devs wasting time reformatting code (for whatever reason) and putting non-existent changes into the version control system. Its not just "petty" though it may seem so. You're right that coding standards shouldn't be mindless and will have to evolve over time but the second example is not a black and white as you'd like to thing. –  Murph Jan 30 '11 at 11:15
1  
@Murph - Actually, that was my point. The second example isn't black and white. So why should we be subjected to coding standards that are black and white? –  Jason Baker Jan 30 '11 at 17:02
2  
@Murph - I disagree. I understand the desire for consistency, but as the quote I mentioned says, a foolish consistency is the hobgoblin of little minds. The world won't come crumbling down if you use both styles. And besides that, there are times where one of the two methods might be appropriate. –  Jason Baker Jan 30 '11 at 20:26
1  
@Jason - reasonable (-: My point is that you don't want users to create differences between commits that are solely down to formatting - programmers being what they are, the kind of flexibility you suggest (allowing a choice of layout as above) will result in exactly that. I'm not sure where the middle ground is... but I think the issues are more to do with things like comments (about which some flexibility is desirable) than formatting about which one should probably be pretty dictatorial. –  Murph Feb 2 '11 at 8:10
1  
of course, you're both right - you don't need a standard to say "stop reformatting for no good reason" (in fact, few standards say that. hmm). But you don't need to prescribe either style in the standard to enforce that first rule. IMHO a standard that does not enforce this style allows you to use the first style where it would be cleaner (eg a large block of accessors for a structure, maybe ina header file). –  gbjbaanb Jul 28 '11 at 10:26
show 4 more comments

I find the primary reason for stricter coding styles is to help younger programmers develop a good style. Once you achieve a certain amount of experience coding styles do not necessarily help and in some cases can hinder "the flow". So my answer to your question is, it depends on the programmer.

E.g. having a rule saying all functions must be commented can cause some bizarre comments when the function name already tells the whole story.

share|improve this answer
add comment

The answer is going to depend on where you look.

For systems with ancient code bases, the coding style is usually less strict than on a newer project with a new code base. This is entropy at work - old code bases have more entropy because they've had longer to accumulate it.

It can vary even within projects within a single company, let alone between companies or industries.

'Always' is a sweeping absolute, and few absolute claims are always valid. Usually, a strict coding style leads to more uniform code that is easier to maintain. Sometimes, though, it leads to code that is harder to maintain, when the standards are inappropriate.


For instance:

/*2******************************************************************
** show_stk : dummy function used for breakpoint
**
** DESCRIPTION:
**
**     Dummy function used for breakpoint.
**
** RETURN VALUE:
**
**     void
**
********************************************************************/
void
show_stk(void)

The coding standard that said 'thou shalt document the return value even when there is no return value' was moderately ridiculous. I just spent some time removing the 'RETURN VALUE: void' comments (800 lines gone from the relevant file). The repeated comments between the one liner intro and the DESCRIPTION is also moderately pointless in this example - but I've not fixed that (yet). The idea is 'sort of' good, but when followed without using discretion, it becomes silly. And code templates encourage the addition of mostly unused information, which just makes matters worse. (Input arguments, output arguments - for functions with no arguments?) And what about the horizontal lines? Why not just:

/* show_stk(): dummy function used for breakpoint */
void show_stk(void)

There are some reasons to keep the function name at the start of a line - but 2 or 3 lines versus 14 is a lot of expansion for minimal benefit.

share|improve this answer
1  
the one thing I do like about flowerbox comments is that they split the functions up, making them really easy to see. If you ever see a large file where each function is separated by a single blank line you'll understand what I mean. –  gbjbaanb Jul 28 '11 at 10:20
add comment

No, it's not true. Coding styles differ widely and are subject to preferences and a "stricter" style (and I'm not even sure if you can definetely say if one style is stricter than another) is not necessarily "better" (because better is also subject to preference).

Take for example code comments. Some might argue that the more comments the better because obviously it's more clear what the code does. Others would say that code that requires a lot of comments is poorly written because it's not self documenting (be it due to inappropriate naming or poor factoring). The same could be said about other aspects of a coding style.

share|improve this answer
    
Where I work, comments are used to explain WHY rather than WHAT. The code should be self explanatory, but the reason for choosing one method over another may not be immediately clear to the next poor schmuck who has to maintain it. –  oosterwal Jan 30 '11 at 2:10
1  
I don't want to start the "to comment or not to comment" war again, but I don't think that's a fair representation of the argument against using lots of comments. Being self-documenting isn't an end in itself. For me, it's about efficiency. Why have code + comments when just code can do the same thing with a bit more thought? –  Jason Baker Jan 30 '11 at 2:33
    
A 20-page style document (they do exist) is definitely stricter than a half-page one. –  Peter Taylor Feb 14 '11 at 17:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.