Omitting semicolon on last statement

[Xenno]

Hello everyone,

For years I guess I've been doing wrong. But please your insight about the subject. I read that placing semicolon on a statement before end produce a Null statement.

• Is it encouraged to omit semicolon on last statement? Any specific guides or official documentation?
• Are there any practical impacts? Compiler, Code Optimazation, Debugger?
• If omitting it is the preferred clean way, is there a compiler directive or hint that can notify us when an unnecessary semicolon is found?

I look forward for your thoughts and experiences. TIA

[440bx]

the semicolon in Pascal is a statement separator and the keyword "end" is not a statement, therefore, a semicolon should not be present before an "end".

The presence of a semicolon before the "end" causes an empty statement which as far as the compiler is concerned means nothing, thereby in turn generates nothing.

as far as your questions:

1. there is no guideline encouraging or discouraging the presence of empty statements but, generally speaking, superfluous semicolons should be avoided particularly when they may be visually "offensive", e.g, you can have a long list of semicolons following an "end" as in "end;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;" (that last sequence compiles without errors because each semicolon indicates an empty statement.)

2. The only practical impact is that the semicolon takes space in the source code and, as such must be scanned, the parser will interpret as an empty statement which means it will simply be ignored/discarded.

3. No, there is no directive to instruct the compiler to flag superfluous semicolons.  At least not at this time.

Thoughts ? ... if placing a semicolon somewhere doesn't look good, just don't put one, if one is required the compiler will complain and then you can add it knowing it is required.  Other than that, don't sweat the semicolons.

Lastly, empty statements (semicolons) can be useful in a few occasions, here is an example:

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

1. if <some error condition> then
2. {$if FORCE_ERROR_CONDITION} ; {$endif}
3. begin
4.  <some statements>
5. end;
6.  

defining {$define FORCE_ERROR_CONDITION} forces the <some statements> part of the "if" to be executed because the <some error condition> ends up controlling the empty statement instead of the statements in <some statements>.  This allows you to test that <some statements> do what you intended without having to find a case that causes the <some error condition> to be triggered.  I used that extensively for testing my code.  Saves a lot of time in not having to contrive cases to trigger errors.

HTH.

[Zvoni]

