if (expression) check

[Default User]

Re: style guidelines misguided

E. Robert Tisdale wrote:

[color=blue]
> Overly restrictive style guidelines signal gross mismanagement.[/color]


As usual, the best idea with ERT advice is to read it and do the
opposite.




Brian

[Flash Gordon]

Re: style guidelines misguided

E. Robert Tisdale wrote:[color=blue]
> Keith Thompson wrote:
>[color=green]
>> Style is a legitimate subject for code reviews.
>> If your work environment imposes style guidelines
>> that require one form or the other,
>> you should probably follow those guidelines.
>> If it's a matter of disagreement between you and a peer,
>> then your opinion is as valid as his (except, of course,
>> that your peer is right because he agrees with me).
>>
>> Ultimately,
>> it's probably more of a political question than a language question.
>> You can expect a lot of opinions here
>> but I don't think you can expect much help.[/color]
>
> Overly restrictive style guidelines signal gross mismanagement.
> They appear to be based upon the mistaken belief that
> you can forge a single "super" programmer
> out of a diverse group of individuals
> by compelling them all to write code the same way -- your way.[/color]

Nonsense. Style guides are so that anyone familiar with with the style
knows how it will be formatted and can therefore easily scan for certain
things, such as the end of a loop.
[color=blue]
> This virtually precludes code reuse
> because existing codes must be rewritten
> to conform with the style guidelines.[/color]

Nonsense. I've worked under strict guidelines and reused plenty of code.

Rule 1: Don't reformat just for the hell of it when using third party code.
Rule 2: Don't reformat just for the hell of it if the coding standard
changes.
Rule 3: When modifying code, unless it is a major rewrite follow the
existing style in the module.
Rule 4: Write all new code to the coding standard.
[color=blue]
> Good programmers use style to help them detect mistakes.
> Forcing them to use an unfamiliar style increases the likelihood
> that they will miss existing bugs and introduce new ones.[/color]

Nonsense. If they are any good they can adapt easily enough. I know
because I have done it and seen others do it.
[color=blue]
> Code review is a good idea but the purpose of code review
> is, first, to make you a better programmer
> and, second, to make your programs better.[/color]

No, where I worked it was first to determine if the code was fit for
purpose.
[color=blue]
> Your programming style doesn't matter
> as long as you are consistent.[/color]

It is easier to review a lot of code from multiple people if they all
use the same style.
[color=blue]
> If you are consistent, any competent code reviewer
> will quickly adapt to your style and will be able to spot errors
> almost as quickly as you can yourself.[/color]

Why do you think a reviewer can quickly adapt but a programmer can't?

Also, if all the programmers adopt the same style each individual has to
adapt at most once, rather than people having to repeatedly switch
styles as they move between different modules/projects.
[color=blue]
> Every programmer does *not* need to maintain every code module.[/color]

No, but a programmer may need to move on to any of the other modules or
other other projects. Over the years I have often been called on to help
out on other peoples work and having them using the same style makes it
easier to follow.
[color=blue]
> Good managers must be able to exploit specialized skills
> and assign modules to the programmers most qualified
> to develop and maintain those modules.[/color]

So? If anything that makes it more likely that different developers will
have to look at and work on the code.
[color=blue]
> Good software engineers must be able to decompose a software package
> into independent modules and negotiate well defined interfaces
> between those modules so that the programmers assigned to those modules
> can work independently of each other.[/color]

So?
[color=blue]
> In other words, good software design should be able to accommodate
> various programming styles just as it *must* be able to exploit
> various specialized skills.[/color]

Exploiting specialised skills does not require using different coding style.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[gooch]

Re: style guidelines misguided


"E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
news:dekuub$ssq $1@nntp1.jpl.na sa.gov...
[color=blue]
> Overly restrictive style guidelines signal gross mismanagement.
> They appear to be based upon the mistaken belief that
> you can forge a single "super" programmer
> out of a diverse group of individuals
> by compelling them all to write code the same way -- your way.[/color]

Your idea of overly restrictive probably does not coincide with everyone
elses idea of overly restrictive so how do you then say this is too much and
that is not. Someone has to be the person to make the final decision and in
any organization I have ever worked for it was done not only with management
involved but developers as well.

The idea that can't all produce very similar code is nonesense. If every
programmer has to learn every other programmers style you will be wasting
much more time than if every programmer simply learns the standard style.
[color=blue]
> This virtually precludes code reuse
> because existing codes must be rewritten
> to conform with the style guidelines.
> Good programmers use style to help them detect mistakes.
> Forcing them to use an unfamiliar style increases the likelihood
> that they will miss existing bugs and introduce new ones.
>[/color]

What are you talking about. Style in no way precludes reuse unless you are
simply not smart enough to make the decision that reused code does not get
altered.
[color=blue]
> Code review is a good idea but the purpose of code review
> is, first, to make you a better programmer
> and, second, to make your programs better.
> Your programming style doesn't matter
> as long as you are consistent.[/color]

So you don't think that a reviewers first goal should be to make sure the
code does what it was actually designed to do. I am glad I don't have you on
my team.
[color=blue]
> If you are consistent, any competent code reviewer
> will quickly adapt to your style and will be able to spot errors
> almost as quickly as you can yourself.
>[/color]

Just as a good developer can easily adapt to a new style. The difference is
your way the adaptation has to occur multiple times and the other way
everyone only adapts once.
[color=blue]
> Every programmer does *not* need to maintain every code module.
> Good managers must be able to exploit specialized skills
> and assign modules to the programmers most qualified
> to develop and maintain those modules.[/color]

What do you do if there is no longer anyone working on your team that is
familiar with the style used for a particular module. Even worse is how does
the manager keep track of the styles of each module. This is not a solution
it is a nightmare.
[color=blue]
> Good software engineers must be able to decompose a software package
> into independent modules and negotiate well defined interfaces
> between those modules so that the programmers assigned to those modules
> can work independently of each other.
>[/color]

What the hell does this have to do with having a sensible coding standard?
[color=blue]
> In other words, good software design should be able to accommodate
> various programming styles just as it *must* be able to exploit
> various specialized skills.[/color]

Interesting conclusion that has nothing to do with having a standard on your
code style. I can't believe you have the nerve to refer to someone who would
be that dead set against a style standard as an engineer. If you would like
to call yourself something coder may be appropriate but you are certainly
not an engineer with that attitude. Every good engineer that ever lived
understands the need for standardization including in stylistic issues. Why
do you think that engineers are taught very early on in their training the
proper way to print (write). Don't you think that other engineers could
eventually decipher their normal chicken scratch, probably so but imposing a
printing standard on engineers ensures they all do it in a similar enough
manner that they can all read.

[Keith Thompson]

Re: style guidelines misguided

"gooch" <gooch001@comca st.net> writes:[color=blue]
> "E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
> news:dekuub$ssq $1@nntp1.jpl.na sa.gov...
>[color=green]
>> Overly restrictive style guidelines signal gross mismanagement.
>> They appear to be based upon the mistaken belief that
>> you can forge a single "super" programmer
>> out of a diverse group of individuals
>> by compelling them all to write code the same way -- your way.[/color]
>
> Your idea of overly restrictive probably does not coincide with everyone
> elses idea of overly restrictive so how do you then say this is too much and
> that is not. Someone has to be the person to make the final decision and in
> any organization I have ever worked for it was done not only with management
> involved but developers as well.
>
> The idea that can't all produce very similar code is nonesense. If every
> programmer has to learn every other programmers style you will be wasting
> much more time than if every programmer simply learns the standard style.[/color]

I recently read a very interesting essay by Ken Arnold, in the Joel
Spolsky's book "The Best Software Writing I". He advocates making
coding style part of the syntax of the programming language. (He's
talking about programming languages in general, not just C.)

For example, if it were decided that if statements should be written
like this:

if (condition) {
...
}

then the following:

if( condition )
{
...
}

would be a syntax error.

Programmers would quickly adapt, simply because they'd have to. You
don't hear complaints about C keywords being in lower case, because if
you try to use "IF" rather than "if" your code won't compile.
Likewise, if your code would no longer compile if you used a
non-standard layout, you'd quickly learn to conform.

