Does this have any special meaning or do anything other than document?
<name> IF <condition> THEN
<block>
ELSE IF <condition> THEN <name>
<block>
ELSE <name>
<block>
ENDIF <name>
I read the standard, but it doesn't even seem to mention the construct. (Which I saw a developer use and is described in Metcalf among other books).
I use it as described in M&R in the style of the following:
weeks: if (day == 'monday') then else end if weeks
Are you referring to the <name> parts? They are in the standard - 8.1.7 in F2008. As for their use, you can give their name in an EXIT statement to exit the construct. At least that's my reading - the compiler seems to have other ideas.....
Duh -- yes referring to the <name> parts.
I didn't see any mention that you would be able to use them in an EXIT statement -- you'd have to put that in the middle of a block to be effective I would think.
<name> IF <condition> THEN
<block>
IF <condition> EXIT <name>
<block>
ELSE <name>
ENDIF <name>
On looking further, I see that the use of EXIT for terminating non-DO constructs is new in F2008. We don't yet support that. The construct names have been allowed in IF since at least F2003 if not earlier.
Okay, then it is probably safe to remove these as it just gets confusing to the reader if it's mostly used for documentation of what else statements belong to which "name".
Steve,
Your documentation states when [name] used on IF, [name] is required on (after) END IF.
The documentaiton is mute as to if [name] is also required on ELSE and ELSEIF.
A "good" programmer would want to use named ELSE, ELSEIF to have the compiler check proper nesting.
Jim Dempsey
The standard does not require the name on ELSE or ELSE IF. I have asked the writers to add text on this.
To old timers who are used to keeping track of nested constructs but nevertheless recognize this as a significant chore sometimes, the <name> feature is a great idea. But unfortunately it does add clutter that can just get in the way. Like the English language, pithy is sometimes best.
At least the feature is optional and not mandatory.
To me the block naming is only useful if the nesting gets too deep. But this is sometimes better avoided in the first place by using GOTO (!!!). But that's another story...
Currently the specification requires naming as follows:
FruitLoops: do i = 1,nThings code here end do FruitLoops
I find this visually annoying because I prefer to see the "do" aligned at the appropriate indentation level. Therefore I would prefe to seer:
FruitLoops: do i = 1,nThings code here end do FruitLoops
Yes, I know I can use:
FruitLoops: & & do i = 1,nThings code here end do FruitLoops
But this looks funky
Jim Dempsey
Jim,
With continuation, isn't the following syntax adequate:
FruitLoops: &
do i = 1,nThings
code here
end do FruitLoops
Why is the leading ampersand before Do needed? Without this, it wouldn't look as funky as you make it out to be.
If I really wanted to name the block, I would put it in the left margin so it doesn't indent the DO over too far. But then, I start all of my code lines in column 7 (a holdover from the past) so, with a block name of up to 5 characters followed by a colon, DO is still aligned with END DO. (This is just one of several things that columns 1 - 6 is good for, so I don't like to see code lines that begin in column 1.)
5 letters are not necessarily a good descriptive name. When you may have 1000's of lines of code between the top of the loop and the bottom of the loop, it is better to rely on a longer descriptive name than it is to rely on a longer discriptive comment.
Single &:
In the case of the name tag, I agree that single & may be appropriate. In the case of the continuation of an expression, I think it important that the continuation & be present as a indicator of continuation (as the end of line & may be off the screen and not be noticed).
Jim Dempsey