I'm of two minds regarding this:
1) Everything 440bx wrote
2) To me it looks "cleaner" if a semicolon comes after each statement
BUT (and that's a big one): In an If-Then-Else (!!) before the Else no semicolon is allowed at all!
I've run into that one often enough to curse it into next week.

No idea if there are other "scenarios" where a semicolon is not allowed

[Xenno]

Thank you, @440bx and @Zvoni.

Since there is no objective advantage or disadvantage to omitting the semicolon on the last statement, I won't worry too much about changing my habits.

I noticed that while the Delphi Docwiki explicitly mentions that the semicolon is a separator and can be omitted before an end, I have yet to find an instance in the actual Delphi source code where they actually omit it. Even though the Pascal Wikipedia page explains the logic behind the "separator" rule, it seems the industry standard is to include it anyway for consistency.

I appreciate the clarification!

https://docwiki.embarcadero.com/RADStudio/Athens/en/Delphi_Statements
https://en.wikipedia.org/wiki/Pascal_(programming_language)

[n7800]

Another reason to always add a semicolon is to simplify patches (for example, for Git). If you add a statement to the end of a function (or inside any begin..end), you'll first need to add a semicolon for the previous statement, meaning the patch will be two line longer:

Code: Diff  [Select][+][-]

1.  function test;
2.  begin
3. -  writeln(1)
4. +  writeln(1);
5. +  writeln(2);
6.  end;

Code: Diff  [Select][+][-]

1.  function test;
2.  begin
3.    writeln(1);
4. +  writeln(2);
5.  end;

This isn't a big deal, but extra lines in a patch always make it harder to read (especially if there are many such instances). You have to visually compare the differences between long lines before you can spot the barely noticeable ";".

[Xenno]

@n7800
That is an excellent point! Your Git example perfectly demonstrates why omitting the semicolon can be problematic. I believe it generally matters in Refactoring processes even without version control. Thank you!

[440bx]

It should be noted that Pascal's use of the semicolon as a separator leads to situations that have a tendency to confuse programmers and, for this reason, current Pascal compilers have a "customized" set of rules as to when a semicolon is acceptable.  For instance, consider the following code:

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

1.  
2. type
3.   TRECA = record
4.     AField  : integer   { note the absence of a semicolon }
5.   end;
6.  
7.   TRECB = record
8.     AField  : integer;  { incorrect in standard Pascal    }
9.   end;
10.  

In standard Pascal, the first type definition is correct, there is no semicolon after "integer" as it should be.  The second definition would be rejected by a strictly abiding compiler because a semicolon after "integer" is unacceptable, there cannot be a semicolon before the "end" because in that case it does _not_ represent an empty statement (there is no statement in a record type definition.)

The point is that, modern Pascal compilers have a set of rules about the semicolon that is based more on human intuition than strict language definition.  In the definition of TRECB, the semicolon is acting as a terminator instead of a separator (since it isn't separating one field definition from another and "end" isn't a field definition.)

FPC compiles either definition but, a strictly adhering standard Pascal compiler would reject the second definition because the semicolon after "integer" would be considered unacceptable.

All of the above, just FYI.

As I stated in my first post, if a semicolon looks good someplace then put it there which is what leads to the second definition and modern Pascal compilers will usually all tolerate the syntactically misplaced semicolon since, its presence doesn't make any difference whatsoever.

[MarkMLl]

I'm of two minds regarding this:
1) Everything 440bx wrote
2) To me it looks "cleaner" if a semicolon comes after each statement
BUT (and that's a big one): In an If-Then-Else (!!) before the Else no semicolon is allowed at all!
I've run into that one often enough to curse it into next week.

No idea if there are other "scenarios" where a semicolon is not allowed

At least some versions of Turbo Pascal got unhappy if there was a ; before until, and I generally agree with the rest of your points.

I have to say that by now Pascal is a mess: the original language is as designed by Wirth but there are a whole lot of extensions (try-finally as an example) where end is mandatory.

My personal preference is to omit ; where it is not needed, and to use  otherwise  on case statements to reduce the possibility of ambiguity caused by the dangling-else issue (for which the 1963 fix was ignored by Wirth).

MarkMLl

[440bx]

use  otherwise  on case statements to reduce the possibility of ambiguity caused by the dangling-else issue

Actually, the problem of having "else" in a case statement isn't about a dangling-else issue (as in which if statement owns the "else"), it's about which of "case" or "if" owns the "else".

For instance, in the following code:

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

1. var
2.   a: integer = 1;
3.  
4. begin
5.   case a of
6.     1, 2: if a = 2 then
7.             writeln(2);
8.           else               { belongs to the "case" because of the ";" after (2) }
9.             writeln(1);
10.   end;            
11. end.
12.  

without the semicolon after the "writeln(2)" the compiler could not decide whether the "else" belongs to the "case" or the "if" (there is no rule in Pascal resolving that ambiguity, a dangling else not between two if statements but between an if statement and a case statement), for this reason, "otherwise" should always be used in "case" statements (since that's not shared between "if" and "case", it always belongs to the "case" statement.)

What's really bad in the above statement is that the semicolon is acting as a statement _terminator_ instead of separator.  Allowing "else" in a case statement introduced a flaw in the Pascal grammar.

[Xenno]

@440bx
Noted. Thank you very much for detail explanation.

@MarkMLl
This is great to know that someone actually prefers to omit unneeded semicolons.

This thread was triggered about the phrase null statement or empty statement for placing a semicolon before end. It just sounds something but then apparently it is absolutely harmless.

Somehow I agree to omit it for preventing compiler creates (redundant) null statements. On the other hand common practices show it causes glitches such in version control or refactoring.

[440bx]

@440bx
Noted. Thank you very much for detail explanation.

You're welcome.

Somehow I agree to omit it for preventing compiler creates (redundant) null statements.

The compiler does not create null statements.  Superfluous semicolons have no effect whatsoever on the resulting executable.

[Paolo]

just a very-very-very minor note

I am refactoring my code to minimise ';' usage, anyway in case of code like this

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

1.       ...
2.       end
3.     end
4.   end
5.   ...
6.  

an then you add a statement in the middle of end sequences

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

1.      end
2.     end
3.     newcode;
4.   end
5.  

you have to remember to apply the ';' on previous row

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

1.      end
2.     end; <-- here
3.     newcode;
4.   end
5.  

..and I usually forgot to do this! but that is in any case catched by the compiler

having ';' all around avoid this typing error situation.

[Xenno]

@Paolo
Thank you. I will remember that. Yes, sometime I experience that, too.
I am little curious, could you tell the reason of why you want to "minimise ';' usage"?

[Paolo]

I am not a professional programmer, many of my programs are created 'at fly' on the basis of specific needs. Only later, I have time to clean and make modular the code, at this stage I try to follow the pascal syntax as much as possible. So, non specific motivation in saving ';'. On larger project, built over the years, I like to have code compact as much as possible for readable reasons.

[Xenno]

@Paolo
I get a good lesson from you that I should consider to take a look at my code and tidy it up or better refactor it in order to have maintainable code. Thank you.