
On Mon, 2008-09-08 at 14:24 +0200, Harald Geyer wrote:
> Bernd Petrovitsch <bernd@firmix.at> wrote:
> 
> > Define variables in the most inner block.
> > Rationale: No one wants to scroll up and look for the definition.
> 
> Has this already made it into some widely supported standard? Not

To the best of my knowledge: Kernighan-Richie has it.

> everything is gnu, last time I checked I think (well it's quite some
> time ago) AIX cc didn't like that and why would anybody want to write
> unportable code?

IBM should then fix their C compiler IMHO.
And details and facts please (and into the docs). Just because the
grapevine tells me something about some old compilers somewhere[0] ...
And supporting br0ken so-called "C compilers" is a different thing than
"portability".
Even less as there is some somewhat recent gcc for virtually everywhere.
While we are at it: What is the oldest relevant gcc in the field that we
want to support?
Currently new Linux kernel 2.2 and 2.4 version come out also because
gcc-3.sth doesn't compiled them anymore (so gcc-2 is virtually dead.).

> OTOH I'm not sure if block local definitions are that much of a nice 
> idea at all: Having the same variable with different definitions in

The vast majority (read: almost all) are used just once.
I have no problem with a function-wide "int i,j;" if it's used several
times. The problem are more the current line-consuming formatting making
functions larger then 2 screens (and my "screen"s are not 25 lines but
much more). And at the top, you have 15 lines of variable declaration.
Heck, perhaps I wouldn't have noticed if lots of functions are not that
large.

> different blocks of the same function is quite confusing while the
> scroll up problem can be avoided with writing short functions - not
> because they fit on one 80x24 screen, but because it's easier to
> remember.

No problem, if it's makes sense. But ATM we don't have them.
BTW I expect for each of these rules some reasonable exception
somewhere .....

> > ad formatting: Use Linux kernel coding style[3] except
> 
> I think that's not only for formatting but also for other things
> like length of functions (see above) a good guide.
> 
> > - the above "use { ... } everywhere"
Rationale:
- Avoid merge conflicts
- Have one visual pattern (and not 2) if you read it

> > - indent 4 (and not 8) positions.
>
> What's the rationale behind that?

Rationale:
I'm not a big fan of "at most $n indent levels per function and nothing
more" - you need too often just 1 more and just splitting some function
somewhere because of the indentation seems strange to me (look into the
httpinfo plugin. Most of the code is quite simple and boring anyways. So
why should one make more functions out of it just to avoid some
artificial indentation limit?).
And I'm an even lesser fan of using several lines on the screen for one
statement - just because there are only 30 columns left and it would
overflow.

The other thing is: How wide is a column?
Linux kernel has "80" (and the above $n == 3 or 4 IIRC). I live at least
"132" as my xterms/editor windows are usually much larger than 80x25.

Given 132 chars wide columns, I can easily live with 8 space indentation
(and then with tabs to indent. Emacs'ens can do both ...).

	Bernd

[0]: And I won't start with "AIX is not Unix";-)
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




