Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!mips!atha!aunro!alberta!mts.ucs.UAlberta.CA!Al_Dunbar From: userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) Newsgroups: comp.lang.fortran Subject: Re: A Question of Style Message-ID: Date: 25 May 91 17:21:48 GMT References: <12306@uwm.edu> Organization: MTS Univ of Alberta Lines: 65 In article , burley@albert.gnu.ai.mit.edu (Craig Burley) writes: >Somehow I missed these intermediate postings, so here goes: > >In article userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: > > In article <1991May21.180713.1602@unixg.ubc.ca>, buckland@ucs.ubc.ca (Tony Buckland) writes: > >In article <1991May21.140440.16964@m.cs.uiuc.edu> kornkven@m.cs.uiuc.edu (Ed Kornkven) writes: > >>burley@mole.gnu.ai.mit.edu (Craig Burley) writes: > >>>In article <12306@uwm.edu> jgd@convex.csd.uwm.edu (John G Dobnick) writes: > >>> I have recently run into a FORTRAN compiler that exhibits, to my > >>> mind, an annoying trait. It complains voiciferously about statement > >>> numbers that are defined on statements, but are otherwise unreferenced. > >Wrong, unreferenced labels are NOT "very likely due to an error". I'd put >the odds at more like 5% than the implied 90%+. A nice statistic, but based on what? It is likely true of your code, because you use unreferenced labels. Since I choose not to do this, the odds that the presence of an unreferenced label in my code represents an error is exactly 100%. <<< deletions >>> > > There are a few people around (I'm not one of them, but I will > > defend, although not entirely to the death, their right to be > > themselves) who put labels on statements just as markers, with > > no intention of ever referencing them. The technique can serve > > as a way of locating all statements belonging to some class > > defined in the programmer's head, or as a way of delineating > > program segments, or as a labelling of statements you intend > > to reference one day, or as a labelling of drop-through > > statements for computed GOTOs. Et cetera. > > Comment statements are a much more flexible (and readable) way > to document code than sticking in a specially coded statement > label. Anyway, Murphy's law suggests that eventually your code > will be mangled to actually GOTO an unintended destination. > >Yes, but documenting code wasn't all that was listed. What about labeling >statements you intend to reference someday, as when developing code? That >happens very frequently, and comment statements are a poor substitute, >since they aren't checked by the compiler to determine whether you've >defined the same label twice as unreferenced label definitions typically >are. I agree that comments provide no information to the compiler. The idea is that a paragraph of comment about your future intention may be easier to understand later than a five digit number. Using unreferenced labels for future use certainly will help you reserve them, as the compiler will complain of duplication. But will it also be able to tell you that "you cannot GOTO a statement inside a DO loop or if-endif block from outside" if you do not also show it a GOTO. I am not arguing that you should not be allowed to use unreferenced labels the way you obviously are successfully using them. I just know that it would be a mistake for me to do the same. I also have no problem with a compiler that allows you to tailor how it is to respond to certain constructs that it may determine to be questionable. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "not much better than CANADA | datclaimer" -------------------+-------------------------------------------