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

[Ben Laurie <be...@gonzo.ben.algroup.co.uk>]

Paul Richards wrote:
> 
> >>>>> "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.

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

Just to add a third slant ... I don't like either of the "usual" styles, as
people who've seen my code can probably guess. I find K&R particularly
irritating because its so easy to miss opening braces. I also seem to differ
from most of the group on where to put spaces. However, consistent style is
desirable, even if it isn't a style I like. Perhaps we should start a list of
style possibilities and vote on them all...

FWIW, here's a list of possibilities I just knocked up...

1. Function declarations

a)

int
main(...)

b)

int main(...)

2. Commas

a)
	f(a, b);

b)
	f(a,b);

3. Braces

a)
	while(x) {
	    ...
	}

b)
	while(x)
	{
	    ...
	}

c)
	while(x)
	    {
	    ...
	    }

4. For statements

a)
	for(a ; b ; c)

b)
	for(a; b; c)

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

Cheers,

Ben.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

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.

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