On Monday 21 January 2008 11:59, Marco van de Voort wrote:
> I personally would spend my time improving source beautifiers like
> our own ptop (and you could make them to automatically find these
> tabstops).
Waste of time. Automated tools have never worked so far.
Sure, they can turn totally unreadable, terribly formatted code into
something more understandable, but they can never *enforce* any kind of
coding standard.
At best you can use them as tool to check against given guidelines and
spit out a warning where the tool thinks some of the guidelines are
violated (things like: "subprograms are not in alphabetical
order", "wrong indendation", "comment starts at wrong column").
As an example where most tools just put out nonsense, consider this:
|type
| CPU_Ins = (Add, Sub, Mul, Div,
| Jnz, Jz, Jnc, Jc,
| Call, Ret,
| Push, Pop,
| ...);
Now, as you can see, the instructions are laid out tabular (a lot of
tools [yes, including "elastic tabstops"] I've seen so far are unable
to handle even that simple case).
So what does the tool do? Reformat it to some kind of coding standard
like that:
type CPU_Ins = (Add, Sub, Mul, Div, Jnz, Jz, Jnc,
Jc, Call, Ret, Push, Pop, ...)
to destroy the programmer's initial intent - which was to put similar
CPU instructions into a single row and also set them out in a tabular
way to make them more distinct?
And even if the tool is a bit more intelligent and detects the tabular
design, how is it supposed to know which instructions are more similar
to the other and should appear in a row and which ones not?
Code is primarily written for humans. Otherwise we wouldn't care about
the formatting. Interestingly, to format code properly you'd need to
understand it. And that's something that currently only a human can do.
At least to my knowledge.
Vinzent.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
