opinion on coding standard

[John]

Our project leader is making the decision to enforce coding standards
through the use of our IDE. While standards and consistency are
beneficial, I'm unhappy with one limitation of our IDE (IntelliJ IDEA
4.5), namely its inability to preserve extra spaces. I've found that
a judicious use of spacing can often make code much easier to read and
consequently to understand. Below is an example of before and after
formatting. For me, the formatted code seems to blur together and is
much harder to read. I'm wondering what opinions others might have.



Original code fragment:

private FormSetupComponent formSetupComponent;
private FormSetupProperties formSetupProperties;
private FormProperties formProperties;
private MsgManager msgManager;
private AbstractProperties selectedProperties;
private ResourceBundleHelper mBundle;

edgeBoundary[0] = createBoundaryLine(x, y, x, y + h);
edgeBoundary[1] = createBoundaryLine(x + w, y, x + w, y + h);
edgeBoundary[2] = createBoundaryLine(x, y + h, x + w, y + h);
edgeBoundary[3] = createBoundaryLine(x, y, x + w, y);


With extra spaces removed:

private FormSetupComponent formSetupComponent;
private FormSetupProperties formSetupProperties;
private FormProperties formProperties;
private MsgManager msgManager;
private AbstractProperties selectedProperties;
private ResourceBundleHelper mBundle;

edgeBoundary[0] = createBoundaryLine(x, y, x, y + h);
edgeBoundary[1] = createBoundaryLine(x + w, y, x + w, y + h);
edgeBoundary[2] = createBoundaryLine(x, y + h, x + w, y + h);
edgeBoundary[3] = createBoundaryLine(x, y, x + w, y);

 

[John]

Our project leader is making the decision to enforce coding standards
through the use of our IDE. While standards and consistency are
beneficial, I'm unhappy with one limitation of our IDE (IntelliJ IDEA
4.5), namely its inability to preserve extra spaces. I've found that
a judicious use of spacing can often make code much easier to read and
consequently to understand. Below is an example of before and after
formatting. For me, the formatted code seems to blur together and is
much harder to read. I'm wondering what opinions others might have.



Original code fragment:

private FormSetupComponent formSetupComponent;
private FormSetupProperties formSetupProperties;
private FormProperties formProperties;
private MsgManager msgManager;
private AbstractProperties selectedProperties;
private ResourceBundleHelper mBundle;

edgeBoundary[0] = createBoundaryLine(x, y, x, y + h);
edgeBoundary[1] = createBoundaryLine(x + w, y, x + w, y + h);
edgeBoundary[2] = createBoundaryLine(x, y + h, x + w, y + h);
edgeBoundary[3] = createBoundaryLine(x, y, x + w, y);


With extra spaces removed:

private FormSetupComponent formSetupComponent;
private FormSetupProperties formSetupProperties;
private FormProperties formProperties;
private MsgManager msgManager;
private AbstractProperties selectedProperties;
private ResourceBundleHelper mBundle;

edgeBoundary[0] = createBoundaryLine(x, y, x, y + h);
edgeBoundary[1] = createBoundaryLine(x + w, y, x + w, y + h);
edgeBoundary[2] = createBoundaryLine(x, y + h, x + w, y + h);
edgeBoundary[3] = createBoundaryLine(x, y, x + w, y);

I agree completely and add extra spaces all the time. I would much
rather let people use manual formatting and hit them with a big stick
when they start class names in lower case or call variables "var" or "foo".

John

 

[Ann]

That's why s/he is the boss and you are not. Learn to live with it.
It isn't all that bad. Stop whining. You'll just make her mad.

 

[Tim Ward]

Our project leader is making the decision to enforce coding standards
through the use of our IDE. While standards and consistency are
beneficial, I'm unhappy with one limitation of our IDE (IntelliJ IDEA
4.5), namely its inability to preserve extra spaces. I've found that
a judicious use of spacing can often make code much easier to read and
consequently to understand. Below is an example of before and after
formatting. For me, the formatted code seems to blur together and is
much harder to read. I'm wondering what opinions others might have.

