phipps@garth.UUCP (Clay Phipps) (04/12/89)
In article <1415@blake.acs.washington.edu>, djo7613@blake.acs.washington.edu (Dick O'Connor) writes: > >The article was in the March 14, 1989 (Volume 8, Number 5) issue of >PC Magazine, Page 329. Author: Charles Petzold, of course <grin>! Good grief, folks ! I read Petzold's article last night, and what he describes is just a glorification of FORTRAN naming conventions. -- [The foregoing may or may not represent the position, if any, of my employer, ] [ who is identified solely to allow the reader to account for personal biases.] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403 415/494-8800
bcw@rti.UUCP (Bruce Wright) (04/13/89)
In article <2701@garth.UUCP>, phipps@garth.UUCP (Clay Phipps) writes: > In article <1415@blake.acs.washington.edu>, > djo7613@blake.acs.washington.edu (Dick O'Connor) writes: > > > >The article was in the March 14, 1989 (Volume 8, Number 5) issue of > >PC Magazine, Page 329. Author: Charles Petzold, of course <grin>! > > Good grief, folks ! I read Petzold's article last night, and > what he describes is just a glorification of FORTRAN naming conventions. This sort of thing is also quite common in various assembler programming environments. For example, on VMS (one of several places where I do a lot of device driver hacking), most of the system-level global names have the general syntax: xxx$l_something - for a longword (32-bit) variable xxx$w_something - for a word (16-bit) variable xxx$b_something - for a byte variable xxx$k_something - for the size of something xxx$v_something - for a bit number or general constant xxx$m_something - for a bit mask (note: xxx = the mnemonic of the facility or data structure having the named object or attribute, often but not always 3 characters). There are more but this gives the flavor of the naming convention. It can make a big difference where you have to use assembler language and can't remember whether some miscellaneous field is a word or a longword (it's not always obvious from context). But I agree that the convention makes C look more like a low-level language. It really only becomes necessary when you are using a language which is so lax about typing (someone I know once said that C only has "pretend" types :-) Bruce C. Wright
hollombe@ttidca.TTI.COM (The Polymath) (04/21/89)
In article <45900223@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: }Except that in Fortran the naming AUTOMATICALLY makes the variable }the correct type! If you see a variable in a normal (i.e. it uses }this method, which is not required) Fortran program, you can tell the }type directly from the name. The last FORTRAN shop I worked in considered this a hazardous practice. So much so, in fact, that their in-house coding standard required an IMPLICIT COMPLEX (A-Z) at the top of every module to force explicit declaration of every variable. If we found something defined as complex in the link map, we knew our wrist had been slapped. (We also had a dandy data-dictionary system that automatically put headers on each module containing all information about each variable used. It even included the appropriate common blocks for us. Saved a lot of grief). -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe