opinion on coding standard

[Jean Lutrin]

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.

I agree with you that extra spaces can make code much, much
more pleasant to use.

Moreover, the preferred presentation of a source code file to a
programmer should /really/ be a detail. Only the structure is
important.

But I've got good you can both accomodate your boss's
will and have your extra spaces... If your willing to
do some extra work.

This can be done under IntelliJ. I work mostly with
IntelliJ but it should work under Eclipse and other IDEs too
(and, for sure, it is doable under *the* editor, (x)emacs

At first, I decided that I would conform to the "standard", whatever
that is, and modify my coding style to match the one you get when
you do, under IntelliJ, "Tools / Reformat code" (using the default
settings).

But then I did indeed find it sometimes very annoying. So I wrote
my own plugin for IntelliJ (it's not hard), to do some
extra "beautifying" (it's basically "Tools / Reformat code" + some
eye candy for arrays and alignment).

What do you mean when you say that IntelliJ is unable to
preserve extra spaces ? Do you mean that Tools / Reformat code
removes what it considers unnecessary spacing ?

Now, if your boss is concerned about you conforming to the
standard, do the following :

1. Use the normal "Tools / Reformat code" before commiting
to the CVS (or whatever code repository you use)

2. Call your plugin to "beautify" your code when you get back
some source file from the CVS that doesn't look good to you.

Note that you can still compare your source file with those
in the CVS: IntelliJ has an option to "ignore extra spaces"
when comparing a source file with one from the CVS.

The only issue is that IntelliJ has a very convenient way
of displaying which lines were modified and which were not
at the left of each line and when you do your own reformatting,
it shows every line reformatted as "modified" (but when using
the "CVS / Compare with..." there's no problem). For me it's
no a problem though: I /mostly/ adhere to the standard, besides
for some occasionnal small arrays and alignment in some very
precise cases). Now maybe there's an option somewhere in
IntelliJ to fix this behavior!?

/sorry about that not-so-clear paragraph/



IntelliJ's so called "Open API" to write plugins is not
that "open" but it's open enough and there are enough examples
and open plugins, available with source code, that should
get you started.

I've written two "plugins" for IntelliJ so far: one that
"beautifies" the code by inserting extra spaces to suit
my taste and one other that adds and remove automagically
System.out's (for quick and dirty debugging, when I don't
feel like doing the "clean" log4j logging). The latter allows
me to add System.out that gets automatically removed by
a single shortcut (say, before committing), so nobody sees
that I, temporarly, added quick and dirty System.out's.

Same for the "extra spaces beautifier".

I developed these plugins at home and nobody's gonna notice
that little 20 Kb jar file in your IntelliJ/plugins directory.

My plugins are ugly hacks (so ugly that I would be ashamed
to show you the sourcecode), but you can find several source
code for IntelliJ plugins at www.intellij.org

This is not yet a real "source code in database" (scid) that
some other languages / IDEs have, but with my little IntelliJ
plugin and the CVS, I'm getting closer to that...

Do a groups.google.com search on "source code in database" and
have fun

See you,

Jean

 

[blmblm]

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)

Oh good, a chance to combine two perennial religious-war topics (choice
of editor and choice of coding style)!:

I indent my code with spaces, for just the reasons described earlier
(by sks, if I have the attributions sorted out right).

I do not, however, type as you described. That would indeed be
tedious. Fortunately my editor of choice (vim) is able to not only
convert presses of the tab key into an appropriate number of spaces
but also to do a pretty good job of automatically indenting code,
in most cases supplying the correct number of spaces automatically.
It can also be directed to reformat blocks of code according to its
rules. This seems to work remarkably well in practice. I believe
emacs has similar capabilities.

 

[Jared MacDonald]

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)

No. Every modern editor (and not-so-modern: emacs, e.g.) has the
ability to map the "tab" key to a configurable number of space
characters.

As for why to use spaces over tabs, open up any .java file from the
JDK's src.zip, in any editor. It's a mess. Same goes for any
organization that uses tabs.

 

[Michael Borgwardt]

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)

People tend to use spaces when changing existing code later on and single
lines need to have their indentation adjusted, and of course there are the
editors that automatically convert tab presses to spaces.

 

[Gerbrand van Dieijen]

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

