[fpc-pascal] FreePascal Coding style

[Marco van de Voort]

> 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.

Depends on you requirements. 
 
> Sure, they can turn totally unreadable, terribly formatted code into 
> something more understandable, but they can never *enforce* any kind of 
> coding standard.

Nor does an editor. It can only help. I also think being to focussed on
coding standards (to the point of enforcing) is counterproductive.

> 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).

Then you'll add a tool switch to make enums tabbable. That's actually an
easier example than Graeme's original. Positioning comments, specially over
block border is what these tools are generally bad at.

Note that this is the first time that I actually saw this enum formatting as
an requirement. Do you have a criterium for this?
 
> 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?

If you make coding standards an artform, you'll need an artist. 

For me it is mainly meant functional, and a tool suffices. My main gripe
with ptop and h2pas are comment positioning.  The rest pretty much suffices.

The only exception I can see is documentation, but then you'll need meta
info to the formatter. Either in source, or out source
(unitname.enumx.style:=tabular or something in some metafile)
 
> 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. 

Depends on your definition of "properly".