Normally the advice is to put up with coding standards, even if they aren't
what you would choose, even if they are a bit daft, because the consistency
is worth more than whatever the advantages of your personal style might be.

But one does have to draw the line somewhere - some coding standards are
just so bad that it's reasonable to call them "wrong".

The worst of all is the requirement to have hard tab characters in source
files - if someone asks me to do that I just find another job.

What you describe has got to qualify as second worst - it's on the margin
for looking for another job; if the organisation doesn't recognise that this
is "wrong" then they're probably getting a lot of other things wrong as
well.

 

[Ann]

The worst of all is the requirement to have hard tab characters in source
files - if someone asks me to do that I just find another job.

What you describe has got to qualify as second worst - it's on the margin
for looking for another job; if the organisation doesn't recognise that this
is "wrong" then they're probably getting a lot of other things wrong as
well.

Don't be such a baby.

 

[Kari Laitinen]

Our project leader is making the decision to enforce coding standards
through the use of our IDE. While standards and consistency are
beneficial, I'm unhappy with one limitation of our IDE (IntelliJ IDEA
4.5), namely its inability to preserve extra spaces. I've found that
a judicious use of spacing can often make code much easier to read and
consequently to understand. Below is an example of before and after
formatting. For me, the formatted code seems to blur together and is
much harder to read. I'm wondering what opinions others might have.

Original code fragment:

private FormSetupComponent formSetupComponent;
private FormSetupProperties formSetupProperties;
private FormProperties formProperties;
private MsgManager msgManager;
private AbstractProperties selectedProperties;
private ResourceBundleHelper mBundle;

edgeBoundary[0] = createBoundaryLine(x, y, x, y + h);
edgeBoundary[1] = createBoundaryLine(x + w, y, x + w, y + h);
edgeBoundary[2] = createBoundaryLine(x, y + h, x + w, y + h);
edgeBoundary[3] = createBoundaryLine(x, y, x + w, y);

With extra spaces removed:

private FormSetupComponent formSetupComponent;
private FormSetupProperties formSetupProperties;
private FormProperties formProperties;
private MsgManager msgManager;
private AbstractProperties selectedProperties;
private ResourceBundleHelper mBundle;

edgeBoundary[0] = createBoundaryLine(x, y, x, y + h);
edgeBoundary[1] = createBoundaryLine(x + w, y, x + w, y + h);
edgeBoundary[2] = createBoundaryLine(x, y + h, x + w, y + h);
edgeBoundary[3] = createBoundaryLine(x, y, x + w, y);

I'm on your side in this question. Programming tools
which remove spaces from source code are not good.
It's the people who make programs readable and
understandable by writing them carefully, and
tools should preserve the programs as they
are written.

 

[kaeli]

That's why s/he is the boss and you are not. Learn to live with it.
It isn't all that bad. Stop whining. You'll just make her mad.

Oh, and god forbid we make the PM MAD...

Methinks YOU are one of those bad bosses these people dislike so much. (or a
blatant troll)
If a PM gets angry b/c team members have real reasons for wanting to do
things differently, s/he is a complete moron who deserves to be fired on the
spot.
No one likes a micromanager who is so incompetant and egotistical, s/he has
to have power trips about stupid things. It's worse when those stupid things
actually make team members have a harder time of it. A good boss makes life
EASIER for their team, not harder. A good boss listens to suggestions that
have a logical basis, weighs the pros and cons, and decides how best to do
things based on logic and business needs, not their itty bitty ego.

If someone is this much of an ass, it would do ALL the employees good to get
the hell out of Dodge before they go down with them. These kinds of PMs love
to blame their mistakes on the underlings.

/ have been team member and PM in my time, sometimes both at once

--

 

[sks]

Normally the advice is to put up with coding standards, even if they
aren't

