[fpc-pascal] FreePascal Coding style

[Vinzent Hoefler]

On Monday 21 January 2008 13:27, Graeme Geldenhuys wrote:

> On 21/01/2008, Vinzent Hoefler <JeLlyFish.software at gmx.net> wrote:
> > But how would it solve
> >
> > |type
> > |   FooBar = (Foo,
> > |             Bar);
>
> Look at the flash demo on the website for an example of this!
> Lets say gEdit (linux editor) has support for ET.
>
> You would type
>
> type
> <tab>FooBar = (<tab>Foo,
> <tab>Bar );

Yes, that's what I figured. But that's wrong. Only legasthenic 
retards[1] put spaces at the inside of parentheses.

> type
>    FooBar = ( Foo,
>               Bar );

Yes. And that's precisely what I *DON'T* want: Spaces to break the 
reading flow.
To be more clear on the subject: Parentheses are not operators, although 
a lot of people like to treat them so in source code while they miss to 
put the spaces around the real operators.[2]

> The other nice thing is, it's font independent. You can even use
> variable width fonts and it will still line up correctly.

I know. I've read about this before (I think it was mentioned on 
the "Embedded Muse" a while ago).

>> Whenever 
> you press TAB, it tries to find the closest TabStop (a tabstop is NOT
> a tab character) normally from the lines before it. Then when you
> save, it can convert the alignment to spaces.

And when it reloads, everything "semantic" you put in with the tab 
stops, got lost. Effort wasted, file needs to be reformatted.

> As I said, it took me a while to fully understand ET as well. :)

All I understood so far is the same as with all the other tools: If you 
write your code like a moron to suite the tool, the tool suits you.[3]

To put it more bluntly: Code formatting does not follow strict rules, 
there are always some heuristics involved.
So even two different formatting of the same code may not violate coding 
style. Now, a tool can choose whatever heuristic it wants, there *will* 
be corner cases where the tool will fail, no matter what heuristics it 
chooses. That's inherent to heuristics. Following stricter rules only 
leads to harder-to-read code (like the code with the misplaced 
parentheses).


Vinzent.

[1] No offense, it's not meant personally. But as someone who reads a 
whole Tom Clancy on a 5-hour train ride, I'm accustomed to a certain 
style. And that also means, any deviation from that slows me down 
considerably.
[2] Now that I know whose tool is responsible for that I can go and 
shoot the author. ;)
[3] Also see [1]. I don't need tools to slow me down.