Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Pesky Semicolons

Status
Not open for further replies.

PinkeyNBrain

IS-IT--Management
Dec 12, 2006
279
US
In a previous post the excessive usage of semicolons was brought into light. One poster preferred the minimalist approach, another (myself) added a few extra here and there. This thread is opened to receive input from anyone who who has an opinion, or, are at that point in their day when they're about to start keyboard diving and need a break.

Please note that before I continue, I wish to establish that this posting is intended to be an open discussion. In absolutely no way is this intended to be a slam, dig or otherwise ridiculing of any of the many talented contributors to this forum.

To begin - The two basic camps that I'm aware of at this point are:
1) Minimal usage
a) If not needed, a semicolon should not be used.
b) You'll never see any book example, tutorial, or other using them.
c) Can potentially cause logic errors.

2) Liberal usage
a) Programmers choice / coding style.

First review -
After reading some comments from the minimalist camp, I did cross examine how my code fell. Thinking of logic errors, I came up with the following example:
Code:
#!/usr/bin/perl -w
use strict ;
$main::avar = $main::bvar = 0 ;
# logic error inducing semicolon on next line
# We're really wanting avar = 1 + ++bvar ;
$main::avar = 1 ;
 + ++$main::bvar  ;
OK - The code does nothing save for illustrating the point
that neither the -w switch nor the usage of strict will find anything in error here. Should this basic construct be intermingled within a much larger chunk of code, it could easily be lost.

On the other hand, while I can't say for certain that I've never made the above mistake, I can say that I've made the following mistake many times:
Code:
if (xx) {
   # semicolon intentionally left off the next line
   if (yy) { zz }
else {
   ww
}
  <insert huge chunk of code here >
  <that has an extra { or missing }>
}
By habit, I use indentation to trace through logic. As such, I'll overlook the fact that 'ww' will never be executed if 'xx' is false. Again, neither -w or strict will find an error. However in my defense, by my usage of ;'s after 'if' statements (e.g. if (yy) { zz };), the missing } would have been pointed out by the parser.

<insert idealist here who states: "For every if-then, there should be an else; even if it isn't used">
..... Hey - we're just working on semicolons here. Start your own thread.

Going back to the fact that you'll never see additional ;'s used in publicated (sp?) material, I offer the following 3 sources:
#1#
Camel book 1st ed, Mar 1992 Ch7-Other Oddments / Common Goofs for Novices:
* Forgetting the trailing semicolon.
Obviously you've done too much awk hacking recently. Every statement in Perl is terminated by a semicolon.
#2#
Camel book 2nd ed, Sep 1996 Ch2-The Gory Details:
Here there is a separation between simple statements and compound statements (i.e. BLOCKs). For simple statements:
A simple statement is an expression evaluated for its side effects. Every simple statement must end in a semicolon, unless it is the final statement in a block. In this case, the semicolon is optional (but strongly encouraged in any multiline block, since you may eventually add another line)

Under the description of compound statements, there is no reference toward promoting nor condemning the usage of ;'s.

This next statement is conjecture on my part but, I feel that the trend toward not using ;'s when not needed would be Mr.Tom Christiansen's influence. I've heard him speak before and believe he is a very intelligent individual, he can also be a horses rump.

#3#
And finally, please reference:
In particular the "Comments and statements" section.

To wrap up: I say that if an extra semicolon here or there helps you complete your program, use them. If they cause you problems don't use them. In the manor that I use them, you can't tell me that they shouldn't be there. Its the programmers choice.
 
I always terminate the statement with a semicolon, even when it's the last one in a block. It saves me screwing up when I come back and put in a print statement for debugging, or add a new statement in the block. I don't find the extra typing effort too much of an issue, and with my 160GB hard drive I can afford to blow a few extra bytes of disk space.

I quite often add redundant parentheses to compound conditions too. It's not that I don't trust the compiler to get the precedence right, it just makes it easier for me to read, especially several months later.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object::perlDesignPatterns)[/small]
 
Found a good #4#

Toward the bottom of page one can find a reference to not wasting time typing line terminators when the language should be able to figure it out. Wasting time?? As a test, I found that I can casually type about 25 semicolons in 10 seconds. In scanning over one project directory, I found 22 *.pl files totaling well over 16K lines of code with 7846 semicolons. Doing the math I spent under an hour typing all those semicolons. Note that it took me 3+ months to write the code.

Had I not typed all those extra ;'s, how much would I save? 30 minutes? If your IT department is so pinched for time that 30 minutes over the course of several months is important, you've got bigger things to worry about.

And in league with Steve, I will also commonly do things like:
Code:
open(FH, $file) ;
# coda, coda, coda
close(FH);
when the ()'s are not needed.
 
Perl is a little lose with some of the syntax requirements, its part of the "perl tries to do what is right" philosophy I guess. The previously mentioned semi-colons were at the end of blocks, as in:

Code:
if {
   ...
};
else {
   ...
};


Those semi-colons should not be there, or it can be said, that don't need to be there. In that specific case they do no harm, unless, there is a missing semi-colon else where in the code and perl tries to use the extra semi-colon as the terminator for the missing semi-colon. In some cases it might actually allow the code to run but appear to not do what the writer of the code expects. So the code runs, appears to look written correctly, perl returns no errors or warnings, yet the code produces bizarre results. That is my concern for putting in semi-colons where they should not be.



------------------------------------------
- Kevin, perl coder unexceptional! [wiggle]
 
Sorry, I thought you were objecting to redundant semicolons at the end of blocks inside the block. It never occurred to me to put them outside the }...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object::perlDesignPatterns)[/small]
 
In a futile effort to conserve what little brain power I have, I try to minimise what I have to remember.

You never need a ; after a {} in perl (or in any other language I know with similar syntax), so I never put one there.

You sometimes don't need a ; after a regular statement in perl, but it does no harm to have one anyway. Since I consider it more trouble to remember the circumstances under which a ; is unnecessary than it is to type the (possibly superfluous) extra keystroke, I prefer to type the ; regardless.

There's also the issue that if you also have to write in languages other than perl which have broadly similar syntax (which is a lot of languages), they have different levels of permissiveness on when you can omit the ;. Since it's all I can do to remember whether a given language uses [tt]elsif[/tt] or [tt]elseif[/tt] to tack one conditional onto another, I try to keep my coding practices as generic as possible.


-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
I think I've figured out the source of my abusive semicolon usage. The first languages I programed in were Pascal and PL/C. (still have my first "hello word" program ... sniff)

Anyway - if you're not familiar, these languages were very liberal on their usage of ;'s. Pascal, for one, used "BEGIN .. END" blocks (analogous to {} blocks). Pascal required a ; after the 'END' keyword even though it was grossly obvious that END meant END. I haven't programed in those languages since the late 80's when I started switching to awk and eventually perl.

So - for what it's worth, I'll try to limit my ; usage. But if one sneaks in there, please bear with me.
 
Where's Miller when we need him :)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[noevil]
Travis - Those who say it cannot be done are usually interrupted by someone else doing it; Give the wrong symptoms, get the wrong solutions;
 
ChrisHunt,

Unfortunatley its another example of having to learn perls rules on a case by case basis. There is a requirement for a semi-colon after a block of code. When you use a function like "do" or "eval" (maybe others too) as a block expression you have to put a terminating semi-colon.

Example:

Code:
eval { expression };

do {
   expression
   expression
   expression
};

I assume this is because they are the block form of expressions that can be written differently, such as:

Code:
eval '$x';



------------------------------------------
- Kevin, perl coder unexceptional! [wiggle]
 
Hummm - could either learn a bunch of case by case rules, or, ... save the brain power and just slap those ;'s out there! [frog]
 
Its one thing about perl I also find frustrating, but there are also rules and exceptions in other languages. Perl isn't too bad with the rules/exceptions, you learn them as you go.

------------------------------------------
- Kevin, perl coder unexceptional! [wiggle]
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Sponsor

Back
Top