what you would choose, even if they are a bit daft, because the consistency
is worth more than whatever the advantages of your personal style might be.

But one does have to draw the line somewhere - some coding standards are
just so bad that it's reasonable to call them "wrong".

The worst of all is the requirement to have hard tab characters in source
files - if someone asks me to do that I just find another job.

I think using multiple spaces instead of tabs is completely ridiculous.

 

[Eric Sosman]

[...]
If a PM gets angry b/c team members have real reasons for wanting to do
things differently, s/he is a complete moron who deserves to be fired on the
spot.

Good grief, kaeli! What in the world makes you think
that "real reasons" never conflict with each other? Methinks
the person unable to perceive conflict is the "complete moron,"
not the person who seeks a resolution.

No one likes a micromanager who is so incompetant and egotistical, s/he has
to have power trips about stupid things. It's worse when those stupid things
actually make team members have a harder time of it. A good boss makes life
EASIER for their team, not harder. A good boss listens to suggestions that
have a logical basis, weighs the pros and cons, and decides how best to do
things based on logic and business needs, not their itty bitty ego.

If someone is this much of an ass, it would do ALL the employees good to get
the hell out of Dodge before they go down with them. These kinds of PMs love
to blame their mistakes on the underlings.

Most people outgrow the "Terrible Twos" eventually.
Hang in there.

 

[Brock Heinz]

Hi John,

This document is somewhat the 'authority' on coding standards.

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

Most IDE's try to conform this as well.

Brock

 

[Scott Ellsworth]

Oh, and god forbid we make the PM MAD...

Often not a good idea. I try to only make PMs angry when there is
something worth winning. An actual bad decision that will make the
product worse, or add to work for no benefit, for example. Scarfling
around on a coding standard that my IDE enforces is just not worth the
energy.

Methinks YOU are one of those bad bosses these people dislike so much. (or a
blatant troll)
If a PM gets angry b/c team members have real reasons for wanting to do
things differently, s/he is a complete moron who deserves to be fired on the
spot.

Perhaps. Perhaps the PM has their own reasons, which might well make
sense.

For example, on every project where someone flatly refused to go along
with the coding standards, there was someone who would reformat and
check in other people's code with no changes other than the format.
This makes it hard as hell to find the actual changes in the file. Even
better, they would reformat any file they worked on, using an automated
tool, and check in real changes along with reformatting.

Guess who the villain was? Got it in one - the person who felt that
their coding standard was just better, and that if people only saw it,
they would convert.

A good PM only puts up the minimal required standard, but their
perception may well differ with yours. If they respond to valid
complaints, such as "the IDE will not autoformat, so we have to spend
valuable hours doing it ourselves", rather than the specious "I do not
like it", then they are doing their job.

No one likes a micromanager who is so incompetant and egotistical, s/he has
to have power trips about stupid things. It's worse when those stupid things
actually make team members have a harder time of it. A good boss makes life
EASIER for their team, not harder. A good boss listens to suggestions that
have a logical basis, weighs the pros and cons, and decides how best to do
things based on logic and business needs, not their itty bitty ego.

Perhaps the PM did make that decision, and it went against the original
poster.

Having been in a coding standard war, I would not be eager to get in
another. I might well decide that a reasonably rigorous coding standard
was the only way to prevent it. At the moment, I am working with cool
people who do not do garbage like that, and we have no coding standards,
but this is the exception.

Scott

 

[Michael Borgwardt]

I think using multiple spaces instead of tabs is completely ridiculous.

Then you're thinking wrongly or misunderstood the subject. We're talking
about *source code*. That means, text files that are frequently changed,
by different people, often using different editors, and where correct
indentation is very important for understanding the code.

The problem is that people have different settings for how "wide" a tab
is, and then, as soon as tabs and spaces get mixed (which invariably
happens) the formatting is broken for some people.

 

[Hal Rosser]

