Path: utzoo!attcan!uunet!mcvax!enea!kth!draken!liuida!pekka
From: pekka@majestix.liu.se (Pekka Akselin [The Mad Midnight Hacker])
Newsgroups: comp.lang.c
Subject: Scientific C style choices (+ example of MY coding standard)
Message-ID: <1136@majestix.liu.se>
Date: 13 Jan 89 05:04:06 GMT
References: <eWl9H#2cdgbS=eric@snark.UUCP> <132@mole-end.UUCP> <1045@ns.UUCP> <1066@ns.UUCP> <11091@ulysses.homer.nj.att.com>
Organization: CIS Dept, Univ of Linkoping, Sweden
Lines: 167

In article <11091@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes:
>[...]
>if (   mumble
>    && mumble
>    && mumble
>    && mumble )
>{
>	mumble;
>	mumble;
>}

I don't like this, though I AM a extremely 'visual' person.



I'd like it this way: (I apologize for my bad english, though I hope you'll
understand my words. More commments (by me) on the style just after the "file")

================ file begins ================
				<---- Line feed, for "air" in the file.
/*
 * This-file comment.		<---- Capital letter on first word and
 * Copyright info.			a period after the sentence.
 */					I. e. normal writing rules.

#include <stdio.h>
#include <ctype.h>		<---- Include's grouped together if possible.

#define up22(x)	sqrt(x)		<---- Same for define's.
#define BAD	-1

				<---- 3 line feeds.

/*
 * Externs declared here, if any.
 */

char	a_ch;			<---- Variables declared in alphbetical
char	b_ch;				order. I. e. char's are declared
					before int's and so on.
int	one1;
int	power;			/* Short comments like this ... */

/*
 * ... especially when commenting variable declarations.
 */

/*
 * Longer comments like this.
 *
 * Variables not sorted on struct or union tag's!
 */
struct weather	age;
struct old }

	int	because;
	int	why;
{ test_pattern[1] = }

	{ 2,	3}
{
union jack	labor_union:

				<---- 3 line feeds.

int	main(argc, argv)
int	argc;
char	*argv[]; {		<---- Consistent with (e.g.) if-statements.

	/*
	 * Register decl's first! But not before externs.
	 */
	register struct old	something;

	char	abc;

	int	one_two_three;

				<---- 3 line feeds.

	switch (ok) {
	case 1:			<---- Only the case tag here.
		some_proc(54);
		break;
	default:
		exit(0);
		break;		<---- I usually put a break here too.
	}

	/*
	 * All cond_expr on the same line (there are laserwriters that
	 * prints in landscape mode 8-). Comments that belongs to a part
	 * of the code is connected to it through not having line feeds
	 * after the comment.
	 */
	if (mumble && mumble && mumble && mumble) {
		code;
		code;
	} else {		<---- These on same row! No exeption!
		some_proc(3);
		if (garp && toe) {
			puts("Hello world!\n");
		}
	}			<---- Gives some space before next block.
	(void)putchar('\n');
				<---- Line feeds inserted for readability.
	exit(0);

	/*NOTREACHED*/
} /* main */

				<---- Again 3 line feeds.

unsigned int	some_proc(t)	<---- TAB's only before varible-names.
register int	t; {		<---- SPACE's otherwise.

	do {
		t++;
		t += t * 65;
		t = (unsigned char)0xff;

	} while (cond_expr1 || cond_expr2);

	return (unsigned int)t;
{ /* some_proc */
================ file ends ================

Some comments on my style:

The '}' `pulls' bak the code indentation one TAB.
Thats why I have it `under' the beginning of the statement that caused
the indentation. I always use the '{}' even if the (e.g.) if-body is
a single statement. If you do this then you always can see directly where
the else's belongs.

I have a comment after the '}' that ends a function 'cause when you have
long functions you can then see which function you edit when you are at the 
end of it (especially when you are in the progress of coding the function -
- I(!) have a short memory 8-).

The "return"-statement does NOT have paren's around it's "argument" 'cause
it's NOT a function call! It's merely a compiler directive, saying "return
to the calling function". It is NOT logical having it look like a function
call!

Cast's is `connected' to it's `argument' through not having a SPACE between
the cast and argument. It is a operator on the argument in the same manner
as the '++' or '--' operators are. Many of you code like "ptr++" or "--i"
and no one argues that. It is natural.

I always put only one statement on a row.

The case tags functions like '{}', indenting and unindenting the code.



Well that's some of my coding rules, and I think it gives readable code.
And it is my hope that you will adopt this style of coding 8-)

Have a nice day (or night or whatever is appropriate)
Thanks for having your attention for a while.

-- 
	/pekka			  
_______________________________________________________________________________
pak@ida.liu.se			  [...The Mad Midnight Hacker Strikes Again...]
Pekka Akselin, Univ. of Linkoping, Sweden  (The Land Of The Midnight Hacker 8-)