Re: fixes to assist building Apache-1.1b4 on SunOS-4.1, among other things (fwd)

[Paul Richards <p....@elsevier.co.uk>]

>>>>> "Robert" == Robert S Thau <rs...@ai.mit.edu> writes:

Robert> As a SunOS victim, I've long since given up on the native
Robert> compiler as hopelessly broken and not worth supporting.  Even
Robert> so, some of the guy's changes leave me totally perplexed, as
Robert> when he repeatedly claims to have removed "Pascal-isms" which
Robert> are "not C" and "GNU extensions".

Sme of them puzzle me too. Perhaps he could explain what he thought
was wrong in the first place.

Robert> More generally, thorough conformance to some kind of coding
Robert> standard might be nice (though I really *don't* like Berkeley
Robert> style, before anyone else brings it up; K&R with four-space
Robert> indents is what most of the code is written to currently, and
Robert> suits me fine).  However, it does require a thorough and
Robert> *correct* understanding of what the C language looks like...

A "loose" coding style would certainly make looking at other code easier,
I have a hard time following some of the code in Apache simply because it
looks so odd. What don't you like about the Berkeley style, just as a matter
of interest. I obviously like it but if nothing else, I think we should
use the function definition format from it because it makes it so easy
to search for the things. I also think ANSI C rather than K&R should be
the standard. I'm not really bothered about more cosmetic things such as
how much to indent (as long as there is indentation) but some basic
rules we hopefully all find acceptable would be usefull.

Re: fixes to assist building Apache-1.1b4 on SunOS-4.1, among other

[Tom Tromey <tr...@creche.cygnus.com>]

Ben> 1. Function declarations
Ben> a)
Ben> int
Ben> main(...)

Here's a tie-in between the coding style decision and Greg Woods'
original message: if this style of function decl is used, then the
"ansi2knr" tool (that is distributed with ghostscript, among other
things), can be used to provide compatibility with pre-ANSI compilers.
(Actually, it's a little worse than that -- you still have to turn off
prototypes somehow)

Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

Re: fixes to assist building Apache-1.1b4 on SunOS-4.1, among other

[Paul Richards <p....@elsevier.co.uk>]

>>>>> "Ben" == Ben Laurie <be...@gonzo.ben.algroup.co.uk> writes:

Ben> If we can agree on a layout then we could put a .emacs in the
Ben> source directory, and for most people, the layout would then be
Ben> semi-automatic...

Not keen on sticking that in the main tree, we could make it available
somewhere though. Not much use for non-emacs folks though.

Ben> My votes would be 1b, 2b, 3c, 4a.


Mine would be

1a, 2a, 3a, 4b

Well, off to a good start :-)

You were right though, you have a totally insane idea about good code
style :-)

Hmm, I'm actually going to argue a case for some of these points.

The main reason for "style" is not so things look pretty but to make
things clearer to understand when you're trying to read someone else's
code. 

1a) As I've already said, it's *VERY* usefull when you've got a directory
    full of files and you need to get to the actuall function's code.

2b) It's very cramped and makes code diffifult to read when there's a lot
    of it.

3b) Well, I guess this is the next most common style but I don't personally
    see that it makes the code any easier to read since the top of the loop
    is more clearly marked by the "while" statement and having the
    brace after the "while" makes it clearer and shortens the function
    so more actual code fits on the screen. I like the code to be as
    compact as possible but with enough space to make it readable - a
    compromise obviously and a matter of personal taste.

3c) Indenting the brace does very little in terms of highlighting the
    top of the loop and actually makes the brace more difficult to find
    when there's lots of code and particularly when there's lots if
    embedded loops.

4a) The extra space is just unecessary

I'll add a 5) for comments


5) Single line comments aligned with the code they refer to
	/* A single line comment, should be a valid sentence */

Multiple line comments
	/*
	 *
	 * A multiple line comment
	 * should look like this.
	 *
	 */

I don't like complex boxed comments since they're fiddly to type in and
I want to spend my time writing properly commented code not drawing lots
of asterisks around boxes.