[fpc-pascal] FreePascal Coding style

[Vinzent Hoefler]

On Monday 21 January 2008 13:54, Marco van de Voort wrote:
> > On Monday 21 January 2008 11:59, Marco van de Voort wrote:
> >
>
> 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.

Oh, come on. What if you encounter an enum that does *not* require 
such "tabbing" inside the same source file.

Of course you can do it all configurable until the tool formats as you 
would like it to format, but in the end this leads to one tool 
configuration per source file. Also to be checked in into version 
control in case the source file somehow changes and its formatting 
configuration needs to be adjusted.

> Note that this is the first time that I actually saw this enum
> formatting as an requirement. Do you have a criterium for this?

I didn't say, it's a requirement. But I don't want a tool to reformat 
code, which has been explicitely logically ordered for readability, a 
better overview over the instruction set, and for easier extensionby 
the coder.

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

No. A simple set of rules is sufficient. The only problem with those 
simple rules is that they can bend and there's no tool yet which knows 
how far it may bend the rule for formatting a certain piece of 
code... ;)

The first universal rule is that the code needs to be readable. This 
overrules any other rule anyway.

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

Yeah, great. Just like /*INDENT-OFF*/ in each and every C-source file 
I've ever checked into the company's CVS before we threw out the whole 
auto-formatting on check-in.
Ok, GNU-indent is probably not the best auto-formatter (in fact, it's 
one of the worst I've ever seen), but you get the idea, I suppose.

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

There's only one: You need to easily understand it when you read it. 
Even if you read it 10 or 15 years after it has been written. And 
contrary to popular beliefs, there's a substantial amount of visual 
appearance involved.

In other words: Sexy code is easier to understand. ;)


Vinzent.