Formatting in FreePascal

[kupferstecher]

@lucamar, @howardpc:
Thanks! You guided me in the correct direction.
I changed the setting in IDE Options->Codetools->Words->"Keyword policy" to "none". With this setting no lower casing is enforced and Shift+Ctrl+C will use (and enforce) the same notation in the implementation section as is found in the interface section.

I advocate to make that the default setting. Less dictation by the IDE 

[440bx]

I'll use this style and nothing can make me change my mind there.

I expected no different.  I would have considered changing your mind a miracle beyond Christ's second coming.

There is no wrongly formatted code, because formatting is not fixed in Pascal, it's not part of the language. There are only guidelines. And every project can choose it's own style to adhere to.

Nice try but, there is wrongly formatted code.  The quintessential example is

Code: Pascal  [Select][+][-]

1. if <condition> then
2.    if <anothercondition> then <statement>
3. else <statement>
4.  

which is wrong because it incorrectly pretends the else associates with the outer if instead of the inner one.  The formatting you use gives the impression "if" statements are terminated by "end" and, as a compiler developer, you know very well they are not.  Your formatting is wrong because it violates the language's structure and, you can't slide that under the "style" rug.

Code: Pascal  [Select][+][-]

1. with TBarSeries(Result) do begin
2.   <snip>
3.   if APlotType = ptBars then begin
4.     AxisIndexX := AChart.LeftAxis.Index;
5.     AxisIndexY := AChart.BottomAxis.Index;
6.   end else if APlotType = ptWhatEver then begin
7.     // whatever
8.   end else begin
9.     AxisIndexX := AChart.BottomAxis.Index;
10.     AxisIndexY := AChart.LeftAxis.Index;
11.   end;
12. end;
13.  

That is wonderful (not!)

You need not mention again you won't change your mind.  I know you won't. 

[dbannon]

Nice try but, there is wrongly formatted code.

Oh, lets not get too excited here. Formatting in Pascal is about style, not syntax (like in Python).  PascalDragon's (and my) preferred style is just that, our preference. It compiles fine and is, to us at least, more readable. If you are uncomfortable reading it, its just because its not a style you use. If you found yourself working in a team where that style was required, I am quite sure you would adapt to it quite quickly, perhaps not prefer it but you would have no trouble reading in.

.......The formatting you use gives the impression "if" statements are terminated by "end" and,......

No, to me it gives the impression that if - begin statements are terminated by end. The bolding makes that so easy.

There are heaps of other 'personalisations' we all use, capitals, CamelCase etc. I read once about a researcher who was identifying the author of a piece of code by collating all those idiosyncrasies to establish a signature. I once had to use Ada for a while, its all about taking away any of those personalisations, in theory, any two programmers would produce identical code for a particular problem. It was horrible !

Davo

[440bx]

Nice try but, there is wrongly formatted code.

Oh, lets not get too excited here.

I'm not getting excited but, it does bother me when indentation does not reflect the structure of the language.

Formatting in Pascal is about style,

I honestly don't believe that.  In Pascal, "begin" is terminated with an "end", because of that, they should be at the same level.  This isn't a choice I make, it's inherent in the structure of the language.  I know that "deforming" the language structure is commonly done and swept under the rug of "style" but, I don't consider that to be valid or justified.

PascalDragon's (and my) preferred style is just that, our preference.

I understand that but, it certainly isn't the preference of the compiler.  If someone chose to write a piece of code like this:

Code: Pascal  [Select][+][-]

1. if <condition> then
2.   <statement>
3.   <statement>
4. end;

As much as some people "prefer" that, a standard Pascal compiler would not accept it.

It compiles fine

Yes, it does but, it visually breaks the structure of the language.  That's the part that is objectionable.

and is, to us at least, more readable.

I cannot figure out how some people find that "style" more readable.  You have to scan more text from left to right to mentally build the blocks because "begin" is not aligned with "end".  Because the formatting doesn't reflect the structure of the language, the reader has to mentally scan and restructure the text for it to match the structural semantics of the language.  It's a lot more work for the person who reads the code.

