Hi,

 ac> A while ago I worked on cleaning-up some of the source files, but
 ac> there is still work left to do in that area, but it's rather time
 ac> consuming and not very interesting.
This work is indeed annoying. But one can make changes step by step. If one
works in a local one can adjust just this function and so on. This takes
time, but divided into pieces, one can migrate the old code.

 ac> I wouldn't bother with changing the all function names of the old
 ac> code unless you can work out some automated way of doing it.  This
 ac> is not necessarily as easy as just doing a string replace on all
 ac> the source files, because you can end up changing things that
 ac> aren't function names, eg. string literals.
Yes. This a problem. Especially with lowlevel functions, which are called
from a lot of different places.

 ac> Put them all in a struct, eg.

 ac> static struct
 ac> {
 ac>     word NumMacros;
 ac> }
 ac> glob;

 ac> It may be useful to calloc glob instead of using a static struct,
 ac> but you'd need to make this decision early on, because you'd then
 ac> need to use "glob->" instead of "glob."
throughout the code.
Huh? I've never heard about this idea. Does this scheme have some nifty
advantages? However the static idea won't work, or you have to put
everything in large module. This is not feasible, I think.... The
init-function should be mandatory. Every global variable should be
explicitely initialised.

 ac> I tend to think there are a lot of functions that aren't marked
 ac> static that should be.  Working out which ones they are sounds
 ac> rather laborious without automated tools.
However it's worth a try to clean up the namespace. My principle is:
"As much as necessary, but as less(?) as possible" (less is
more).

 MB>> I'd like to suggest also to include some parts of style(9) of
 MB>> FreeBSD. Most of that resembles my opinion on good coding style.
 ac> Which ones?  But I probably agree.
The commenting style, macro names are uppercase, do {} while (0) for
macros, putting the backslash to the right in multiline-macros, (well) the
alignement of member names in structsm, function prototypes, alignement of
prototypes, commenting the code (with helpful comments, not trivialities),
helping labels like "/*NOTREACHED*/" or
"/*FALLTHROUGH*/", K&R-style braces (this is just my opinion.
we should stick with ... eh... Ansi-style?), conditions on adding braces to
a for or if construct, adding braces to increase readability (my favourite
quote: Do YOU understand the following?

a = b->c[0] + ~d == (e || f) || g && h ? i : j >> 1;
k = !(l & FLAGS);
), sorting the local variable declarations
Those are the main points (more or less).

 MB>> char *foo;
 MB>> unsigned int bla;
 MB>> int bar, baz;
versus
 MB>> unsigned int    bla;
 MB>> char           *foo;
 MB>> int             bar, baz;
 ac> I find the first one more readable actually.
Huh? Really? Ok. Maybe I'm a table fetishist, but I find it easier to just
look on the right: "Ah frob is a ... long. Fine."
 
We should put a STYLE into the distribution.

Ciao
Meikel

--- timEd/FreeBSD 1.11.a5