Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site ccvaxa Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!preece From: preece@ccvaxa.UUCP Newsgroups: net.lang.c Subject: Re: C style Message-ID: <2600024@ccvaxa> Date: Tue, 29-Oct-85 10:35:00 EST Article-I.D.: ccvaxa.2600024 Posted: Tue Oct 29 10:35:00 1985 Date-Received: Sat, 2-Nov-85 00:30:15 EST References: <1556@brl-tgr> Lines: 39 Nf-ID: #R:brl-tgr:-155600:ccvaxa:2600024:000:1901 Nf-From: ccvaxa.UUCP!preece Oct 29 09:35:00 1985 > Your examples are not equivelent, you forgot the "else result[i]=0;" > clause for every if on the nested example. /* Written 6:52 pm Oct > 26, 1985 by BLARSON%ECLD@usc-ecl.ARPA in ccvaxa:net.lang.c */ ---------- No, there aren't supposed to be else clauses -- the "result[i]=0" is supposed to happen ONLY if all tests but the last are passed. That is, the function1 - function5 tests are checking whether it is valid to apply the actual test and the failure of any of them is supposed to suppress assignment and terminate the loop. The suggestion that the tests could be written as a single expression by joining them with ANDs is fine for the simplified example, but not applicable if there were additional code involved in setting up before each test Several other comments were received. A couple of people suggested using an array of functions and looping over that array. That also wouldn't work if there were additional code preceding each call, but is reasonable for the simplified example. Care would be required in making it clear what was being done and how to find out which functions were being called in what order, but this approach has a nice generality (the list of functions could be built from a description, automatically). Prof. Lo also wrote to clarify the posting about LOOP-EXIT-END to which I originally responded. The intent was to not use a for loop where it is possible to exit without completing the iteration. That's reasonable, though I think it can be argued that the use of the "for" construct makes it clearer that the NORMAL behavior is intended to be a loop over those hundred values and the annotation should make clear under what circumstances an ABNORMAL exit is made before the end. It is important to readability that the language used make clear not only WHAT happens but also WHY. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece