Print Page - Formatting in FreePascal

Programming => General => Topic started by: rnfpc on July 22, 2019, 04:40:46 am

Title: Formatting in FreePascal
Post by: rnfpc on July 22, 2019, 04:40:46 am

One of the reasons for success of Python is its code formatting/indentation. I find that Pascal formatting, though very clear, can be further simplified to Python-type formatting.

Following is some code (which really has 3 statement blocks: with, if and else) with 2 types of formatting:

Traditional Pascal:

Code: Pascal [Select][+]

with TBarSeries(Result) do
  begin
    BarBrush.Color := AColor;
    BarPen.Color := AColor;
    BarWidthStyle := bwPercentMin;
    if APlotType = ptBars then 
      begin
        AxisIndexX := AChart.LeftAxis.Index;
        AxisIndexY := AChart.BottomAxis.Index;
      end 
    else 
      begin
        AxisIndexX := AChart.BottomAxis.Index;
        AxisIndexY := AChart.LeftAxis.Index;
      end;
  end;

Modified (python-like):

Code: Pascal [Select][+]

with TBarSeries(Result) do begin
  BarBrush.Color := AColor;
  BarPen.Color := AColor;
  BarWidthStyle := bwPercentMin;
  if APlotType = ptBars then begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
    end
  else begin
    AxisIndexX := AChart.BottomAxis.Index;
    AxisIndexY := AChart.LeftAxis.Index;
    end;
  end;

The modified version results in less lines (separate line for begin is avoided) and less indentation (indentation for begin and end are avoided) so that 3 statement blocks are seen clearly.

I am interested in views of other users on this forum.

Title: Re: Formatting in FreePascal
Post by: 440bx on July 22, 2019, 05:33:26 am

Quote from: rnfpc on July 22, 2019, 04:40:46 am

One of the reasons for success of Python is its code formatting/indentation.

You may be right but, personally, I doubt it.

Quote from: rnfpc on July 22, 2019, 04:40:46 am

I find that Pascal formatting, though very clear, can be further simplified to Python-type formatting.

When I find code formatted in the "python way" you suggested, the first thing I do is reformat it to make its logical blocks more evident.

I'd format the snippet of code you presented as follows:

Code: Pascal [Select][+]

with TBarSeries(Result) do
begin
  BarBrush.Color := AColor;
  BarPen.Color   := AColor;
  BarWidthStyle  := bwPercentMin;
 
  if APlotType = ptBars then
  begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end
  else
  begin
    AxisIndexX := AChart.BottomAxis.Index;
    AxisIndexY := AChart.LeftAxis.Index;
  end;
end;

A begin/end denotes a compound statement that is controlled by its "owner" (in your example, the "with" and the "ifs".) Since compound statements are surrogates to their owner, they (IMO) should be at the same level of indentation since they are logically at the same level.

Quote from: rnfpc on July 22, 2019, 04:40:46 am

The modified version results in less lines (separate line for begin is avoided) and less indentation (indentation for begin and end are avoided) so that 3 statement blocks are seen clearly.

A separate line for "begin", not only should _not_ be avoided, it should be required because it marks the beginning of a block which should be aligned with the keyword that marks its end (in this case "end".)

One of the things I find most annoying in C code are "definitions" that go like this:

Code: C [Select][+]

struct astruct {
  SOMETYPE somefieldname;
  int someotherfieldname;
}

For trivial definitions it's easy to "see" that it's one block but, when the data type has many other structured types in it, matching the "{" to the "}" is a pain, particularly when you have to add a new struct or field somewhere in there. Another thing that makes the entire thing look like a blob of text is the total lack of alignment of types and variable/field names. A large and complex structure defined like that is "binary roadkill". Fortunately, most C programmers figured out that indenting the definitions a couple of spaces makes it easier to read. In a few centuries, evolution willing, they might start formatting code halfway decently. Evolution is really a great thing, too bad it's so slow.

Quote from: rnfpc on July 22, 2019, 04:40:46 am

I am interested in views of other users on this forum.

Good indentation can make a program much easier to read and understand.

Title: Re: Formatting in FreePascal
Post by: eric on July 22, 2019, 07:56:21 am

I'm totally with 440bx on this. That's exactly how I do it. Indenting each end to the same level as its corresponding begin makes the structure beautifully clear, and helps to avoid some awkward bugs.

Title: Re: Formatting in FreePascal
Post by: PascalDragon on July 22, 2019, 09:05:03 am

Quote from: rnfpc on July 22, 2019, 04:40:46 am

One of the reasons for success of Python is its code formatting/indentation. I find that Pascal formatting, though very clear, can be further simplified to Python-type formatting.

Python requires proper formatting as there it is part of the syntax. In other languages and especially Pascal this is not the case as everyone can choose their own style. Thus "measuring" the success of Pascal on that is nonsense.

By the way, when not working on the compiler, this is how I format my code:

Code: Pascal [Select][+]

with TBarSeries(Result) do begin
  BarBrush.Color := AColor;
  BarPen.Color := AColor;
  BarWidthStyle := bwPercentMin;
  if APlotType = ptBars then begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end else begin
    AxisIndexX := AChart.BottomAxis.Index;
    AxisIndexY := AChart.LeftAxis.Index;
  end;
end;

Title: Re: Formatting in FreePascal
Post by: 440bx on July 22, 2019, 09:21:23 am

Quote from: PascalDragon on July 22, 2019, 09:05:03 am

By the way, when not working on the compiler, this is how I format my code:
Code: Pascal [Select][+][-]
with TBarSeries(Result) do begin
<snip>
if APlotType = ptBars then begin
AxisIndexX := AChart.LeftAxis.Index;
AxisIndexY := AChart.BottomAxis.Index;
end else begin
AxisIndexX := AChart.BottomAxis.Index;
AxisIndexY := AChart.LeftAxis.Index;
end;
end;

The problem with that formatting is that it shows an "if" terminated with two "end"(s). If statements are not terminated with "end"(s).

Title: Re: Formatting in FreePascal
Post by: rnfpc on July 22, 2019, 09:41:03 am

@PascalDragon : you are 50% with Python-type formatting!

If you indent 'end's (and start 'else' on a new line with de-indentation), you will be 100%.

Title: Re: Formatting in FreePascal
Post by: marcov on July 22, 2019, 09:50:24 am

Quote from: rnfpc on July 22, 2019, 04:40:46 am

The modified version results in less lines (separate line for begin is avoided) and less indentation (indentation for begin and end are avoided) so that 3 statement blocks are seen clearly.

I am interested in views of other users on this forum.

The core meaning of indentation is readability, not to get is as short as possible (then put everything on one line with a space between it).

This way, to scan structure validity you have to constantly move your eyes from left to right to catch all those begins. Pascal isn't a tennis game.

Moreover while a known alternative, it is the minority position, and going against majority rules is generally a bad thing anyway.

Title: Re: Formatting in FreePascal
Post by: kupferstecher on July 22, 2019, 10:19:13 am

Quote from: marcov on July 22, 2019, 09:50:24 am

This way, to scan structure validity you have to constantly move your eyes from left to right to catch all those begins. Pascal isn't a tennis game.

The visual braces are build by "if [...]" and "end". You can see it from the indentation, that its a block. So there has to be a begin in the end of the line, no need to search for it.

Quote

Moreover while a known alternative, it is the minority position, and going against majority rules is generally a bad thing anyway.

Thats true. Especially if you work on more than one codebase.

I do an other custom formatting in special cases:
Outer loops/ifs I sometimes write in capital letters to make them more outstanding and thus more readable.

Code: Pascal [Select][+]

begin
  [...]
 
  WHILE NOT Terminated DO BEGIN
 
    if not self.Enabled then BREAK;
 
    If SomeValue >= 0 Then Begin
      lastItem:= 0;
      for aitem in SomeArray do begin
        aItem:= lastItem + aItem * SomeValue;
        lastItem:= aItem;
      end;//do      
 
    End Else Begin
     for aitem in SomeArray
     do aItem:= aItem * SomeValue;
 
    End;//If
 
    [...]
 
  END;//DO
 
 
end;

Title: Re: Formatting in FreePascal
Post by: dbannon on July 22, 2019, 10:20:50 am

Quote from: rnfpc on July 22, 2019, 09:41:03 am

@PascalDragon : you are 50% with Python-type formatting!

"Python -type" ? I was writing pascal code formatted like PascalDragon just showed us before Python was invented.

I still do, saving a few lines increases my chance of seeing a complete function on screen. I believe that is the key to readability.

Davo

Title: Re: Formatting in FreePascal
Post by: BrunoK on July 22, 2019, 10:25:38 am

My parameters for Jedi Code Formatter give this result, it looks quite like python and I have used that when programming in Quick Basic Compiled in the 80's and then in Delphi / Lazarus+FPC since the end of the 90's. And also in small teams in COBOL earlier.
Actually when I work on some parts of FPC, the first thing I do, if it is not something approaching PascalDragon's style, is to do a big JCF run on the concerned unit or some of the parts I want to work on or understand.

Code: Pascal [Select][+]

  with TBarSeries(Result) do begin
    BarBrush.Color := AColor;
    BarPen.Color := AColor;
    BarWidthStyle := bwPercentMin;
    if APlotType = ptBars then begin
      AxisIndexX := AChart.LeftAxis.Index;
      AxisIndexY := AChart.BottomAxis.Index;
    end
    else begin
      AxisIndexX := AChart.BottomAxis.Index;
      AxisIndexY := AChart.LeftAxis.Index;
    end;
  end;
 

or kupferstecher example

Code: Pascal [Select][+]

    while not Terminated do begin
      if not self.Enabled then
        BREAK;
      if SomeValue >= 0 then begin
        lastItem := 0;
        for aitem in SomeArray do begin
          aItem := lastItem + aItem * SomeValue;
          lastItem := aItem;
        end;//do
      end
      else begin
        for aitem in SomeArray do aItem := aItem * SomeValue;
      end;//If
      // [...]
    end;//DO
 

One of the most unreadable unit is \rtl\inc\objpas.inc with strange indent and spurious empty lines, others use a 1 character indent, these are awful and spells much doubt on the FPC developer comprehension of its code, I wont cite name ...
Lazarus is in general reasonably OK except for one package that is buggy and untestable/not understandable due to 1 character indent.

My preference is for indents to be at least as wide as one line height or an even multiple of that, problem occasionally appeearing in multiline bits of code (complicated if's, cstring concatenation, long formulas).
The python like formatting is not very good because the end is indented like the boby of the condition so it is difficult, visually to understand where the IF or WITH statements end.

Title: Re: Formatting in FreePascal
Post by: rnfpc on July 22, 2019, 10:37:41 am

We often have to use "//do" after 'end's to clarify. This is not needed in pythonic (or whatever name it can be given) format:

Code: Pascal [Select][+]

while not Terminated do begin
  if not self.Enabled then
    BREAK;
  if SomeValue >= 0 then begin
    lastItem := 0;
    for aitem in SomeArray do begin
      aItem := lastItem + aItem * SomeValue;
      lastItem := aItem;
      end;
    end //for has ended above here;
  else begin
    for aitem in SomeArray do 
      aItem := aItem * SomeValue;
    end;
  [...] //else has ended above here;
  end;
[...] //while has ended above here; 

Also, we use similar formatting for var, const and type declarations (without needing any begin or end):

Code: Pascal [Select][+]

var 
  i: integer;
  s: string; 
  r: real;
 

My only submission is this alternative format should be acceptable in posts here.

Title: Re: Formatting in FreePascal
Post by: marcov on July 22, 2019, 10:41:22 am

Quote from: kupferstecher on July 22, 2019, 10:19:13 am

Quote from: marcov on July 22, 2019, 09:50:24 am
This way, to scan structure validity you have to constantly move your eyes from left to right to catch all those begins. Pascal isn't a tennis game.
The visual braces are build by "if [...]" and "end". You can see it from the intendation, that its a block. So there has to be a begin in the end of the line, no need to search for it.

Indentation is a tool only. The begin is the real block structure.

Anyway, I've used the style for a while (many schools taught it in the eighties/early nineties), and there is also a corresponding C style, and I found myself constantly scanning for missing or forgotten begins (or {'s). It is IMHO simply not worth the single line savings.

And bear in mind that I'm originally modula2er, which omits BEGIN for non procedure blocks and thus has indentation close to this style. (actually a popular alternative was to put all statements of the block and the END on the same indentation level)

But in M2 you can rely on it, so while visually the same, which makes it totally different in practice . Same as Python, there the indentation must be right(*), otherwise it won't work, so you can "rely" on it.

Stronger even, my general opinion is that I don't care that much about indentation, as long as begin (and ELSE) is on a single line.

(*) whatever your opinion is on that.

Title: Re: Formatting in FreePascal
Post by: marcov on July 22, 2019, 10:48:09 am

Quote from: rnfpc on July 22, 2019, 10:37:41 am

We often have to use "//do" after 'end's to clarify. This is not needed in pythonic (or whatever name it can be given) format:

It is, since such comments are mostly used when rebalancing (after a codebase or nesting the block deeper). And then you can't rely on indentation being correct.

Title: Re: Formatting in FreePascal
Post by: lucamar on July 22, 2019, 10:48:48 am

I have tested lots of formatting styles (to the point of (re)formatting each function in a unit in a different way) and in the end I settled (returned) to one like PascalDragon's.

For common readability one shouldn't deviate (or not too much) from the style of the rest of the code-base or the agreed upon rules, if working with others, but in the end it's all a question of personal preference.

For example while I find constructions of this type

Code: Pascal [Select][+]

  if something then
  begin
    {... some code ..}
  end
  else
  begin
    {... code some ...}
  end;

cumbersome, others (as can be seen in previous posts) swore by them. But then, I tend to allow for deeper nesting while others prefer shallow nesting and earlier exits (like in the famous "if condition then Exit" vs. "if contrary then begin .." controversy).

A question of to what you're accustomed, I guess :)

What is realy important, IMHO, is that, whatever style you use, it must be used consistently and coherently. Otherwise it produces that jarring impression that makes one reach for the JCF as a frst measure :D

Title: Re: Formatting in FreePascal
Post by: BrunoK on July 22, 2019, 10:56:21 am

Additionally, statements that use then exit, then continue, then break or then goto Somelabel should always be written on 2 lines like :

Code: Pascal [Select][+]

  if not self.Enabled then
    BREAK;
  if not self.Enabled then
    exit;
  if not self.Enabled then
    continue;
  if not self.Enabled then
    goto SomeLabel;
 

Reason : in all these cases there is a real code flow change and enhancing the visual aspect helps find errors.
Having an important instruction just stuck at the end of a line makes code more difficult to read.

AS for then ... end indentation, it is convenient to align the end under the if or the matching begin so moving the cursor up or down will help visually detect the boundaries of block code.

But this is a personal point of view and I have examples of my own patches in Lazarus Trunk that have been changed by the TEAM to something else and has become more difficult to read.

Title: Re: Formatting in FreePascal
Post by: wp on July 22, 2019, 11:57:52 am

It looks too colored initially, and it took some time to get used to it. But now I think that the outlining feature of the IDE is very helpful in finding non-matching "end"s in longer code blocks ("IDE options" > "Editor" > "Display" > "Markup and Matches" > Check "Outline (global)". For the vertical lines to work correctly it is required that block start and end are aligned.

Title: Re: Formatting in FreePascal
Post by: marcov on July 22, 2019, 12:02:48 pm

Quote from: BrunoK on July 22, 2019, 10:56:21 am

Additionally, statements that use then exit, then continue, then break or then goto Somelabel should always be written on 2 lines
(snip)
Reason : in all these cases there is a real code flow change and enhancing the visual aspect helps find errors.
Having an important instruction just stuck at the end of a line makes code more difficult to read.

More importantly, you need them on separate lines to be able to put breakpoints on the THEN constructs. So that is not a matter of taste. At least not with the current debugging support. (but Delphi is no different)

Title: Re: Formatting in FreePascal
Post by: BrunoK on July 22, 2019, 12:31:14 pm

Quote from: marcov on July 22, 2019, 12:02:48 pm

More importantly, you need them on separate lines to be able to put breakpoints on the THEN constructs. So that is not a matter of taste. At least not with the current debugging support. (but Delphi is no different)

The break point is not a good reason because with the following code

Code: Pascal [Select][+]

program Project1;
  procedure Test;
  var
    aDbgInt: integer = 0;
  begin
    repeat
      if aDbgInt = 8 then
        break;  // Exit is the same but continue will break (maybe because is a procedure)
      inc(aDbgInt,2);
    until False;
    aDbgInt := 2;
  end;
begin
  Test;
end.
 

Do an F5 on line 8. It will never stop there, at least with my current version of Lazarus. If it has changed, please tell because I might upgrade to something newer in trunk.

Title: Re: Formatting in FreePascal
Post by: ASerge on July 22, 2019, 12:55:48 pm

I prefer https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide (https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide). All Delphi sources use the same coding style. For example "Never place a begin statement on the same line with any other code".

Title: Re: Formatting in FreePascal
Post by: marcov on July 22, 2019, 01:07:45 pm

More importantly, whatever your own opinions are (and I have a list of critiques there too), the Borland style guide (on which Jedi* is based) are the majority option. Period.

Title: Re: Formatting in FreePascal
Post by: BrunoK on July 22, 2019, 01:37:24 pm

Quote from: ASerge on July 22, 2019, 12:55:48 pm

I prefer https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide (https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide). All Delphi sources use the same coding style. For example "Never place a begin statement on the same line with any other code".

I just read the supplied page.
I adhere to most of it, except for the simple condition with begin on the same line but would certainly not have a fight on that. I just find that correct indentation of the end/until matching the if/repeat/while... position conveys sufficiently the code flow and sparing 1 line allows to have a better on screen readability (more code visible).
One I find pretty difficult to like is the

Code: Pascal [Select][+]

  // CORRECT
  if Condition then
  begin
    DoThis;
  end else
  begin
    DoThat;
  end;
 

I find that the most relevant conditional structure flow information is the else and as such should be the leftmost statement.
I would unscrupulously write it :

Code: Pascal [Select][+]

  if Condition then begin
    DoThis;
  end
  else begin
    DoThat;
  end;
 
 

But at a certain point we fall in personal taste and sure have things to change. I'm never very happy with my variable names ...

Title: Re: Formatting in FreePascal
Post by: Kays on July 22, 2019, 01:40:28 pm

Well, I align my code to the right, :D:

Code: Pascal [Select][+]

                                  with TBarSeries(Result) do
                                                       begin
                                 BarBrush.Color := AColor;
                                   BarPen.Color := AColor;
                            BarWidthStyle := bwPercentMin;
                                if APlotType = ptBars then
                                                     begin
                    AxisIndexX := AChart.LeftAxis.Index;
                  AxisIndexY := AChart.BottomAxis.Index;
                                                       end
                                                      else
                                                     begin
                  AxisIndexX := AChart.BottomAxis.Index;
                    AxisIndexY := AChart.LeftAxis.Index;
                                                      end;
                                                        end;

Title: Re: Formatting in FreePascal
Post by: Thaddy on July 22, 2019, 01:48:28 pm

That is surprisingly readable!!! :D

Title: Re: Formatting in FreePascal
Post by: rnfpc on July 22, 2019, 02:21:22 pm

I find following to be easiest to see blocks:

Code: Pascal [Select][+]

 if Condition then begin
    DoThis;
    end
 else begin
    DoThat;
    end;

Above clearly shows block below 'if' and one below 'else'.

It is obviously what one is used to work with. It will be interesting to find what beginners in this forum prefer.

Title: Re: Formatting in FreePascal
Post by: lucamar on July 22, 2019, 03:52:26 pm

Quote from: Kays on July 22, 2019, 01:40:28 pm

Well, I align my code to the right, :D

Quote from: Thaddy on July 22, 2019, 01:48:28 pm

That is surprisingly readable!!! :D

And surprisingly beautiful :D
Though it might depend quite a lot on where is your right margin :P

Title: Re: Formatting in FreePascal
Post by: rnfpc on July 22, 2019, 04:47:39 pm

A related aspect is indentation/formatting for functions/procedures. Classical is:

Code: Pascal [Select][+]

procedure FFT_2(var Z: array of TComplex);
var
  T1: TComplex;
begin
  T1   := ComplexAdd(Z[0], Z[1]);
  Z[1] := ComplexSub(Z[0], Z[1]);
  Z[0] := T1;
end;
 
procedure FFT_3(var Z: array of TComplex);
var
  T1, M1, M2, S1: TComplex;
begin
  T1   := ComplexAdd(Z[1], Z[2]);
  Z[0] := ComplexAdd(Z[0], T1);
  M1   := ComplexScl(c31, T1);
  M2.Re := c32 * (Z[1].Im - Z[2].Im);
  M2.Im := c32 * (Z[2].Re - Z[1].Re);
  S1   := ComplexAdd(Z[0], M1);
  Z[1] := ComplexAdd(S1, M2);
  Z[2] := ComplexSub(S1, M2);
end;

But following may be clearer:

Code: Pascal [Select][+]

procedure FFT_2(var Z: array of TComplex);
  var
    T1: TComplex;
  begin
    T1   := ComplexAdd(Z[0], Z[1]);
    Z[1] := ComplexSub(Z[0], Z[1]);
    Z[0] := T1;
  end;
 
procedure FFT_3(var Z: array of TComplex);
  var
    T1, M1, M2, S1: TComplex;
  begin
    T1   := ComplexAdd(Z[1], Z[2]);
    Z[0] := ComplexAdd(Z[0], T1);
    M1   := ComplexScl(c31, T1);
    M2.Re := c32 * (Z[1].Im - Z[2].Im);
    M2.Im := c32 * (Z[2].Re - Z[1].Re);
    S1   := ComplexAdd(Z[0], M1);
    Z[1] := ComplexAdd(S1, M2);
    Z[2] := ComplexSub(S1, M2);
  end;

Title: Re: Formatting in FreePascal
Post by: marcov on July 22, 2019, 05:14:28 pm

There's code folding for that.

Title: Re: Formatting in FreePascal
Post by: VTwin on July 22, 2019, 05:25:08 pm

Interesting. I format exactly as PascalDragon does. I find it compact and readable, with each block indented by 2.

My style, as many, predates Python. I find the whitespace formatting in Python a little unsettling, especially if I cut and paste code, I like to find where I am.

For example, I recently cut java code from a pdf of Yaroslavskiy's 2009 "Dual-Pivot Quicksort algorithm" paper. Pasting it produced a single line of code, but it was relatively quick work to get it formatted again (and then converted to Pascal :)).

Title: Re: Formatting in FreePascal
Post by: Thaddy on July 22, 2019, 05:34:20 pm

Quote from: VTwin on July 22, 2019, 05:25:08 pm

I find the whitespace formatting in Python a little unsettling, especially if I cut and paste code, I like to find where I am.

Yes, but in Python the whitespace formatting is part of the language, even its core concept.
In other languages it is a matter of taste. In Pascal you can leave almost any whitespace except separators out and it still compiles:

Code: Pascal [Select][+]

program helloworld;{$mode delphi}uses sysutils;begin writeln('Hello, World');end.

Which is, to stay on subject, an alternative way of formatting.. :D :D O:-)

