chris@umcp-cs.UUCP (Chris Torek) (07/26/86)
In article <2954@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes: >ps. Note that a C break statement is nothing more than a goto without >specifying the label. Surely you must agree that a goto without a label >makes for more difficult understanding than a goto with a label. Why must I agree? I do not. A `goto' without a label must have a defined behaviour. If this behaviour is simple enough, the construct will be easy to understand. For example, the FORTRAN `STOP' statement is equivalent to a Pascal `goto 9999' if label 9999 is just before the program end. In other words, STOP is a `go to program end' statement, or a goto without a label. It is also trivial to understand. A C `break' is a `go out of the innermost enclosing loop or switch', and as such requires knowing its context. The more locality of reference in a statement, the easier that statement is to understand by itself, and `break' violates this locality. But so does `end while', and in much the same way; yet I have never heard it argued that an `end while' `statement' is hard to understand. (`End while' is semantically a control flow bracket but is written as a statement. The same is true of `break'.) In a language with `break' and `continue' statements, the body of a loop is not always entirely executed each time the loop test succeeds. If one makes the assumption that it is, and that turns out to be false, naturally one will have trouble understanding the code. It seems simpler not to make that assumption. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
marty@ism780c.UUCP (Marty Smith) (07/28/86)
In article <2619@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes: >In article <2954@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes: >>ps. Note that a C break statement is nothing more than a goto without >>specifying the label. Surely you must agree that a goto without a label >>makes for more difficult understanding than a goto with a label. > >Why must I agree? I do not. > >A `goto' without a label must have a defined behaviour. If this >behaviour is simple enough, the construct will be easy to understand. >For example, the FORTRAN `STOP' statement is equivalent to a Pascal >`goto 9999' if label 9999 is just before the program end. In other >words, STOP is a `go to program end' statement, or a goto without a >label. It is also trivial to understand. > Agreed. But what I meant by "more difficult to understand" had more to do with the destination of the goto or break than with the source. When I see a labeled statement, I presume there is more than one way to get to the statement and hence more than one set of initial conditions for the statement. If I use break instead of goto, there is no label to tip me off. Martin Smith >A C `break' is a `go out of the innermost enclosing loop or switch', >and as such requires knowing its context. The more locality of >reference in a statement, the easier that statement is to understand >by itself, and `break' violates this locality. But so does `end >while', and in much the same way; yet I have never heard it argued >that an `end while' `statement' is hard to understand. (`End while' >is semantically a control flow bracket but is written as a statement. >The same is true of `break'.) > >In a language with `break' and `continue' statements, the body of >a loop is not always entirely executed each time the loop test >succeeds. If one makes the assumption that it is, and that turns >out to be false, naturally one will have trouble understanding the >code. It seems simpler not to make that assumption. >-- >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) >UUCP: seismo!umcp-cs!chris >CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
taylor@glasgow.glasgow.UUCP (Jem Taylor) (07/31/86)
In article <2619@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes: >In article <2954@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes: >>ps. Note that a C break statement is nothing more than a goto without >>specifying the label. Surely you must agree that a goto without a label >>makes for more difficult understanding than a goto with a label. > >A C `break' is a `go out of the innermost enclosing loop or switch', >and as such requires knowing its context. The more locality of >reference in a statement, the easier that statement is to understand >by itself, and `break' violates this locality. But so does `end >while', and in much the same way; yet I have never heard it argued >that an `end while' `statement' is hard to understand. (`End while' >is semantically a control flow bracket but is written as a statement. >The same is true of `break'.) > >In a language with `break' and `continue' statements, the body of >a loop is not always entirely executed each time the loop test >succeeds. If one makes the assumption that it is, and that turns >out to be false, naturally one will have trouble understanding the >code. It seems simpler not to make that assumption. I have long avoided constructs which cause only part of a compound statement or loop body to be executed. As has been pointed out before, it's a matter of personal taste and style if one does not use some features of a language, but I feel much happier if I can regard compound statements as single entities when reading through the code at a higher level; each compound being replaced conceptually by a procedure call. However - this suggests that use of the 'return' statement to leave a procedure body part way through is against my rules of style. In practice, it is. The same rules of conditional-expression formulation that give me blocks without breaks, give procedures without returns. I find colleagues have less trouble with the narrowness of (132) column displays, since I indent with tabs, but with a sideways-scrolling fullscreen editor that is bearable. The thing which convinces me that coding without breaks/returns is 'better', is that when re-formatting other peoples' programs into this form, I have found the resulting code easier to understand, and often been able to see redundant or duplicated tests and code sections. 'RETURNs considered harmful' , anyone ? -Jem. ( I am talking about 'return from procedure', not 'return value from function'. However, even in functions, if there are multiple returns each return-result should be at the end of it's own section, not hidden in the middle. If that makes sense ) -- -------------------------------------------------------------------------------- JANET: ' , ' , ' taylor@uk.ac.glasgow.cs ' ___ , ' USENET: , / | \ , { uk }!cs.glasgow.ac.uk!taylor ' -o| Royal Mail: , ' (J=) ' , J.A.Taylor ~~~~~~~~~~~~~~ Computer Science <>< 17 Lilybank Gardens ><> Jemima GB-GLASGOW G12 8QQ ><> Puddleduck "who says it doesn't rain on the west coast ?"