If you are uncomfortable reading it, its just because its not a style you use. If you found yourself working in a team where that style was required, I am quite sure you would adapt to it quite quickly, perhaps not prefer it but you would have no trouble reading in.

I honestly wouldn't work as part of a team that required that "style".  I'd wish them good luck and work someplace else.

There are heaps of other 'personalisations' we all use, capitals, CamelCase etc.

There should be a reason for a "personalization" to exist. For instance, it is quite common to uppercase constants.  The reason is make it obvious anywhere in the program they are a constant.  I consider such "personalizations" to be justified and useful. 

Breaking the alignment level of a begin/end pair is a "personalization" that is "justified" with the poor argument that it saves one line and in many cases it doesn't even do that.  Consider this

Code: Pascal  [Select][+][-]

1. if <somecondition> then
2. begin  // not a singularity point, calculate the derivative at the point
3.   <statement>
4.   <statement>
5. end
6. else   // a singularity point, inform the reader how it will be handled.
7. begin
8.   <statement>
9.   <statement>
10. end;
11.  

Since the "begin" is on a separate line, a comment can be appended to it informing the programmer what the group of statements is for.  When the "begin" is not on a separate line, either there is no good place for the comment or the comment has to be on a separate line nullifying the "one line gain" used to justify not putting on a line by itself.

The real problem is that a lot of indentation "styles" have no justification other than "I like this way".  That's not much of a solid foundation to justify it.

[dbannon]

I cannot figure out how some people find that "style" more readable....

As I said, its a style thing. I cannot understand how your mode is more readable.

I honestly wouldn't work as part of a team that required that "style".  I'd wish them good luck and work someplace else.

Well, don't think I ever had a job applicant ask to see our style guide at an interview !  But maybe it would be reasonable to do so.

Consider this

Code: Pascal  [Select][+][-]

1. if <somecondition> then
2. begin  // not a singularity point, calculate the derivative at the point
3.   <statement>
4.   <statement>
5. end
6. else   // a singularity point, inform the reader how it will be handled.
7. begin
8.   <statement>
9.   <statement>
10. end;
11.  

My version

Code: Pascal  [Select][+][-]

1. if <somecondition> then begin  // not a singularity point, calculate the derivative at the point
2.   <statement>
3.   <statement>
4. end else   begin // a singularity point, inform the reader how it will be handled.
5.   <statement>
6.   <statement>
7. end;
8.  

Yes, I agree that putting begin on its own line does leave more room for comments, thats an argument your way. But I do generally manage to do the same thing my way, I code to 132 characters, long gone are the days when we printed code on an 80 column printer.

The real problem is that a lot of indentation "styles" have no justification other than "I like this way".  That's not much of a solid foundation to justify it.

No, thats not true. I like the more compact model that fits more of a function on screen. I find that far more valuable a benifit than your (valid) points. In our very simple examples, I am using up 30% less lines !

But honestly, we are fortunate that you are free to do it your way and I am free to do it my way, agree ?

Davo

[440bx]

But honestly, we are fortunate that you are free to do it your way and I am free to do it my way, agree ?

Davo

Yes, I definitely agree with that.

[Zoran]

Code: Pascal  [Select][+][-]

1. with TBarSeries(Result) do begin
2.   <snip>
3.   if APlotType = ptBars then begin
4.     AxisIndexX := AChart.LeftAxis.Index;
5.     AxisIndexY := AChart.BottomAxis.Index;
6.   end else if APlotType = ptWhatEver then begin
7.     // whatever
8.   end else begin
9.     AxisIndexX := AChart.BottomAxis.Index;
10.     AxisIndexY := AChart.LeftAxis.Index;
11.   end;
12. end;
13.  

I also have used exactly same formatting for many years.

In my opinion this naturally belongs in one line:

Code: Pascal  [Select][+][-]

1. end else if SomeCondition then begin

With correct indenting it is the most readable style to me.

Apart from this, I pretty much agree with Delphi style guide.

And I find specifically ugly to see operators (except dot operator) not surrounded with spaces:

Code: Pascal  [Select][+][-]

1. // Ugly:
2. if X>0 then
3.   Y:=X;

[PascalDragon]

There is no wrongly formatted code, because formatting is not fixed in Pascal, it's not part of the language. There are only guidelines. And every project can choose it's own style to adhere to.

Nice try but, there is wrongly formatted code.  The quintessential example is

Code: Pascal  [Select][+][-]

1. if <condition> then
2.    if <anothercondition> then <statement>
3. else <statement>
4.  

which is wrong because it incorrectly pretends the else associates with the outer if instead of the inner one.  The formatting you use gives the impression "if" statements are terminated by "end" and, as a compiler developer, you know very well they are not.  Your formatting is wrong because it violates the language's structure and, you can't slide that under the "style" rug.

There is one problem with your argumentation: I wouldn't format it like that. Instead it would be this:

Code: Pascal  [Select][+][-]

1. if <condition> then
2.   if <anothercondition> then
3.     <statement>
4.   else
5.     <statement>

And most likely I'd use a begin ... end pair for the outer if anyway even if not technically required:

Code: Pascal  [Select][+][-]

1. if <condition> then begin
2.   if <anothercondition> then
3.     <statement>
4.   else
5.     <statement>
6. end;

[440bx]

There is one problem with your argumentation: I wouldn't format it like that. Instead it would be this:

Of course there is, it was an example to show there is such a thing as incorrect formatting.  I'm pleased you see the problem.

[ASerge]

For over a ten years I've was use the style when begin was in the same line. It seemed strange to me that someone would agree to use an extra line. But once on the Oracle forum, where it was about formatting in PL/SQL, which is very similar to pascal, a dispute arose about why in this form:

Code: SQL  [Select][+][-]

1. PROCEDURE SOME(Param IN NUMBER)
2. IS
3.   LocalVar DATE;
4.   LocalN NUMBER;
5. BEGIN
6. ...
7. END;

"is" occupies a separate line. I liked one explanation: the function header comes first, and the implementation is a separate syntactic unit. And mixing them is wrong. And then I thought about pascal. Indeed, we do not use so:

Code: Pascal  [Select][+][-]

1. procedure Some(Param: Integer); begin
2. ...
3. end;

The same applies to the rest of the cases with begin end. Then I started trying to change my style. In addition, I was helped by the fact that the Borland team persistently used this style. Later, when the programs began to occupy not hundreds of lines, but tens of thousands, it turned out that it was easier to read the text with such a syntactically selected line, which start new code unit. Now the style with the begin in the end it seems to me crumpled.

[440bx]

And if you need to add another "if" after that "begin" where is the "end" of that "if" going to be ?... is it going to be a third "end" to the starting if ?

Correct:

Code: Pascal  [Select][+][-]

1. with TBarSeries(Result) do begin
2.   <snip>
3.   if APlotType = ptBars then begin
4.     AxisIndexX := AChart.LeftAxis.Index;
5.     AxisIndexY := AChart.BottomAxis.Index;
6.   end else if APlotType = ptWhatEver then begin
7.     // whatever
8.   end else begin
9.     AxisIndexX := AChart.BottomAxis.Index;
10.     AxisIndexY := AChart.LeftAxis.Index;
11.   end;
12. end;
13.  

I waited a few days to see if anyone who uses that "style" would notice that the above is _incorrect_. 

[Thaddy]

In Pascal a formatting style can't be incorrect. The code can be incorrect.

[440bx]

In Pascal a formatting style can't be incorrect. The code can be incorrect.

When the formatting "style" alters the language structure to pretend that "if" statements are terminated by "end", it is incorrect, in turn that often leads to incorrect code as the above showed.

[Thaddy]

I repeat: In Pascal a formatting style can't be incorrect. The code can be incorrect. I hope you'll agree.

[440bx]

I repeat

Yes, you are good at repeating.