Antwort: Re: FOP Style Guide (update)

[Arnd Beißner]

Peter B. West wrote:

> This man must be one of them there anarchists.

8-)

No, I once had to moderate a team of 15 programmers
trying to agree on formatting. I learned you have
to work with the "Carrot-and-stick" methodology.

Meaning, in this context, force the few guidelines
that really hurt if not adhered to and leave room
for personal taste where it doesn't hurt.

Personally, I run everything through a formatter
first (even FOP) when I need to modify code.
I just can't stand Kernighan/Ritchie
braces - my visual interface doesn't scan that properly. 8-)

One further anecdote:
In a company where I worked for two years, they had a
fetish regarding hungarian notation (in C) while disregaring
most every basic rule of programming (like CVS? what's that?,
Make? Why, we have batchfiles!). I was the only one who
always got away without using Hungarian notation. I always
said: Oh, I will, as soon as you have transformed all of your
pszpptr names into pszpFilename (or whatever).
Somehow, this worked.

--
Cappelino Informationstechnologie GmbH
Arnd Beißner

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Peter B. West]

Arnd Beißner wrote:

Jeremias Maerki wrote:


The following should (sorry, could) be ok:

  for (int i = 0; i < 5; i++) {
  doSomething();
  if (amIRight()) cool();
  doSomethingElse();
  }



One point here:
If it's not amIRight() but

if (amIRight() || ( more stuff follows .) cool();
doSomethingElse();

you tend to ignore the cool() stuff in favor of doSomethingElse.


Yep.  It takes an eye for layout, which seems appropriate.


I can't count the times I've seen people hunt for this kind of
bug (most when changing someone else's code, of course).

Which is why I always use:

if (foo)
  doFoo();

On the whole I think you would be served best by forbidding

if (foo) doFoo();

and allowing

if (foo)
  doFoo();
else
  doBar();

as well as

if (foo) {
  doFoo();
} 
else {
  doBar();
}

leaving this issue to personal taste.

This man must be one of them there anarchists.


Just my 2 cents.


Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Arnd Beißner]

Jeremias Maerki wrote:
> The following should (sorry, could) be ok:
>
>for (int i = 0; i < 5; i++) {
>doSomething();
>if (amIRight()) cool();
>doSomethingElse();
>}

One point here:
If it's not amIRight() but

if (amIRight() || ( more stuff follows .) cool();
doSomethingElse();

you tend to ignore the cool() stuff in favor of doSomethingElse.

I can't count the times I've seen people hunt for this kind of
bug (most when changing someone else's code, of course).

Which is why I always use:

if (foo)
  doFoo();

On the whole I think you would be served best by forbidding

if (foo) doFoo();

and allowing

if (foo)
  doFoo();
else
  doBar();

as well as

if (foo) {
  doFoo();
} 
else {
  doBar();
}

leaving this issue to personal taste.

Just my 2 cents.
--
Cappelino Informationstechnologie GmbH
Arnd Beißner

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[J.Pietschmann]

Jeremias Maerki wrote:

If only everybody would run the formatter...We're facing reality here.

I do.
We could add a Jalopy task to build.xml.
We could refuse checkins which hadn't run checkstyle and
source formatting. :)

J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Peter B. West]

J.Pietschmann wrote:



On 08.01.2003 14:23:36 Peter B. West wrote:


And it adds just a spice of danger.



I can live well without this.



Spoilsport.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Jeremias Maerki]

Hi Jörg

On 08.01.2003 16:38:04 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > I've got the same problem with that. I've found more than a few
> > occurences of that last example in FOP. It would be nice to restrict
> > that rule to one line ifs/fors/whiles. Having more than one line in
> > total should mean having to use braces.
> I don't understand this: It has different semantics.

I'll try...

This should be detected and barked at:

for (int i = 0; i < 5; i++) {
doSomething();
if (amIRight())
cool();
doSomethingElse();
}

reason: wrong indentation

...and this, too:

for (int i = 0; i < 5; i++) {
doSomething();
if (amIRight())
cool();
doSomethingElse();
}

reason: if spread over more than one line without braces.

The following should (sorry, could) be ok:

for (int i = 0; i < 5; i++) {
doSomething();
if (amIRight()) cool();
doSomethingElse();
}


> > Or if checkstyle could also check indentation...
> That's Jalopy or Emacs reindent for you.

If only everybody would run the formatter...We're facing reality here.
:-)


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Peter B. West]

J.Pietschmann wrote:

Peter B. West wrote:


if (isEnabled()) {
return true;
}

is absurd.



Not necessarily. I it *much* easier to add a
System.out.println() to this than to either

  if (isEnabled())return true;
or
  if (isEnabled())
return true;


Agreed.



If you are debugging code written by someone else,
this should be worth the trouble of the additional
line with the closing brace.


When I add the println, I also add the braces.  The motivation for 
eliminating the braces is the readability of the code when there is only 
one line, which is a very frequent occurrence.  It comes to a balance of 
motives and requirements.

I like to have as much code as possible in my viewing window, but I also 
like to scatter blank lines about - readability again, to this jaundiced 
eye.  These conflicting demands are one reason I'm so fond of compact 
one-liners.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Jeremias Maerki]

Good point.

On 08.01.2003 16:28:21 J.Pietschmann wrote:
> Peter B. West wrote:
> > if (isEnabled()) {
> > return true;
> > }
> > 
> > is absurd.
> 
> Not necessarily. I it *much* easier to add a
> System.out.println() to this than to either
> 
>if (isEnabled())return true;
> or
>if (isEnabled())
>  return true;
> 
> If you are debugging code written by someone else,
> this should be worth the trouble of the additional
> line with the closing brace.


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[J.Pietschmann]

Jeremias Maerki wrote:

I've got the same problem with that. I've found more than a few
occurences of that last example in FOP. It would be nice to restrict
that rule to one line ifs/fors/whiles. Having more than one line in
total should mean having to use braces.

I don't understand this: It has different semantics.


Or if checkstyle could also check indentation...

That's Jalopy or Emacs reindent for you.


On 08.01.2003 14:23:36 Peter B. West wrote:

And it adds just a spice of danger.


I can live well without this.

I got used to always add braces.
1. You don't have to think whether you have one or more
   than one statement in the control statement body.
2. Adding braces to an existing statement because another
   statement is added is more disrupting to the editing
   process than adding it right from the beginning.
   Especially the
 if (foo)
   dobar();
 else
   dobaz(),
   case is bad.
3. If I temporarily add a println() for traces, I sure
   wont delete the braces after the println is deleted.
   You'll have to live with the inconsistency.

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[J.Pietschmann]

Peter B. West wrote:

if (isEnabled()) {
return true;
}

is absurd.


Not necessarily. I it *much* easier to add a
System.out.println() to this than to either

  if (isEnabled())return true;
or
  if (isEnabled())
return true;

If you are debugging code written by someone else,
this should be worth the trouble of the additional
line with the closing brace.


J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Peter B. West]

Jeremias Maerki wrote:


Or if checkstyle could also check indentation...



*That* would be extremely useful, and would solve the problem.  Maybe a 
Python preprocessor  Joke, folk.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Jeremias Maerki]

I've got the same problem with that. I've found more than a few
occurences of that last example in FOP. It would be nice to restrict
that rule to one line ifs/fors/whiles. Having more than one line in
total should mean having to use braces. Unfortunately, checkstyle
doesn't support that. Maybe that's something for their wishlist.

Or if checkstyle could also check indentation...

Well, I agree that it's easier to read, but I want to be on the safe
side when it comes to semantic differences (you only have to add two
characters to really play safe). So, if checkstyle doesn't support the
above, I'd rather leave the settings as they are (even though I started
this in the first place).

On 08.01.2003 14:23:36 Peter B. West wrote:
> Christian Geisert wrote:
> > Peter B. West wrote:
> > 
> >> Jeremias Maerki wrote:
> >>
> >>> Since I've made the checkstyle.cfg file an integral part of our style
> >>> guide I have to bring this up before changing:
> >>>
> >>> I'd like to add a line "checkstyle.ignore.braces = yes". This enables
> >>> one line ifs like the following:
> > 
> > 
> > [..]
> > 
> >> if (isEnabled)
> >> doOneLiner();
> >> else
> >> return false;
> >>
> >> which is easier to read than
> >>
> >> if (isEnabled()) doOoneLiner();
> >> else return false;
> > 
> > 
> > And what about this:
> > 
> > if (isEnabled())
> > doThis();
> > doThat();
> > 
> > Yes, I like explicit braces.
> 
> For the above reason, which is the primary argument for them.  It's 
> usual expression would, I think, involve changes to the code, so that 
> what started as
> 
> if (isEnabled())
>  doOneLiner();
> else
>  doOtherOneLiner();
> 
> becomes
> 
> if (isEnabled())
>  doOneLiner();
> else
>  doOtherOneLiner();
>  oopsForgotThisOne();
> 
> which errors can be hard to find when the indentation confuses the 
> issue.  Nonetheless, I prefer the braceless style for one-liners, 
> because it is easier to read, IMO.  And it adds just a spice of danger.


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Peter B. West]

Christian Geisert wrote:

Peter B. West wrote:


Jeremias Maerki wrote:


Since I've made the checkstyle.cfg file an integral part of our style
guide I have to bring this up before changing:

