Do you number your begin/end blocks?

[silvercoder70]

I will typically do something similar to what Bart said in reply #2.

The other thing I would mention is that _try_ to reduce number of levels with something like (see below). I know it was/is only an example but if I can do something and exit...

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

1. begin
2.   if not this then Exit;
3.  
4.   {this is true here...}
5.   if not otherthing then
6.   begin
7.     ...
8.     Exit;
9.   end;
10.  
11.   {this and otherthing are true...}
12.   If anotherthing then
13.   begin
14.       ...
15.   end;
16. end;
17.  

     

[wp]

FPC routines somethis follow strange indentation rules (in my opinion), and it is hard to identify the blocks. The "outline" feature here helps a lot to see that an "end" is missing in the FPImage code shown in the screenshot (of course, I removed the "end" for this demo, the original code is correct): The final "end" of a procedure always must be red (in the default coloring scheme) - here it is orange, and this indicates that an "end" is missing somewhere, without having to do a test compilation.

[Martin_fr]

Further more, if you have folding enabled, then you can set a different color for the fold-gutter-line of the nearest enclosing fold. (going over any nested folds, if the caret is outside those nested)

[TBMan]

use the Ouline option in IDE Options: https://wiki.lazarus.freepascal.org/Lazarus_IDE_Tools#Outline

I'll try this for a while and see if I can adapt to it.

[Warfley]

I will typically do something similar to what Bart said in reply #2.

The other thing I would mention is that _try_ to reduce number of levels with something like (see below). I know it was/is only an example but if I can do something and exit...

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

1. begin
2.   if not this then Exit;
3.  
4.   {this is true here...}
5.   if not otherthing then
6.   begin
7.     ...
8.     Exit;
9.   end;
10.  
11.   {this and otherthing are true...}
12.   If anotherthing then
13.   begin
14.       ...
15.   end;
16. end;
17.  

   

But why not use an assertion for this?

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

1. begin
2.   if not this then Exit;
3.  
4.   {this is true here...}
5.   if not otherthing then
6.   begin
7.     ...
8.     Exit;
9.   end;
10.   Assert(otherthing, 'Guard should have captured if otherthing is false');
11.  
12.   If anotherthing then
13.   begin
14.       ...
15.   end;
16. end;
17.  

First it serves the same documentation purpse, as when reading the code you immediately see that from this point onwards otherthing should be true, with a textual explanation why this is the case. Additionally, when compiling in debug mode with assertions enabled, when you test your code and you reach that point it checks and if it fails (e.g. you changed your guard and forgot an exit), it will cause an error that you find. While when you compile in release mode the assertions will be thrown out, resulting in no extra code being generated.

I think people are using assertions way to rarely in pascal. In other languages I see this much more commonly used

[440bx]

One construct I use very often is either:

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

1. for i := i to i do  { scope - not a loop }
2. begin
3.   if somecondition then
4.   begin
5.     <statements>
6.     break;
7.   end;
8.  
9.   if othercondition then
10.   begin
11.     <statements>
12.     break
13.   end;
14. end; { scope }
15.  
16. <more statements here>
17.  
18.  

or the same thing using a "repeat <conditions with break> until TRUE;"

That way you can have an "artificial case" statement with conditions that are not all dependent on a constant or a single variable.

It's extremely easy to understand and add conditions in the right place and there is no ifs inside ifs inside ifs which can easily obfuscate the set of conditions that lead to a specific statement to be executed.  No nesting keeps the flow linear (which is the ideal.)

using a "repeat ... until" is often better because that avoids having the compiler sometimes emit a warning about the variable "i" not having been initialized.  Small potato.

[Zoran]

using a "repeat ... until" is often better because that avoids having the compiler sometimes emit a warning about the variable "i" not having been initialized.  Small potato.

You could avoid the warning with "for I := 0 to 0", but "repeat ... until True" is still preferred, as you don't need to declare the unnecessary variable I (and, although I haven't checked, I would also expect a better optimisation without I).

[440bx]

the one thing I like about using a "for" instead of a "repeat" is that the "for" makes it clear upfront that the statements will only be executed once whereas with a "repeat" the programmer has to visually locate the "until" to see that the condition is "until TRUE" to determine the statements will only be executed once.

That's the part about the "for" I like and I sometimes use it when the "until" isn't immediately visible (say about 30 lines or more below the "repeat".)

As far as performance, the "repeat" takes less code but, since it only gets executed once, the difference is just a handful of clock cycles,  not worth sweating.