Title: Re: Formatting in FreePascal
Post by: VTwin on July 22, 2019, 05:49:37 pm

Quote from: Thaddy on July 22, 2019, 05:34:20 pm

Yes, but in Python the whitespace formatting is part of the language, even its core concept.
In other languages it is a matter of taste. In Pascal you can leave almost any whitespace except separators out and it still compiles:
Code: Pascal [Select][+][-]
program helloworld;{$mode delphi}uses sysutils;begin writeln('Hello, World');end.

Which is, to stay on subject, an alternative way of formatting.. :D :D O:-)

Of course I get that, and realize it is because I'm an old fuddy-duddy who did not cut his teeth on Python. I like code that can be parsed despite indentation style (or lack thereof :)). I think I even recall some (lame) code obfuscation techniques using removal of all extra whitespace. :D

Title: Re: Formatting in FreePascal
Post by: PascalDragon on July 23, 2019, 09:17:09 am

Quote from: 440bx on July 22, 2019, 09:21:23 am

Quote from: PascalDragon on July 22, 2019, 09:05:03 am
By the way, when not working on the compiler, this is how I format my code:
Code: Pascal [Select][+][-]
with TBarSeries(Result) do begin
<snip>
if APlotType = ptBars then begin
AxisIndexX := AChart.LeftAxis.Index;
AxisIndexY := AChart.BottomAxis.Index;
end else begin
AxisIndexX := AChart.BottomAxis.Index;
AxisIndexY := AChart.LeftAxis.Index;
end;
end;
The problem with that formatting is that it shows an "if" terminated with two "end"(s). If statements are not terminated with "end"(s).

So? When there are two ends I implicitly know that there's an else inbetween. And with the indentation I can quickly determine where it is. Same with more complex if-constructs.

Quote from: BrunoK on July 22, 2019, 10:25:38 am

One of the most unreadable unit is \rtl\inc\objpas.inc with strange indent and spurious empty lines, others use a 1 character indent, these are awful and spells much doubt on the FPC developer comprehension of its code, I wont cite name ...

Don't forget that most code of the RTL is grown code, more often than not from a time before a general code formatting settled... And doing a reformatting would break up the history when doing a svn blame which is more often than not more important to have than proper formatting.

Title: Re: Formatting in FreePascal
Post by: 440bx on July 23, 2019, 11:48:06 am

Quote from: PascalDragon on July 23, 2019, 09:17:09 am

So? When there are two ends I implicitly know that there's an else inbetween. And with the indentation I can quickly determine where it is. Same with more complex if-constructs.

And the programmer who reads that wrongly formatted code (ifs are not terminated with end), he/she is supposed to "implicitly" know there is an "else" in between ?

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 ?

Programmer's don't read the minds of other programmers, they read code. It's "nice" when the formatting matches the language's constructs, which in this case is, "end" terminates a "begin", not an if or anything else for that matter (correction: an "end" terminates a "case" too.)

That answers your "so ?"

Title: Re: Formatting in FreePascal
Post by: marcov on July 23, 2019, 12:13:42 pm

Quote from: BrunoK on July 22, 2019, 12:31:14 pm

Do an F5 on line 8. It will never stop there, at least with my current version of Lazarus. If it has changed, please tell because I might upgrade to something newer in trunk.

One bug is not a counterexample, and did you disable optimization?

Title: Re: Formatting in FreePascal
Post by: BrunoK on July 23, 2019, 02:14:09 pm

Quote from: marcov on July 23, 2019, 12:13:42 pm

One bug is not a counterexample, and did you disable optimization?

Effectively I always compile -O1 -OoREGVAR that gives very good speed and is compact. This avoids uncertain optimizations at higher levels.

As you write, compiling -O0 does stop there and I just tried -O0 -OoREGVAR that also stops there and produces pretty tight code. From now on, my debug settings will be -O0 -OoREGVAR.

Bug or not bug, I do not know.

Title: Re: Formatting in FreePascal
Post by: marcov on July 23, 2019, 02:15:36 pm

Delphi also has such issues when optimization are on. They are less pronounced, but they are there.

It can't be avoided I guess.

Title: Re: Formatting in FreePascal
Post by: BrunoK on July 23, 2019, 02:27:14 pm

Quote from: marcov on July 23, 2019, 02:15:36 pm

Delphi also has such issues when optimization are on. They are less pronounced, but they are there.

It can't be avoided I guess.

One would have to ask to the king of the debugger.
May be there is not enough code bytes to patch the debug hook when in -O1 and above.

Title: Re: Formatting in FreePascal
Post by: kupferstecher on July 23, 2019, 08:14:01 pm

Some Lazarus features enforce lower case, which I really don't like. E.g. I like to write Procedure and Function with capital P and F. But the automatic creation of the function body with Shift+Ctrl+C not only creates the new one with lower cases, but also changes all other functions/procedures to lower case p and f.

An other thing is the file names. A file name uFancyControl is much more readable than ufancycontrol. But Lazarus always saves them in lower case. If saved twice with capital letters, then at least in the Editor window the name is shown in the specified caseness, while the file name still is in lower case. Not sure if this a bug or a feature...

Title: Re: Formatting in FreePascal
Post by: lucamar on July 23, 2019, 09:36:25 pm

