in reply to Re^2: Why Create Coding Standards and Perform Code Reviews?
in thread Why Create Coding Standards and Perform Code Reviews?

separate your Coding Standard from a Style Guide.

Ditto Anonymonk.

The only problem is that you first have to agree what belongs in which!

For example. I would say that the use of consistant indentation is mandatory; the size of indent and curly placement is not.

Rule 0: Donít sweat the small stuff.

Eek! Total divergance :)

It's strange. As an avowed anti-pedant, I probably shouldn't think this never mind say it, but I often think that the "small stuff" has more impact upon me than the "big stuff". (Bearing in mind the disparate ways we may be using the phrases.)

For example. I don't mind if code is written in a OO, procedural or functional style, or some mix of the three. I've encountered good and bad examples of all three. Though for me, the worst is badly structured (spagetti) OO code because it is so easy to pass it off as "well structured"--and believe it.

But there are some things I find intensly irritating

any consistent style

Bravo! That my watchword for both categories, but especially style: consistancy. Whichever way you opt to do it, do it everwhere the same.

better than having multiple styles in a large code base.

However we'll have to agree to differ on that. Nobody reads an entire large codebase from beginning to end, they dive in to small pools for a while, occasionally.

Consistancy within individual source files makes reading them easier; and across closely related sets of file is nice to have as they will often be used concurrently. But 4-space indentation and cuddled elses across the entire codebase, is entirely unimportant. I won't save time nor money; nor make the code run more correctly or efficiently. It won't even look good on paper because no one will ever see it (all) on paper.

And when it comes to maintaining someone elses code within the codebase, sticking with their indentation & curly placement is a good idea--for consistancy--but don't expect me to omit all horizontal whitespace; add one-per-line or block comments; or make up new, stupidly long variable names.

I'll hug your elses if you do; use the full, unadulterated name a variable's mother gave it; and emphasise the silences between my (lowercase) words if that's the local custom. I'll adapt to the local customs for the duration, but do not expect me to adopt your ways, including your bad habits, wholesale.

When I visit a Japanese business man at his home or workplace, I'll nod my head on greeting, but when he visits me, I'll offer my handshake. And don't expect me to spend 5 minutes silently admiring his damn business card, just cos he has more money than sense. And just to ensure that this isn't seen as anti-Japanese--I could have picked any national cultural quirks--I won't accept, or give, kisses to a Frenchman I've never met either. Even just on the cheek.

Enough! I don't have time for this :) I've got to get back to that dratted Java :(

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^4: Why Create Coding Standards and Perform Code Reviews?
by gwadej (Chaplain) on Jul 06, 2009 at 03:02 UTC

    Wow... I didn't mean to hit a nerve.<grin/>

    Despite what it appears from your response. I'm in almost total agreement with you. Much of what you appear to disagree with is from my paraphrasing and abbreviating the book. If you get a chance, I highly recommend it.

    Most of the coding standards in the book are what most of us describe as good coding practice with a short blurb about why. It then refers you multiple texts for the full discussions about why you need to follow these standards.

    As you've described, they talk about consistent formatting (in the item 0) but don't mandate what that formatting is.(The particular style is "unimportant".) If I remember correctly, they may also have mentioned the "style per file" is more important than "style for all code" and to avoid wasting time with reformatting for the sake of reformatting. Or, that may be in one of the books they referenced.

    G. Wade