The result: Not only would code be more consistent and easier to read,
but we'd stop wasting time arguing about where the braces go.

Drawbacks: None that I can think of (except that it's not likely to
happen in real life).

See also Henry Spencer's 8th Commandment:

Thou shalt make thy program's purpose and structure clear to thy
fellow man by using the One True Brace Style, even if thou likest
it not, for thy creativity is better used in solving problems than
in creating beautiful new impediments to understanding.

<http://www.lysator.liu .se/c/ten-commandments.ht ml>

Perhaps some particular style really is more efficient than the
"standard" one -- but it's vanishingly unlikely that the increase in
efficiency outweighs the countless person-hours wasted arguing about
it.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Eric Laberge]

Re: style guidelines misguided

Keith Thompson wrote:
[color=blue]
> "gooch" <gooch001@comca st.net> writes:
> I recently read a very interesting essay by Ken Arnold, in the Joel
> Spolsky's book "The Best Software Writing I". He advocates making
> coding style part of the syntax of the programming language. (He's
> talking about programming languages in general, not just C.)[/color]
[example][color=blue]
> Programmers would quickly adapt, simply because they'd have to. You
> don't hear complaints about C keywords being in lower case, because if
> you try to use "IF" rather than "if" your code won't compile.
> Likewise, if your code would no longer compile if you used a
> non-standard layout, you'd quickly learn to conform.
>
> The result: Not only would code be more consistent and easier to read,
> but we'd stop wasting time arguing about where the braces go.[/color]
[etc.]

I think this is indeed a good idea, but I believe the *computer* should be
in charge of the coding style.

What I have in mind is something like the unix "indent" tool, with more
power/customization/a pretty configuration GUI and integrated in the design
environment or ran stand-alone before the code is uploaded to the revision
control system/repository/whatever and after it is downloaded from it.

This way, every coder can have his own coding style, and it will all look
the same for each other. This seems to me like it would be easy, just a
matter of parsing the code (keeping the comments) and rewriting it using
pre-defined or custom guidelines.

Of course, there would still be the need for comments and code documentation
standards, but this could eliminate style wars like
if (a == 0)
versus
if (0 == a)
or
if (condition) do_stuff();
versus
if (condition)
{
do_stuff();
}

Now feel free to totally crush this idea :^)
--
Eric Laberge

[Keith Thompson]

Re: style guidelines misguided

Eric Laberge <demon_lord@myr ealbox.com> writes:[color=blue]
> Keith Thompson wrote:[color=green]
>> "gooch" <gooch001@comca st.net> writes:
>> I recently read a very interesting essay by Ken Arnold, in the Joel
>> Spolsky's book "The Best Software Writing I". He advocates making
>> coding style part of the syntax of the programming language. (He's
>> talking about programming languages in general, not just C.)[/color]
> [example][color=green]
>> Programmers would quickly adapt, simply because they'd have to. You
>> don't hear complaints about C keywords being in lower case, because if
>> you try to use "IF" rather than "if" your code won't compile.
>> Likewise, if your code would no longer compile if you used a
>> non-standard layout, you'd quickly learn to conform.
>>
>> The result: Not only would code be more consistent and easier to read,
>> but we'd stop wasting time arguing about where the braces go.[/color]
> [etc.]
>
> I think this is indeed a good idea, but I believe the *computer* should be
> in charge of the coding style.
>
> What I have in mind is something like the unix "indent" tool, with more
> power/customization/a pretty configuration GUI and integrated in the design
> environment or ran stand-alone before the code is uploaded to the revision
> control system/repository/whatever and after it is downloaded from it.
>
> This way, every coder can have his own coding style, and it will all look
> the same for each other. This seems to me like it would be easy, just a
> matter of parsing the code (keeping the comments) and rewriting it using
> pre-defined or custom guidelines.
>
> Of course, there would still be the need for comments and code documentation
> standards, but this could eliminate style wars like
> if (a == 0)
> versus
> if (0 == a)
> or
> if (condition) do_stuff();
> versus
> if (condition)
> {
> do_stuff();
> }
>
> Now feel free to totally crush this idea :^)[/color]

