[RESOLVED] Coding standards (rules)

[laserlight]

And you find that easy to read?

Yes, but with a little more indentation, like 4 spaces. This really is just style, something that Sutter and Alexandrescu recommend to "don't sweat the small stuff (or: know what not to standardize)", so it is more of consistency with something reasonable.

[treuss]

Personally I usually omit braces entirely when it's a single-line statement.

That's probably the only thing I yell at junior developers for. Too often hours have been wasted trying to find a bug that was caused by changing code from:

if (a==b)
  foo();

to

if (a==b)
  DBG("a and b are equal");
  foo();

[_uj]

If it's alright, I was wondering if some of you could share with me the policy on the conding standards of the company you guys work for. Example would be...

I don't work at Lockheed Martin but they've made public their standard for the JSF project. It's especially interesting because Stroustrup has participated so it's not just any company standard.

http://www.programmingresearch.com/P...ev_D_JUN07.pdf

[potatoCode]

Thanks guys.
That's very helpful. One more question.
Does this mean that not every employer has a set of coding rules?

[treuss]

Yes, but with a little more indentation, like 4 spaces.

You indent with spaces instead of tabs? I though only the devil itself would do that?

ducking and running away.....

[GCDEF]

So you also write

if (a==b)
{
  foo();
}
else
{
  bar();
}

?

And you find that easy to read?

Absolutely. It's very easy to see which brace goes with which.

[_uj]

Does this mean that not every employer has a set of coding rules?

It depends very much on the company. "Engineering" style companies, where software is part of a more complex product, is more likely to have it.

To be effective a coding standard must be comprehensive and go far beyond the "here we put the braces like this" level. And it must be strictly enforced. Occasional "yelling at junior programmers" won't do. Everybody follows the standard or they get shot. Period. And this should be followed up in regular and formal code reviews where programmers explain their code to others.

Have a look at the JSF standard I posted. It's the best example I've ever seen, although I don't personally like everything. For example instead of

if (....)
{
   foo();
}

I would rather do,

if (....) foo();

It's probably because I prefer "one line one thought" over "one line one statement".

[TheCPUWizard]

_uj....agreeing with your post...

1) Many environments now have good tools for enforcing coding standards. For example Visual Studio can be set up with a set of rules that will completely prevent check-in to the source repository if the rules are not followed.

2) The "one-liner" has a bad history, which is why many coding standards still prohibit it. Back a "few" years ago, many of the debuggers were only capable of setting a breakpoint on the first part of a line. Thus in your example it would not have been possible to set a breakpoint when foo was about to be called (ie after the if evaluated to true). [you probably already knew this, but I figured it could be helpful to the general population]

[Lindley]

You indent with spaces instead of tabs? I though only the devil itself would do that?

ducking and running away.....

Indenting should always be done with spaces! You can use the tab key, but only if you set it to add 4 spaces (or some consistent number).

Otherwise you get code that becomes horribly unformatted when viewed on a system with a different tab size....

That's probably the only thing I yell at junior developers for. Too often hours have been wasted trying to find a bug that was caused by changing code from:

if (a==b)
  foo();

to

if (a==b)
  DBG("a and b are equal");
  foo();

I would consider that the fault of the modifier rather than the original coder. My view is that there is no one "right way" to structure all code-----I feel that code should be like English: complete thoughts should be expressed as concisely as possible, and kept separate from each other. Sometimes that means putting in {} for some extra whitespace, sometimes it means omitting them to remove a few lines.

[GCDEF]

2) The "one-liner" has a bad history, which is why many coding standards still prohibit it. Back a "few" years ago, many of the debuggers were only capable of setting a breakpoint on the first part of a line. Thus in your example it would not have been possible to set a breakpoint when foo was about to be called (ie after the if evaluated to true). [you probably already knew this, but I figured it could be helpful to the general population]

I agree. One statement per line makes debugging much simpler and it's easier to read. It's easier to overlook a statement if it's combined on line with others.

[_uj]

I agree. One statement per line makes debugging much simpler and it's easier to read. It's easier to overlook a statement if it's combined on line with others.

That's bullshit.

There's no evidence whatsover that this,

if (...) 
{
}
else
{
}

would be better than this,

if (...) {
} else {
}

Who claims otherwise should show scientific evidence.

[Speedo]

That's bullshit.

There's no evidence whatsover that this,

if (...) 
{
}
else
{
}

would be better than this,

if (...) {
} else {
}

Who claims otherwise should show scientific evidence.

"More than one statement per line" is one of these,

if (...) foo( );

if (...) foo( ); else bar( );

while (...) foo( );

for (int i = 0; i < 10; ++i) foo(i);

not the type of thing that you posted.

[JohnW@Wessex]

We have a comprehensive document on coding guidelines.
These formatting and coding standards are designed to enhance the readability and correctness of software produced by our company. They range from ‘good practice’ developed by the C++ community over the years, to ‘look and feel’ rules that ensure consistency of source code style between different developers.

Readability
Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly. They ensure consistency and simplify the maintenance process with legible code.

Consistency
When code has a consistent style and layout it becomes easier for coders to quickly understand something not written by them.

Bug avoidance
Some rules are there because they help to eliminate hard to find bugs or unintentional changes in meaning due simple code changes.

Harmony
All the coders have to abide by the rules. There's no arguments of whose favourite style is 'best'.

Image
It is often a contractual requirement that we deliver the source code to the customer. It is therefore essential that our code is easy for other programmers to read and understand and that it always conveys our professional standards.

[JohnW@Wessex]

if (...) 
{
}
else
{
}

We consider this to be the most readable form, which has also been the preferred choice of the majority of coders who have worked here.
It's also the form I've found to be used in C++ courses I've attended.
I've noticed that the other form is often used by C++ coders who have recently come across from Java.

[GCDEF]

That's bullshit.

There's no evidence whatsover that this,

if (...) 
{
}
else
{
}

would be better than this,

if (...) {
} else {
}

Who claims otherwise should show scientific evidence.

Wow dude, take a breath. Maybe step away from the computer for a while. Profanity isn't necessary to express a differing opinion.

FWIW I can't for the life of me think that anybody could look at the second example and find that more readable.