Our project leader is making the decision to enforce coding standards
through the use of our IDE. While standards and consistency are
beneficial, I'm unhappy with one limitation of our IDE (IntelliJ IDEA
4.5), namely its inability to preserve extra spaces. I've found that
a judicious use of spacing can often make code much easier to read and
consequently to understand. Below is an example of before and after
formatting. For me, the formatted code seems to blur together and is
much harder to read. I'm wondering what opinions others might have.

One thing experience will teach you:
Your job is to do what the boss says.
Oops - gotta go do the dishes now - bye

 

[sks]

Then you're thinking wrongly or misunderstood the subject. We're talking
about *source code*. That means, text files that are frequently changed,
by different people, often using different editors, and where correct
indentation is very important for understanding the code.

The problem is that people have different settings for how "wide" a tab
is, and then, as soon as tabs and spaces get mixed (which invariably
happens) the formatting is broken for some people.

I know precisely what he means and by using tabs its automatically formatted
how I like it. I like 3 spaces per ident level because it looks right with
my font, you might like 200. If you use spaces I'm just going to get pissed
when looking at your code and vice versa.

 

[Michael Borgwardt]

I know precisely what he means

Apparently not.

and by using tabs its automatically formatted
how I like it. I like 3 spaces per ident level because it looks right with
my font, you might like 200. If you use spaces I'm just going to get pissed
when looking at your code and vice versa.

Again: this only works when you use *only* tabs, but that never works because
you *can't see the difference* between tabs only and mixed tabs&spaces. They
inevitably become mixed and then the formatting is totally screwed at a different
tab width.

 

[Chris Uppal]

Don't be such a baby.

All you are saying is that /you/ don't care about code layout. Yet other
people
/do/ care. Maybe that isn't how you want the world to be, but that's the way
it is, and that's the way it'd going to stay.

So stop whining and get over it.

-- chris

 

[John]

That's why s/he is the boss and you are not. Learn to live with it.
It isn't all that bad. Stop whining. You'll just make her mad.

What are you telling me for? I think perhaps you should be addressing
the OP. I am 'the boss', and I don't whine.

John

 

[kaeli]

[...]
If a PM gets angry b/c team members have real reasons for wanting to do
things differently, s/he is a complete moron who deserves to be fired on the
spot.

Good grief, kaeli! What in the world makes you think
that "real reasons" never conflict with each other? Methinks
the person unable to perceive conflict is the "complete moron,"
not the person who seeks a resolution.

Is that what you think I said?
Re-read it again. Then again. Try reading what it was a reply to.
Here it is, in case your server missed it.

"That's why s/he is the boss and you are not. Learn to live with it.
It isn't all that bad. Stop whining. You'll just make her mad."

Then try to realize that conflict doesn't justify anger and "real reasons"
are anything other than "because I like it that way". Of course they can
conflict. That's the point.
If employees are afraid to raise an issue with a PM because she might get
mad, the one who has the problem is the PM; and in my opinion, s/he has no
right to BE a PM.

And if you think that makes me in my "terrible twos", then so be it. My team
members like me this way. They're glad I don't get pissed off when I actually
listen to their suggestions. I may or may not implement said suggestions, but
I certainly would never get pissy about it.

Nowhere did I say the boss doesn't get the final say. Nowhere. But if a boss
makes decisions without listening with an open mind to their team, they ARE a
moron. Sorry.

--

 

[Ann]

One thing experience will teach you:
Your job is to do what the boss says.
Oops - gotta go do the dishes now - bye

Exactly !!!!!
Ann

 

[sks]

Apparently not.


Again: this only works when you use *only* tabs, but that never works because
you *can't see the difference* between tabs only and mixed tabs&spaces. They
inevitably become mixed and then the formatting is totally screwed at a different
tab width.

You shouldn't mix tabs and spaces. I mean who uses spaces to indent their
blocks? Ridiculous. Do you actually sit there typing t r y { (newline)
(space) (space) (space) (space) (space) (space)