Quote from: kupferstecher on July 23, 2019, 08:14:01 pm

An other thing is the file names. A file name uFancyControl is much more readable than ufancycontrol. But Lazarus always saves them in lower case. If saved twice with capital letters, then at least in the Editor window the name is shown in the specified caseness, while the file name still is in lower case. Not sure if this a bug or a feature...

It's a configurable feature: Tools->Options->Environment->Naming
See attached image.

Title: Re: Formatting in FreePascal
Post by: kupferstecher on July 23, 2019, 10:17:04 pm

@lucamar: Thats great! One annoying thing less~
Thanks!

Title: Re: Formatting in FreePascal
Post by: wp on July 23, 2019, 10:19:48 pm

Quote from: kupferstecher on July 23, 2019, 08:14:01 pm

A file name uFancyControl is much more readable than ufancycontrol. But Lazarus always saves them in lower case. If saved twice with capital letters, then at least in the Editor window the name is shown in the specified caseness, while the file name still is in lower case. Not sure if this a bug or a feature...

An important feature, if you do not only work on Windows.

What would happen without it? Suppose you are on Linux. You create a new form and save the unit as "uForm.pas". The form is used in the mainform; you add the new unit to its uses clause, but write the unit name as "UForm". What will happen? The unit will not be found because a file "UForm.pas" does not exist, the existing file is spelled as "uForm.pas"

With this feature, the unit was automatically saved as lower-case filename, i.e. "uform.pas". When the IDE notices that the file "UForm.pas" does not exist, it automatically searches for the lowercase filename, "uform.pas" - which is found, of course.

Once you fell into this trap, you will never call this feature "annoying" again.

Title: Re: Formatting in FreePascal
Post by: kupferstecher on July 23, 2019, 10:54:29 pm

Hello wp,
I heard before, that its because of the case sensitive operating systems, but couldn't understand, as upper-case-files worked for me on Linux, before. So this is clear now. Still I don't feel very comfortable about beeing limited in the naming just because of that. I think I will change the setting, use upper cases and - earlier or later - fall into the trap~

Title: Re: Formatting in FreePascal
Post by: lucamar on July 24, 2019, 01:43:37 am

Quote from: kupferstecher on July 23, 2019, 10:54:29 pm

I think I will change the setting, use upper cases and - earlier or later - fall into the trap~

THe problem, really is with mixed-case files like your uFancyForm. The compiler/tools work really hard trying to find some file whose name "sounds" as if it might be "it" (IIRC, they look for an exact match, all lowercase, all upercase, initial upper- and rest lower-case, and I don't know what else--it's explained somewhere in the manuals or the wiki); I suspect that's from where all those "case-insensitive" file searching routines in the RTL come.

Even so there may arise the situation where there are two (or more) files with the same name differing only in case, say: "UFancyForm.pas" and "uFancyForm.pas" (and maybe a remnant "ufancyform.pas"). To avoid that, the easiest solution is to stabllish the policy that file names must be all lower (or upper) case and the IDE helps you enforce it ... but only if you want it to!

That's basically all there is to it. :)

Title: Re: Formatting in FreePascal
Post by: lucamar on July 24, 2019, 02:34:21 am

Oop! Forgot about this:

Quote from: kupferstecher on July 23, 2019, 08:14:01 pm

I like to write Procedure and Function with capital P and F. But the automatic creation of the function body with Shift+Ctrl+C not only creates the new one with lower cases, but also changes all other functions/procedures to lower case p and f.

I'm not sure (didn't test) but maybe these settings (see attached image) may help you with this issue. HTH!

Title: Re: Formatting in FreePascal
Post by: howardpc on July 24, 2019, 04:14:21 am

Quote from: kupferstecher on July 23, 2019, 08:14:01 pm

Some Lazarus features enforce lower case, which I really don't like. E.g. I like to write Procedure and Function with capital P and F. But the automatic creation of the function body with Shift+Ctrl+C not only creates the new one with lower cases, but also changes all other functions/procedures to lower case p and f.

You can customise this in IDE Options->Codetools, Words page. Just set the "Keyword policy" radiogroup button to "Lowercase, first letter up".

Title: Re: Formatting in FreePascal
Post by: PascalDragon on July 24, 2019, 09:34:03 am

Quote from: 440bx on July 23, 2019, 11:48:06 am

Quote from: PascalDragon on July 23, 2019, 09:17:09 am
So? When there are two ends I implicitly know that there's an else inbetween. And with the indentation I can quickly determine where it is. Same with more complex if-constructs.
And the programmer who reads that wrongly formatted code (ifs are not terminated with end), he/she is supposed to "implicitly" know there is an "else" in between ?

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.

Quote from: 440bx on July 23, 2019, 11:48:06 am

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][+]

with TBarSeries(Result) do begin
  <snip>
  if APlotType = ptBars then begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end else if APlotType = ptWhatEver then begin
    // whatever
  end else begin
    AxisIndexX := AChart.BottomAxis.Index;
    AxisIndexY := AChart.LeftAxis.Index;
  end;
end;
 

I've used this style for years and as long as I work on my own projects (no matter if they are private ones or code I publish as open source) I'll use this style and nothing can make me change my mind there.

Title: Re: Formatting in FreePascal
Post by: kupferstecher on July 24, 2019, 10:26:34 am

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

Title: Re: Formatting in FreePascal
Post by: 440bx on July 24, 2019, 10:35:50 am

Quote from: PascalDragon on July 24, 2019, 09:34:03 am

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.

Quote from: PascalDragon on July 24, 2019, 09:34:03 am

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][+]

if <condition> then 
   if <anothercondition> then <statement>
else <statement>
 

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.

Quote from: PascalDragon on July 24, 2019, 09:34:03 am

Code: Pascal [Select][+][-]
with TBarSeries(Result) do begin
<snip>
if APlotType = ptBars then begin
AxisIndexX := AChart.LeftAxis.Index;
AxisIndexY := AChart.BottomAxis.Index;
end else if APlotType = ptWhatEver then begin
// whatever
end else begin
AxisIndexX := AChart.BottomAxis.Index;
AxisIndexY := AChart.LeftAxis.Index;
end;
end;

That is wonderful (not!)

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

Title: Re: Formatting in FreePascal
Post by: dbannon on July 25, 2019, 02:23:10 am

Quote from: 440bx on July 24, 2019, 10:35:50 am

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.

Quote from: 440bx on July 24, 2019, 10:35:50 am

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

Title: Re: Formatting in FreePascal
Post by: 440bx on July 25, 2019, 02:59:38 am

Quote from: dbannon on July 25, 2019, 02:23:10 am

Quote from: 440bx on July 24, 2019, 10:35:50 am
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.

Quote from: dbannon on July 25, 2019, 02:23:10 am

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.

Quote from: dbannon on July 25, 2019, 02:23:10 am

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][+]

if <condition> then 
  <statement>
  <statement>
end;

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

Quote from: dbannon on July 25, 2019, 02:23:10 am

It compiles fine

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

Quote from: dbannon on July 25, 2019, 02:23:10 am

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.

Quote from: dbannon on July 25, 2019, 02:23:10 am

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.

Quote from: dbannon on July 25, 2019, 02:23:10 am

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][+]