Ok. 8-)}

Sorry, but if we were to impose style as part of the syntax, I don't
see much benefit in allowing each programmer to write in a different
style. Just define a single style and enforce it. Smart text editors
can help a lot for programmers who want to use them; the programmer
can type his parentheses and braces anywhere he likes, and they'll
*immediately* be put in the right place. Personally, I don't use a
syntax-aware editor (beyond auto-indent); I'll just write the code
correctly in the first place.

This is as much about the programmer's mindset as he's writing the
code as it is about anything else. The point is to end the debate and
spend our time on more important things.

Of course, nobody is going to stop anybody from creating whatever
tools they like, as long as the end result is syntactically correct
source code. But *if* this idea were to catch on, there would be no
more reason to let each programmer have his own coding style than to
let each programmer have his own idea of how reserved words should be
spelled. It's easy enough to create a syntax-aware editor that
transforms "IF" to "if" and "ELSE" to "} else {", but nobody has
bothered to do so.

Surely placement of punctuation marks isn't the best way you can think
of to express your individuality and creativity.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Re: style guidelines misguided

Keith Thompson wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> See also Henry Spencer's 8th Commandment:
>
> Thou shalt make thy program's purpose and structure clear to thy
> fellow man by using the One True Brace Style, even if thou likest
> it not, for thy creativity is better used in solving problems than
> in creating beautiful new impediments to understanding.
>
> <http://www.lysator.liu .se/c/ten-commandments.ht ml>
>
> Perhaps some particular style really is more efficient than the
> "standard" one -- but it's vanishingly unlikely that the increase in
> efficiency outweighs the countless person-hours wasted arguing about
> it.[/color]

At least for C it is worthwhile to keep a standard configuration
for indent available. The following (one line) is the one I use,
which results in something very close to my preferred style with
indent 2.2.9.

-kr -l66 -i3 -bad -di16 -lc66 -nce -ncs -cbi0 -bbo -pmt -psl -ts1
-cdw

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Christian Bau]

Re: style guidelines misguided

In article <ln3boxzbxe.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.org> wrote:
[color=blue]
> Sorry, but if we were to impose style as part of the syntax, I don't
> see much benefit in allowing each programmer to write in a different
> style. Just define a single style and enforce it.[/color]

On the other hand, your average programmer uses a programming editor
that leaves a few billion operations per second unused, and that is
plenty of time to display code and let me edit code in the style that
_I_ like, and lets you see code and edit code in the style that _you_
like.

Not trivial, but not really difficult either. Probably works best if a
source code control system defines a style X and translates everything
from and to style X when some programmer edits a file.

[Richard Bos]

Re: style guidelines misguided

Keith Thompson <kst-u@mib.org> wrote:
[color=blue]
> For example, if it were decided that if statements should be written
> like this:
>
> if (condition) {
> ...
> }
>
> then the following:
>
> if( condition )
> {
> ...
> }
>
> would be a syntax error.[/color]
[color=blue]
> The result: Not only would code be more consistent and easier to read,
> but we'd stop wasting time arguing about where the braces go.
>
> Drawbacks: None that I can think of (except that it's not likely to
> happen in real life).[/color]

Drawbacks: see Python.

Richard

[Default User]

Re: style guidelines misguided

gooch wrote:
[color=blue]
>
> "E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
> news:dekuub$ssq $1@nntp1.jpl.na sa.gov...[/color]

[blither blather]
[color=blue]
> Your idea of overly restrictive probably does not coincide with
> everyone elses idea of overly restrictive so how do you then say this
> is too much and that is not.[/color]


It's useless to try to have a discussion with Trollsdale. He's not
interested in rationally discussing anything, he posts his nonsense to
get a rise out of people. I don't believe for a minute that JPL lets
people program willy-nilly, he's working to a code style guide like
everyone else.




Brian

[Keith Thompson]

Re: style guidelines misguided

rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:[color=blue]
> Keith Thompson <kst-u@mib.org> wrote:[color=green]
>> For example, if it were decided that if statements should be written
>> like this:
>>
>> if (condition) {
>> ...
>> }
>>
>> then the following:
>>
>> if( condition )
>> {
>> ...
>> }
>>
>> would be a syntax error.[/color]
>[color=green]
>> The result: Not only would code be more consistent and easier to read,
>> but we'd stop wasting time arguing about where the braces go.
>>
>> Drawbacks: None that I can think of (except that it's not likely to
>> happen in real life).[/color]
>
> Drawbacks: see Python.[/color]

Hmm. Point taken. Personally, I like the way Python uses indentation
to denote structure. But I understand that a lot of people don't feel
that way. C, on the other hand, uses braces to denote structure, and
programmers are expected to use braces to communicate to the compiler
*and* indentation to communicate to human readers; great confusion
ensues if they get out of sync.

Anyway, this discussion would probably be more appropriate in
comp.lang.misc.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[E. Robert Tisdale]

Re: style guidelines misguided

Keith Thompson wrote:
[color=blue]
> I recently read a very interesting essay by Ken Arnold
> in the Joel Spolsky's book "The Best Software Writing I".
> He advocates making coding style part of the syntax of the programming language.[/color]

That's just plain silly.
[color=blue]
> (He's talking about programming languages in general, not just C.)
>
> For example,
> if it were decided that if statements should be written like this:
>
> if (condition) {
> ...
> }
>
> then the following:
>
> if( condition )
> {
> ...
> }
>
> would be a syntax error.[/color]
[color=blue]
> cat snippet.cc[/color]
if( condition )
{
...
}
[color=blue]
> indent -br snippet.c
> cat snippet.c[/color]
if (condition) {
...}
[color=blue]
> astyle snippet.c
> cat snippet.c[/color]
if (condition) {
...
}

Or you could use a code reformatter to convert the code
to your preferred format for easy maintenance
then convert it back into a format
acceptable to your overly picky code reviewer.

There is practically no reason to have or enforce style guidelines.
That's a job for a code reformatter -- not a programmer.
You probably have serious management problems
if you have team members obsessing about coding style.

Allow yourself and the programmers that you work with
to mature and to grow emotionally and intellectually.
Forget about coding style and concentrate on issues
that are really important to good design and engineering.

[Malcolm]

Re: style guidelines misguided


"E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote[color=blue]
>
> Allow yourself and the programmers that you work with
> to mature and to grow emotionally and intellectually.
> Forget about coding style and concentrate on issues
> that are really important to good design and engineering.
>[/color]
Communication with the human programmer is really important to good design
and engineering.
Compileable gibberish is asking for bugs.

[websnarf@gmail.com]

Re: if (expression) check

jamilur_rahman@ yahoo.com wrote:[color=blue]
> What is the BIG difference between checking the "if(expression) " in A
> and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
> likes style B, how can I defend myself to stay with style A ?[/color]

[instead of if(a==0) ... snipped]

Fire the guy that thinks your style is a problem. They have an
extremely weak grasp of elementary algebra and there is a very real
possibility that they are a serious danger to your programming
environment. Obviously your method also has the well known property of
being resistant to the typical single = instead of == typo.

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sf.net/

[websnarf@gmail.com]

Re: style guidelines misguided

Keith Thompson wrote:[color=blue]
> "gooch" <gooch001@comca st.net> writes:[color=green]
> > The idea that can't all produce very similar code is nonesense. If every
> > programmer has to learn every other programmers style you will be wasting
> > much more time than if every programmer simply learns the standard style.[/color]
>
> I recently read a very interesting essay by Ken Arnold, in the Joel
> Spolsky's book "The Best Software Writing I". He advocates making
> coding style part of the syntax of the programming language. (He's
> talking about programming languages in general, not just C.)[/color]

This idea comes from the Python programming language, not Joel Spolsky.
I don't know if he acknowledges it, but certainly I do for a lot of
eye opening programming ideas the language has given me (even when
programming in C.)

(It really drives a nail in the coffin of the LISP guys who constantly
claim that other programming languages are really just trying to
emulate things they invented ages ago. Python ain't no Lisp rip off.)

Anyhow, the point is that there is only one style for programming
Python, and the interpretor will not really accept much variation other
than the amount of whitespace.

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sf.net/