I'd like to add a line "checkstyle.ignore.braces = yes". This enables
one line ifs like the following:



[..]


if (isEnabled)
doOneLiner();
else
return false;

which is easier to read than

if (isEnabled()) doOoneLiner();
else return false;



And what about this:

if (isEnabled())
doThis();
doThat();

Yes, I like explicit braces.


For the above reason, which is the primary argument for them.  It's 
usual expression would, I think, involve changes to the code, so that 
what started as

if (isEnabled())
doOneLiner();
else
doOtherOneLiner();

becomes

if (isEnabled())
doOneLiner();
else
doOtherOneLiner();
oopsForgotThisOne();

which errors can be hard to find when the indentation confuses the 
issue.  Nonetheless, I prefer the braceless style for one-liners, 
because it is easier to read, IMO.  And it adds just a spice of danger.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Christian Geisert]

Peter B. West wrote:

Jeremias Maerki wrote:


Since I've made the checkstyle.cfg file an integral part of our style
guide I have to bring this up before changing:

I'd like to add a line "checkstyle.ignore.braces = yes". This enables
one line ifs like the following:


[..]


if (isEnabled)
doOneLiner();
else
return false;

which is easier to read than

if (isEnabled()) doOoneLiner();
else return false;


And what about this:

if (isEnabled())
doThis();
doThat();

Yes, I like explicit braces.

Christian


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Michael Gratton]

Michael Gratton wrote:


Surely:

  return isEnabled();

is far, far better - it more clearly expresses your intent.



Err, unless you don't want to return if isEnabled() returns false.. I 
think I might go get that coffee now..

:(

Anyway, I don't think

  if (isEnabled()) {
  return true;
  }

is too onerous. Sun's code conventions reccomend it.

/mike

--
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Michael Gratton]

Jeremias Maerki wrote:


if (isEnabled()) return true;



Surely:

  return isEnabled();

is far, far better - it more clearly expresses your intent.

--
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Peter B. West]

Jeremias Maerki wrote:

Since I've made the checkstyle.cfg file an integral part of our style
guide I have to bring this up before changing:

I'd like to add a line "checkstyle.ignore.braces = yes". This enables
one line ifs like the following:

if (isEnabled()) return true;

Without this line, you have to write:

if (isEnabled()) {
return true;
}

Please speak up if the change is unwelcome. Thanks.


Jeremias,

The change is most welcome.

if (isEnabled()) {
return true;
}

is absurd.  However, if I can do

if (isEnabled()) return true;

should I not be able to do

if (isEnabled() && someOtherVerboseCondition())
return true;

and also

if (isEnabled)
doOneLiner();
else
return false;

which is easier to read than

if (isEnabled()) doOoneLiner();
else return false;

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Jeremias Maerki]

Since I've made the checkstyle.cfg file an integral part of our style
guide I have to bring this up before changing:

I'd like to add a line "checkstyle.ignore.braces = yes". This enables
one line ifs like the following:

if (isEnabled()) return true;

Without this line, you have to write:

if (isEnabled()) {
return true;
}

Please speak up if the change is unwelcome. Thanks.

Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Style Guide (update)

[Joerg Pietschmann]

On Friday 03 January 2003 10:16, Jeremias Maerki wrote:
> (Joerg, I'm still missing your comments.)
Done, added a lot of comments!

J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: FOP Style Guide (update)

[Victor Mote]

Jeremias Maerki wrote:

> I've just restyled our style guide draft for the ApacheWiki and would
> like to finalize this within the next two weeks. I will then clean up
> the page and call for a vote. Given we reach consensus I will then
> convert the Wiki page to XML and put it on our website.

I just now added the following item to the "XML code conventions" section:

<-- start -->
Regarding "pretty-printing", it is preferred that XML files contain lines no
longer than 80 characters. Wrap lines in the same tag to the beginning of
the line, regardless of the indentation for the beginning of the element.
Consider placing a newline between sentences to minimize the number of
deltas resulting from pretty-printing.
<-- end -->

It is styled as a suggestion, and it may be debatable at that. If it creates
any controversy, I don't mind removing it. I have just gotten done wrestling
with what standards we should use for our in-house XML files. The main issue
is the usefulness of diffs between different versions of the file. If a long
element is all on one line, it is difficult to see where the delta is.

Sorry for the late entry -- I had decided to stay out of the style issue.
However, I think this is worth addressing.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

FOP Style Guide (update)

[Jeremias Maerki]

Hello all

I've just restyled our style guide draft for the ApacheWiki and would
like to finalize this within the next two weeks. I will then clean up
the page and call for a vote. Given we reach consensus I will then
convert the Wiki page to XML and put it on our website.

(Joerg, I'm still missing your comments.)

Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]