Indeed, if you're boss wants (for example) the new XML thingie, you'll buy
it. You won't say 'we don't need it because' or 'an alternative would be'
because that's scary and even my advice could save money or be more
efficient, my boss already thougth about that - because he should now
the same things as I do.
This way I'm certain to get promotion

 

[Steve W. Jackson]

:On Tue, 23 Nov 2004 20:40:01 -0500, Hal Rosser wrote:
:>One thing experience will teach you:
:>Your job is to do what the boss says.
:>Oops - gotta go do the dishes now - bye
:
:Indeed, if you're boss wants (for example) the new XML thingie, you'll buy
:it. You won't say 'we don't need it because' or 'an alternative would be'
:because that's scary and even my advice could save money or be more
:efficient, my boss already thougth about that - because he should now
:the same things as I do.
:This way I'm certain to get promotion

Those of you who think this way would never work for me or in my
organization. You'd be too busy worrying about how to get promoted to
do a good job.

If you're working for a quality boss in a quality organization, then the
boss wants your ideas and opinions. He (or she) will give reasons for
his position and expect you to support yours. Convince him that yours
is better and he'll go for it. Or you'll see that his choice is better
and learn something new from it (for future use and the benefit of all).
And *that* is how you get promoted.

= Steve =

 

[Ann]

Those of you who think this way would never work for me or in my
organization. You'd be too busy worrying about how to get promoted to
do a good job.

If you're working for a quality boss in a quality organization, then the
boss wants your ideas and opinions. He (or she) will give reasons for
his position and expect you to support yours. Convince him that yours
is better and he'll go for it. Or you'll see that his choice is better
and learn something new from it (for future use and the benefit of all).
And *that* is how you get promoted.

= Steve =

In my experience in working at a large company, many decisions are made at
the Vice President level (under her is an Executive Director, then a
Department
head, then my lowly Supervisor) and my sup is not able to bang the doors
to make the VP change her mind even if she wanted to. Imagine 10 workers
in a group and 3 want tabs, 3 want spaces, and 4 want tabs and spaces.
I suppose that 6 or 7 of them should quit if they don't get their way.

 

[Gerbrand van Dieijen]

In my experience in working at a large company, many decisions are made at
the Vice President level (under her is an Executive Director, then a
Department
head, then my lowly Supervisor) and my sup is not able to bang the doors
to make the VP change her mind even if she wanted to. Imagine 10 workers
in a group and 3 want tabs, 3 want spaces, and 4 want tabs and spaces.
I suppose that 6 or 7 of them should quit if they don't get their way.

I'm certain there are management books, which go in detail on this kind of
subjects. I think the superviser/boss should listen to all arguments,
critiques and use it to make his or her descision.
Those 6 or 7 don't have to quit, most likely they get their way at another
time. Maybe what is chosen, later doesn't seem to work well and they'll be
listened to next time, or vice versa.

 

[Michael Borgwardt]

In my experience in working at a large company, many decisions are made at
the Vice President level (under her is an Executive Director, then a
Department
head, then my lowly Supervisor) and my sup is not able to bang the doors
to make the VP change her mind even if she wanted to.

What in god's grace is a *VP* doing micromanaging stuff like coding
standards?

 

[Ann]

What in god's grace is a *VP* doing micromanaging stuff like coding
standards?

Haven't you heard? Using coding standards makes the stock price rise
compared to not using coding standards.

 

[Michael Borgwardt]

Haven't you heard? Using coding standards makes the stock price rise
compared to not using coding standards.

Even as a ticklist feature, it doesn't make sense for the VP to decide
*what* coding standards should be used. That's the job of the project
leader, who'd hopefully let (or make) the developers reach a consensus.

 

[Tim Ward]

What in god's grace is a *VP* doing micromanaging stuff like coding
standards?

A company might decide that it wants uniform coding standards across all its
operations, to make it cheaper to move staff about. To achieve this it might
want or need the decision to be made by someone senior to all the techie
groups who are each proposing that their own standard become the corporate
one. This could be a VP. That's not micromanaging, that's strategic.

 

[Michael Borgwardt]

A company might decide that it wants uniform coding standards across all its
operations, to make it cheaper to move staff about. To achieve this it might
want or need the decision to be made by someone senior to all the techie
groups who are each proposing that their own standard become the corporate
one. This could be a VP.

Should be the head of the development department, if there is a separate
development department (it sounded like that).

