Is it true that a stricter coding style is always better?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.