--CdrF4e02JqNVZeln
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 12, 2005 at 02:42:45PM -0800, Garrett D'Amore wrote:
> Iain Hibbert wrote:
> >>3) break long lines where possible.

> >Sure, there are some issues there but how long is too long in the modern
> >world?  I use 160 char width xterm on ~5 year old laptop - 80 column
> >terminals are surely a thing of the past?
> >
> No, for several reasons:
>=20
>     1) Lots of people don't want to start a GUI to work -- there are a
> lot of 80 column consoles displays out there.  (And some folks still
> work with actual terminals, though that is rare.)
>=20
>     2) I work with 80 column emacs windows, and tend to pull up a bunch
> of them side by side on my high res display.  This lets me maximize my
> screen content.
>=20
>     3) *Some* standard has to be defined, because 500 character lines
> are not acceptable.  80 is a reasonable standard with historical preceden=
t.
>=20
>     4) If you need to make your lines that long, then it *might* be a
> sign that your code needs to be restructured.  Deep nesting is a
> frequent sign, and maybe pulling code out into functions or changing
> your loop constructs might make it easier to read.  (More than about 3
> levels of nesting is hard for others to follow, *especially* in big
> functions.)

What he said, and additional:

It encourages you to do all validity tests at the start of a function,
and have the main piece of code at the first indentation level afterwards,
instead of being deeply indented:

Other style:

sometype foo(parameters) {
	variable declarations;
	if (parameter1 is ok) {
		if (somevariable =3D allocationfunction(someparameter)) {
			if (somehandle =3D opennetworkconnection(somevariable) {
				dosomething(somevariable,somehandle,someotherparameter);
				return result;
			} else  {
				freeprocedure(somevariable);
				return some other error code;
			}
		} else {
			return error code;
		}
	} else {
		return error code
	}
}

KNF:

sometype
foo(parameters)
{
	variable declaraitons;

	if (parameter 1 is not ok) {
		return error code;
	}
	somevariable =3D allocationprocedure(someparameter);
	if (!somevariable) {
		return some other error code;
	}
	somehandle =3D open network connection(someparameter, somevariable);
	if (invalid(somehandle)) {
		some error handling;
		goto cleanup;
	}

	do something with variable and netowrk connection;

	return result;


cleanup:
	if (valid(somevariable)) {
		freeprocedure(somevariable);
	}
	return error code;
}

The cleanup section is only really necessary if you have multiple
allocation-style initializations to undo (else all cleanup can be
done right next to the allocation error detection near the start of
the function), and can be written in the same style so that all
allocations succeeded are undone in the right order. - And the main
code is always near the left border of the terminal. If you want to
know why this is a good think, read some examples from the Amiga ROM
kernel programming manual - they do it the other way. To match=20
error handling to allocation, you have to count braces, or hope they
formatted right and use a pencil, a set square and a ruler.

[We all go through this set of instructions when we're new to the
 project - guess it's my time to explain]

Regards,
	-is

--CdrF4e02JqNVZeln
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQEVAgUBQ56RzTCn4om+4LhpAQGPpAf9EEVbW1+nSXzjVSXfhotyS7OLfDuOYSpX
DKd2EaAFLXLY+6OVcsyia1RAe/bYFVU6CfFuum6TD+uII8Ch/Xr4Vs9uyl31ny9C
Jwr8pzvJohJNESJY8pspmppn922dUC2aYVRJaBOVfnxdCy+3DpChMgt8cTMJuH1X
TPFZJ4fc0DZD2seaFT6SkqF8yhXuRjOP5lX7eHnbw7Zg+z6Ss+wBiykRld62DYhM
I2pJGNzRacXVGBHJZxLsls9HYS0KoNy0EpTCvtX1sdXLC590dnTMftcfBC56codc
vCLwheyPQjZ4eXuW6TOum8eH8iPYidthviyABrB1on2O+RLRFuG7JA==
=Q2kV
-----END PGP SIGNATURE-----

--CdrF4e02JqNVZeln--