That's not micromanaging, that's strategic.

Making the decision on the particular coding standards on a non-tech
management level is quite definitely micromanagement. If the tech groups
can't agree on one and the development head is too cowardly to make
the decision himself, it's their fault, but it's still micromanagement.

 

[Tim Ward]

Should be the head of the development department, if there is a separate
development department (it sounded like that).

No no, I'm talking about the scenario where there are many independent
development departments in different divisions of the company on different
sites.

Whether getting a consistent coding standard is a sensible thing to do can
be argued about, but if such a company decides it wants to do it the
decision is almost certainly going to have to be taken at non-technical
level.

 

[Tim Jowers]

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.

<snip>

Good example of good use of spaces. I think it is defensible.

Personally, I'd like to see better comments more than better
formatting. Two other points:

First, we run code through a beautifier here so what you get out of
source control will not necessarily be formatted like what you put
into source control. E.g. the tool puts args on multiple lines like
the Windows coding style. Works fine I think.

Second, I've worked on lots of projects and the occassions for
multiple people to touch the same source are alot less than imagined.
Maybe two and possibly three people will ever change a block of code.
The two cases I've seen are persons leaves and newbie takes over.
Formatting can help because the task of reading and understanding the
code is daunting. Other case is fixing some bug. IME, stupid variable
names and plain poor coding are MUCH harder to fix than weird
formatting. To me, individual formatting is like an artists' style and
certainly we all know enough about compilers to realise it is
syntactically the same. Maybe code formatting bothers other people
more than me.

So, my opinion is good coders can read code and understand it.
Comments are more important than a particular fomatting. Modern tools
that match braces and check syntax and flag errors dynamically make
coding standards more of a business decision than engineering
decision.

As engineers and scientists we need to focus on real problems.

That said, it is nice to be able to glance at Linux source and know
something is a macro but I find following the links to the declaration
more useful in any language because then you are 100% accurate. Oh
yeah, WebLogic WorkShop only follows to the definition as of SP3!
C'mon BEA! Even Eclipse is better at this!

TimJowers

 

[Ann]

<snip>

Good example of good use of spaces. I think it is defensible.

You can always use a preprocessing program (you can write
something you like) then you can relive your youth when you
used things like:

BEGIN {
END }
LOOP for(;
:= =

 

[Michael Borgwardt]

Second, I've worked on lots of projects and the occassions for
multiple people to touch the same source are alot less than imagined.
Maybe two and possibly three people will ever change a block of code.

My experiences are quite different. This depends very much on the size
of the project, and the development process. For example, extreme
programming strongly discourages "code ownership".

The two cases I've seen are persons leaves and newbie takes over.
Formatting can help because the task of reading and understanding the
code is daunting. Other case is fixing some bug. IME, stupid variable
names and plain poor coding are MUCH harder to fix than weird
formatting.

Variable names are *part* of the coding standards, and a more important one
than formatting.

 

[Tim Ward]

For example, extreme programming strongly discourages "code ownership".

As did "egoless programming" and pretty well every other "methodology"
invented since the early 1980s.

If someone wants to "own" some code and not let anyone else work on it then
in approximately 100% of cases this is simply because the code is crap and
they don't want anyone to find out.

 

[David Zimmerman]

As did "egoless programming" and pretty well every other "methodology"
invented since the early 1980s.

If someone wants to "own" some code and not let anyone else work on it then
in approximately 100% of cases this is simply because the code is crap and
they don't want anyone to find out.

I've always tried to maintain that when things are going well, "our
code" is the reason, but if there are bugs, the bugs are in "my code".

 

[Chris Smith]

Personally, I'd like to see better comments more than better
formatting.

Absolutely not! Comments at such a low level should be a last-ditch
effort to explain something when you can't find any other way to express
it in code. Comments are to be encouraged taken at face value, but they
are the least attractive of a large number of options.

IME, stupid variable
names and plain poor coding are MUCH harder to fix than weird
formatting.

I agree that variable names and well-structured code are more important
to get right than formatting. However, something expressed through
formatting is still expressed better than if it were written in
comments.

Someone should organize the ABC (Anything But Comments) movement, named
after the famous 1976 "Anybody But Carter" movement in the U.S.
Democratic Party. Hopefully, this movement wouldn't fail quite so
spectacularly.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation