Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!world!burley From: burley@world.std.com (James C Burley) Newsgroups: comp.lang.fortran Subject: Re: Fortran 77 Style Guide (long, REPOST) Message-ID: Date: 5 Aug 90 06:26:16 GMT References: <26B89BE1.4349@ics.uci.edu> <2138@cernvax.UUCP> Sender: burley@world.std.com (James C Burley) Organization: The World Lines: 42 In-Reply-To: julian@cernvax.UUCP's message of 3 Aug 90 12:07:02 GMT XVI. Arguments 38 Length of passed CHARACTER variables should be * 44 Passed arguments should be dimensioned * in module I'd be interested in knowing the reasoning behind these two. If you KNOW you want to pass, say, a 6-character string, why burden the code generation (and thus the run-time speed) of the receiving procedure with having to retrieve the actual length from the caller? Furthermore, a checking compiler might be able to figure out that a passed variable's length disagrees with the receiver's declared length more easily and more certainly than figure out that an arbitrary reference to a *-length dummy (such as FOO(6:6), the sixth character) is invalid because the actual argument is not long enough. Similar question about 44, since a checking compiler can't easily check array bounds once the array is passed into a procedure that declares it as an assumed-size array. Also, based on personal experience, if you try and port your application to a host/attached-processor combination that allows you to split routines between host (typically I/O-bound routines) and attached processor (typically compute-bound routines), it won't know how much data of an assumed-size array to pass. So instead of REAL FUNCTION SUM(ARRAY,SIZE) REAL ARRAY(*) INTEGER SIZE You say REAL FUNCTION SUM(ARRAY,SIZE) INTEGER SIZE REAL ARRAY(SIZE) Which either generates the exact same code for SUM or, for a checking compiler, adds bounds checking to references to ARRAY within SUM, but also which provides size information for ARRAY usable in passing the contents of dummy arguments across processor boundaries. Other than some of these minor questions, I think all these postings about coding styles look pretty good, though some of the things (like capitalization) I'd rather leave to automated tools than breaking my fingers trying to obey!! James Craig Burley, Software Craftsperson burley@world.std.com