if <somecondition> then 
begin  // not a singularity point, calculate the derivative at the point
  <statement>
  <statement>
end
else   // a singularity point, inform the reader how it will be handled.
begin
  <statement>
  <statement>
end;
 

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.

Title: Re: Formatting in FreePascal
Post by: dbannon on July 25, 2019, 04:34:23 am

Quote from: 440bx on July 25, 2019, 02:59:38 am

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.

Quote from: 440bx on July 25, 2019, 02:59:38 am

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.

Quote from: 440bx on July 25, 2019, 02:59:38 am

Consider this
Code: Pascal [Select][+][-]
if <somecondition> then
begin // not a singularity point, calculate the derivative at the point
<statement>
<statement>
end
else // a singularity point, inform the reader how it will be handled.
begin
<statement>
<statement>
end;

My version

Code: Pascal [Select][+]

if <somecondition> then begin  // not a singularity point, calculate the derivative at the point
  <statement>
  <statement>
end else   begin // a singularity point, inform the reader how it will be handled.
  <statement>
  <statement>
end;
 

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.

Quote from: 440bx on July 25, 2019, 02:59:38 am

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

Title: Re: Formatting in FreePascal
Post by: 440bx on July 25, 2019, 04:51:10 am

Quote from: dbannon on July 25, 2019, 04:34:23 am

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.

Title: Re: Formatting in FreePascal
Post by: Zoran on July 25, 2019, 09:29:40 am

Quote from: PascalDragon on July 24, 2019, 09:34:03 am

Code: Pascal [Select][+][-]
with TBarSeries(Result) do begin
<snip>
if APlotType = ptBars then begin
AxisIndexX := AChart.LeftAxis.Index;
AxisIndexY := AChart.BottomAxis.Index;
end else if APlotType = ptWhatEver then begin
// whatever
end else begin
AxisIndexX := AChart.BottomAxis.Index;
AxisIndexY := AChart.LeftAxis.Index;
end;
end;

I also have used exactly same formatting for many years.

In my opinion this naturally belongs in one line:

Code: Pascal [Select][+]

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][+]

// Ugly:
if X>0 then
  Y:=X;

Title: Re: Formatting in FreePascal
Post by: PascalDragon on July 25, 2019, 09:47:53 am

Quote from: 440bx on July 24, 2019, 10:35:50 am

Quote from: PascalDragon on July 24, 2019, 09:34:03 am
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][+][-]
if <condition> then
if <anothercondition> then <statement>
else <statement>

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][+]

if <condition> then
  if <anothercondition> then
    <statement>
  else
    <statement>

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

Code: Pascal [Select][+]

if <condition> then begin
  if <anothercondition> then
    <statement>
  else
    <statement>
end;

Title: Re: Formatting in FreePascal
Post by: 440bx on July 25, 2019, 09:55:48 am

Quote from: PascalDragon on July 25, 2019, 09:47:53 am

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.

Title: Re: Formatting in FreePascal
Post by: ASerge on July 25, 2019, 10:37:08 am

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][+]

PROCEDURE SOME(Param IN NUMBER)
IS
  LocalVar DATE;
  LocalN NUMBER;
BEGIN
...
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][+]

procedure Some(Param: Integer); begin
...
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.

Title: Re: Formatting in FreePascal
Post by: 440bx on July 29, 2019, 05:22:37 pm

Quote from: PascalDragon on July 24, 2019, 09:34:03 am

Quote from: 440bx on July 23, 2019, 11:48:06 am
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][+][-]
with TBarSeries(Result) do begin
<snip>
if APlotType = ptBars then begin
AxisIndexX := AChart.LeftAxis.Index;
AxisIndexY := AChart.BottomAxis.Index;
end else if APlotType = ptWhatEver then begin
// whatever
end else begin
AxisIndexX := AChart.BottomAxis.Index;
AxisIndexY := AChart.LeftAxis.Index;
end;
end;

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

Title: Re: Formatting in FreePascal
Post by: Thaddy on July 29, 2019, 05:39:12 pm

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

Title: Re: Formatting in FreePascal
Post by: 440bx on July 29, 2019, 05:54:43 pm

Quote from: Thaddy on July 29, 2019, 05:39:12 pm

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.

Title: Re: Formatting in FreePascal
Post by: Thaddy on July 29, 2019, 06:24:12 pm

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

Title: Re: Formatting in FreePascal
Post by: 440bx on July 30, 2019, 02:05:37 am

Quote from: Thaddy on July 29, 2019, 06:24:12 pm

I repeat

Yes, you are good at repeating.

Title: Re: Formatting in FreePascal
Post by: PascalDragon on July 30, 2019, 09:08:06 am

Quote from: 440bx on July 29, 2019, 05:22:37 pm

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

Those that use that style simply don't care that you think it's “incorrect”. 8-)

Title: Re: Formatting in FreePascal
Post by: 440bx on July 30, 2019, 10:17:09 am

Quote from: PascalDragon on July 30, 2019, 09:08:06 am

Quote from: 440bx on July 29, 2019, 05:22:37 pm
I waited a few days to see if anyone who uses that "style" would notice that the above is _incorrect_.
Those that use that style simply don't care that you think it's “incorrect”. 8-)

Various replies in this thread had already made that quite evident.

I understand that those who use that style don't care whether or not I think it is correct but, they _might_ care that the incorrectly formatted code lead to your introducing a bug. Specifically, the original snippet of code is:

Code: Pascal [Select][+]

with TBarSeries(Result) do
begin
  <snip>
 
  if APlotType = ptBars then
  begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end
  else
  begin
    AxisIndexX := AChart.BottomAxis.Index;
    AxisIndexY := AChart.LeftAxis.Index;
  end;
end;

which you formatted incorrectly like this:

Code: Pascal [Select][+]

with TBarSeries(Result) do begin
  <snip>
  if APlotType = ptBars then begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end else begin
    AxisIndexX := AChart.BottomAxis.Index;
    AxisIndexY := AChart.LeftAxis.Index;
  end;
end;

to drive the point home that formatting is incorrect, I asked this:

Quote from: 440bx on July 23, 2019, 11:48:06 am

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 ?

To which you replied with this

Quote from: PascalDragon on July 30, 2019, 09:08:06 am

Correct:

Code: Pascal [Select][+][-]
with TBarSeries(Result) do begin
<snip>
if APlotType = ptBars then begin
AxisIndexX := AChart.LeftAxis.Index;
AxisIndexY := AChart.BottomAxis.Index;
end else if APlotType = ptWhatEver then begin
// whatever
end else begin
AxisIndexX := AChart.BottomAxis.Index;
AxisIndexY := AChart.LeftAxis.Index;
end;
end;

The problem is, adding an "if" statement should have produced this:

Code: Pascal [Select][+]

with TBarSeries(Result) do
begin
  <snip>
 
  if APlotType = ptBars then
  begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end
  else
  begin
    if APlotType = ptWhatEver then <whatever>;   // added if statement
 
    AxisIndexX := AChart.BottomAxis.Index;
    AxisIndexY := AChart.LeftAxis.Index;
  end;
end;

instead, your adding the "if" statement, produced this (formatted correctly to make the error visible):

Code: Pascal [Select][+]

with TBarSeries(Result) do begin
  <snip>
  if APlotType = ptBars then
  begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end
  else
    if APlotType = ptWhatEver then
    begin
      // whatever
    end
    else
    begin
       AxisIndexX := AChart.BottomAxis.Index;
       AxisIndexY := AChart.LeftAxis.Index;
    end;
end;
 

Now the conditions that control when the statements

Code: Pascal [Select][+]

       AxisIndexX := AChart.BottomAxis.Index;
       AxisIndexY := AChart.LeftAxis.Index;

get executed are no longer what they should be.

However, I have no doubt that's what you intended. Changing the conditions that control the execution of the statements is included in the formatting "style" too.

Title: Re: Formatting in FreePascal
Post by: kupferstecher on July 30, 2019, 01:08:48 pm

~~Just compile it. Its the same.~~

Edit: And that shows the beauty of that formatting, no nesting. Just a simple if..elseif..else..end structure.

Title: Re: Formatting in FreePascal
Post by: 440bx on July 30, 2019, 02:11:52 pm

Quote from: kupferstecher on July 30, 2019, 01:08:48 pm

Its the same.

No, not the same. The statements

Code: Pascal [Select][+]

 AxisIndexX := AChart.BottomAxis.Index;
 AxisIndexY := AChart.LeftAxis.Index;

are no longer executed based on the same conditions.

Quote from: kupferstecher on July 30, 2019, 01:08:48 pm

Edit: And that shows the beauty of that formatting, no nesting. Just a simple if..elseif..else..end structure.

When introducing bugs in code is considered "beautiful" that formatting will be "beautiful" too.

Title: Re: Formatting in FreePascal
Post by: kupferstecher on July 30, 2019, 03:22:54 pm

Yes, you're right, it's not the same. But your example is useless. Of course you can add a new level of ifs, but thats not a matter of formatting. This was about inserting an "else if" and than the code is correct.

Title: Re: Formatting in FreePascal
Post by: RAW on July 30, 2019, 04:00:42 pm

I like this ...

Code: Pascal [Select][+]

With TBarSeries(Result)
Do
 Begin
   <snip>
 
   If APlotType = ptBars
   Then
    Begin
      AxisIndexX:= AChart.LeftAxis.Index;
      AxisIndexY:= AChart.BottomAxis.Index;
    End
   Else
    Begin
      If APlotType = ptWhatEver
      Then <whatever>;
 
      AxisIndexX:= AChart.BottomAxis.Index;
      AxisIndexY:= AChart.LeftAxis.Index;
    End;
 End;

Yeah, I couldn't resist ... :D

Title: Re: Formatting in FreePascal
Post by: 440bx on July 30, 2019, 04:01:53 pm

Quote from: kupferstecher on July 30, 2019, 03:22:54 pm

Yes, you're right, it's not the same.

We're making progress. That's good.

Quote from: kupferstecher on July 30, 2019, 03:22:54 pm

But your example is useless.

It wasn't an example. It was a request that an "if" statement be added.

Quote from: kupferstecher on July 30, 2019, 03:22:54 pm

Of course you can add a new level of ifs, but thats not a matter of formatting. This was about inserting an "else if" and than the code is correct.

The formatting is the main cause why when that "if" was added a bug was introduced.

When the formatting is correct, it's rather unlikely for a programmer to make that mistake.

ETA:

Quote from: RAW on July 30, 2019, 04:00:42 pm

Yeah, I couldn't resist ... :D

That's better than upside-down :D

Title: Re: Formatting in FreePascal
Post by: PascalDragon on July 31, 2019, 09:46:11 am

Quote from: 440bx on July 30, 2019, 10:17:09 am

Now the conditions that control when the statements
Code: Pascal [Select][+][-]
AxisIndexX := AChart.BottomAxis.Index;
AxisIndexY := AChart.LeftAxis.Index;
get executed are no longer what they should be.

However, I have no doubt that's what you intended. Changing the conditions that control the execution of the statements is included in the formatting "style" too.

You are aware that I merely added the if-statement to illustrate the formatting and did not care at all about the functionality of the code?

Title: Re: Formatting in FreePascal
Post by: wp on July 31, 2019, 10:10:09 am

All the following variants are "correct" for me:

Code: Pascal [Select][+]

with TBarSeries(Result) do begin
  if APlotType = ptBars then begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end else
  if APlotType = ptWhatEver then begin
    AxisIndexX := something;
    AxisIndexY := something_else;
  end else begin
    AxisIndexX := AChart.BottomAxis.Index;
    AxisIndexY := AChart.LeftAxis.Index;
  end;
end;
...
with TBarSeries(Result) do 
begin
  if APlotType = ptBars then
  begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end 
  else
  if APlotType = ptWhatEver then
  begin
    AxisIndexX := something;
    AxisIndexY := something_else;
  end 
  else 
  begin
    AxisIndexX := AChart.BottomAxis.Index;
    AxisIndexY := AChart.LeftAxis.Index;
  end;
end;
...
with TBarSeries(Result) do begin
  if APlotType = ptBars then
  begin
    AxisIndexX := AChart.LeftAxis.Index;
    AxisIndexY := AChart.BottomAxis.Index;
  end
  else
    if APlotType = ptWhatEver then
    begin
      AxisIndexX := something;
      AxisIndexY := something_else;
    end
    else
    begin
       AxisIndexX := AChart.BottomAxis.Index;
       AxisIndexY := AChart.LeftAxis.Index;
    end;
end;

Personally I prefer the first one because it requires the least lines on the screen. What I absolutely do not like is missing indentation and I put its importance far above the question whether the "begin" after an "if" should be on the same line or not:

Code: Pascal [Select][+]

// DO NOT DO THIS!
with TBarSeries(Result) do begin
if APlotType = ptBars then begin
AxisIndexX := AChart.LeftAxis.Index;
AxisIndexY := AChart.BottomAxis.Index;
end else
if APlotType = ptWhatEver then begin
AxisIndexX := something;
AxisIndexY := something_else;
end else begin
AxisIndexX := AChart.BottomAxis.Index;
AxisIndexY := AChart.LeftAxis.Index;
end;
end;

Title: Re: Formatting in FreePascal
Post by: howardpc on July 31, 2019, 10:31:11 am

Personally, I much prefer this construction, which I find far easier to read and comprehend at a glance.
I believe in some cases it may also be a tad faster, but for me that is unimportant compared to readability and ease of maintenance.

Code: Pascal [Select][+]

  with TBarSeries(Result) do
    case APlotType of
      ptBars: 
        begin
          AxisIndexX := AChart.LeftAxis.Index;
          AxisIndexY := AChart.BottomAxis.Index;
        end;
      ptWhatever:
        begin
          AxisIndexX := something;
          AxisIndexY := something_else;
        end;
      else
          AxisIndexX := AChart.BottomAxis.Index;
          AxisIndexY := AChart.LeftAxis.Index;
    end;
  end;

Title: Re: Formatting in FreePascal
Post by: Thaddy on July 31, 2019, 10:44:21 am

I totally agree with you. Except the indentation of the else clause and that bug it contains :P (no begin end)

IMHO you should not use whitespace at all and make it readable with ptop afterwards... O:-)

Title: Re: Formatting in FreePascal
Post by: fred on July 31, 2019, 11:18:49 am

@howardpc: Line 17 end at the same level as with but no begin 8)

Title: Re: Formatting in FreePascal
Post by: 440bx on July 31, 2019, 11:24:21 am

Quote from: PascalDragon on July 31, 2019, 09:46:11 am

You are aware that I merely added the if-statement to illustrate the formatting and did not care at all about the functionality of the code?

Of course, why would anyone care about the functionality, it's so much more important to save a line or two.

Title: Re: Formatting in FreePascal
Post by: ASerge on July 31, 2019, 12:20:35 pm

Quote from: fred on July 31, 2019, 11:18:49 am

@howardpc: Line 17 end at the same level as with but no begin 8)

Yes, yes when "begin" is on a separate line, the probability of such an error is less, because only "case" and "begin" end on the "end". In other cases, this is a mistake. And if you write "begin" anywhere - you have to carefully read each complex structure.

Title: Re: Formatting in FreePascal
Post by: howardpc on July 31, 2019, 01:17:48 pm

Quote from: Thaddy on July 31, 2019, 10:44:21 am

I totally agree with you. Except the indentation of the else clause and that bug it contains :P (no begin end)

An else clause within a case construct does not require a begin/end since the "else" and the case's "end" are sufficient.
You can add one if you feel the need to write one and make each section of the case construct symmetrical.
But that is a matter of aesthetics, not of correct or incorrect syntax.
I think Pascal is verbose enough. No need to add unnecessary begin/end pairs.
Describing this as a bug is wrong.
The compiler developers don't consider it a bug.
"with" and "case" are both terminated by "end" correctly.
Neither needs a corresponding "begin".

Not every "end" has a matching "begin".

Title: Re: Formatting in FreePascal
Post by: Zoran on July 31, 2019, 01:25:29 pm

Quote from: howardpc on July 31, 2019, 01:17:48 pm

"with" and "case" are both terminated by "end" correctly.
Neither needs a corresponding "begin".

Not every "end" has a matching "begin".

You are right for "case" statement, but not for "with", so there is one "end" more than there should be in your code. See:

Code: Pascal [Select][+]

  with TBarSeries(Result) do
    case APlotType of
      ptBars: 
        begin
          AxisIndexX := AChart.LeftAxis.Index;
          AxisIndexY := AChart.BottomAxis.Index;
        end;
      ptWhatever:
        begin
          AxisIndexX := something;
          AxisIndexY := something_else;
        end;
      else
          AxisIndexX := AChart.BottomAxis.Index;
          AxisIndexY := AChart.LeftAxis.Index;
    end; // this ends case
  end; // what does this one do here?

Will not compile.

Title: Re: Formatting in FreePascal
Post by: 440bx on July 31, 2019, 01:28:41 pm

Quote from: fred on July 31, 2019, 11:18:49 am

@howardpc: Line 17 end at the same level as with but no begin 8)

And that illustrates another one of the problems with that incorrect formatting. The programmers that use it get used to seeing "end" associated with keywords they don't associate with, which makes it much easier to omit a necessary "begin".

At least in those cases, the compiler will emit an error but, that isn't always the case as one of the above examples demonstrates.

Title: Re: Formatting in FreePascal
Post by: howardpc on July 31, 2019, 01:35:07 pm

Quote from: Zoran on July 31, 2019, 01:25:29 pm

Quote from: howardpc on July 31, 2019, 01:17:48 pm
"with" and "case" are both terminated by "end" correctly.
Neither needs a corresponding "begin".

Not every "end" has a matching "begin".

You are right for "case" statement, but not for "with", so there is one "end" more than there should be in your code. See:

You are right - "with" does require a begin/end. Apologies for posting a misleading statement and uncompilable code.
What I should have posted was the following:

Code: Pascal [Select][+]

with TBarSeries(Result) do
  case APlotType of
    ptBars:
      begin
        AxisIndexX := AChart.LeftAxis.Index;
        AxisIndexY := AChart.BottomAxis.Index;
      end;
    ptWhatever:
      begin
        AxisIndexX := something;
        AxisIndexY := something_else;
      end;
    else
        AxisIndexX := AChart.BottomAxis.Index;
        AxisIndexY := AChart.LeftAxis.Index;
  end;

Although this will never satisfy indentation purists, I find it draws attention in a helpful way to the most important parts of the code (the actions that should follow from each case selector) while relegating the boilerplate stuff (begins and ends) to a less significant position in the construct.

Title: Re: Formatting in FreePascal
Post by: 440bx on July 31, 2019, 03:30:18 pm

Quote from: howardpc on July 31, 2019, 01:35:07 pm

What I should have posted was the following:
Code: Pascal [Select][+][-]
with TBarSeries(Result) do
case APlotType of
ptBars:
begin
AxisIndexX := AChart.LeftAxis.Index;
AxisIndexY := AChart.BottomAxis.Index;
end;
ptWhatever:
begin
AxisIndexX := something;
AxisIndexY := something_else;
end;
else
AxisIndexX := AChart.BottomAxis.Index;
AxisIndexY := AChart.LeftAxis.Index;
end;
Although this will never satisfy indentation purists

Change "indentation" to "language" and I can agree with that statement.

Quote from: howardpc on July 31, 2019, 01:35:07 pm

I find it draws attention in a helpful way to the most important parts of the code (the actions that should follow from each case selector) while relegating the boilerplate stuff (begins and ends) to a less significant position in the construct.

That's reasonable.

I'd format it similarly:

Code: Pascal [Select][+]

with TBarSeries(Result) do
case APlotType of
  ptBars:
  begin
   AxisIndexX := AChart.LeftAxis.Index;
   AxisIndexY := AChart.BottomAxis.Index;
  end;
 
  ptWhatever:
  begin
    AxisIndexX := something;
    AxisIndexY := something_else;
  end;
 
else
  AxisIndexX := AChart.BottomAxis.Index;
  AxisIndexY := AChart.LeftAxis.Index;
end;

The above formatting for the following reasons: "case"/"else"/"end" aligned because they are a single Pascal construct. "case" aligned with "with" because the "case" belongs to the "with". "begin"/end" aligned with the conditions because that's what they are associated with (owned by.)

if Delphi supported "otherwise" in "case" statements, I would use "otherwise" to make it visually noticeable that the statements under it are not associated with an "if".

One thing I find particularly interesting is that, probably NONE of the programmers that use "begin" on the same line as an "else" (or something else) code something like this:

Code: Pascal [Select][+]

procedure MyProc; begin
end;

which indicates that their formatting choice is not particularly consistent and lacks a solid foundation. Putting the "begin" on the same line as "procedure" would after all, save one line, just as it does in other constructions.

Title: Re: Formatting in FreePascal
Post by: PascalDragon on August 01, 2019, 09:21:31 am

Quote from: 440bx on July 31, 2019, 11:24:21 am

Quote from: PascalDragon on July 31, 2019, 09:46:11 am
You are aware that I merely added the if-statement to illustrate the formatting and did not care at all about the functionality of the code?
Of course, why would anyone care about the functionality, it's so much more important to save a line or two.

I merely replied with what it would look like with an additional if-condition. Adding an additional condition to that code of course changes what the code does. But that was not the point, the point was to show how I format such code.