From senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!col.hp.com!usenet.eel.ufl.edu!spool.mu.edu!howland.reston.ans.net!gatech2!swrinde!cs.utexas.edu!utnut!nott!cu23.crl.aecl.ca!usenet Tue Dec 12 12:52:20 1995 Newsgroups: comp.lang.fortran Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!col.hp.com!usenet.eel.ufl.edu!spool.mu.edu!howland.reston.ans.net!gatech2!swrinde!cs.utexas.edu!utnut!nott!cu23.crl.aecl.ca!usenet From: glenr@cu71.crl.aecl.ca (Glen Reesor) Subject: Fortran Coding Style for the Modern Programmer X-Nntp-Posting-Host: cu71.crl.aecl.ca Message-ID: Sender: usenet@cu23.crl.aecl.ca (USENET News System) Organization: AECL-Research X-Newsreader: knews 0.9.3 Date: Fri, 1 Dec 1995 18:40:06 GMT Lines: 113 In my (relatively) short time modifying and working with legacy Fortran codes, I have come across a number of, shall we say, interesting tendencies. I attribute these tendencies to a number of things: 1. Historical limitations of compilers and hardware (very understandable-- at least for dusty-deck code, but depressing for newly written code). 2. The author being someone with zero training in how to write maintainable, readable, quality software. (In my opinion, a very significant factor in new Fortran software being written.) Although, I keep telling myself that item 2 is very common, I've lost count of the number of times I've been trying to decipher a code segment and decided there should be an item 3: 3. The author of the code is from a different planet where their logic is a complete reversal (yet twisted in some way) to ours :-) So, in order to soothe my nerves, I've created a guide for writing modern Fortran. There are two especially funny things about this list (in my opinion, of course): - I have encountered every single one of these (within the last 2 years) - Most of these practices are being continued at this very moment by some unnamed people I have encountered So, without further delay, I give you.... Fortran Coding Style for the Modern Programmer ---------------------------------------------- 1. When picking variable names, pick something meaningful then remove all the vowels. If the result is longer than 6 characters, truncate as required. 2. When making code changes, don't delete lines--just comment them out. (You might need them later.) 3. WRITE ALL CODE IN UPPERCASE IT LOOKS BETTER THAT WAY. 4. There is no need to use comments because, "Fortran is self-documenting". (Don't forget rule 1.) 5. Another good reason to leave out comments is that they cause slower execution of your program. 6. If you must include comments, they are easiest to read if you alternate comment lines and code lines (with the same level of indentation), with no blank lines or 'dash' lines in between. 7. When deciding what the condition should be in an "IF-THEN-ELSE" statement, decide what is most logical for a human to understand, then reverse it. 8. When deciding whether to put variables in common blocks or not, choose one of the following: a) Pass all variables on argument lists to subroutines, and put none in common blocks. That way you know exactly where every variable came from. It has the added benefit of reminding you to add variables required in one routine to all routines called before it. b) Put all variables in common blocks, and put none in the subroutine argument list. c) There is no (c)--you must use either (a) or (b). 9. Write your code using implicit typing--that way you don't have to type as much. 10. To make yourself feel at home, always refer to 'cards', 'fields', 'decks' and 'core memory'. 11. When using variables, pick one name when you calculate it, assign it to another one for use in an argument list to another subroutine, and call it something else inside the called routine. (This also has the added benefit of increasing your job security.) 12. When designing the format of your ASCII inputfile, base it on a rigid column structure so you don't have to parse any keywords in the inputfile. 13. To make your program footprint smaller, use the same arrays for different things, depending on which part of the program you're in. 14. When you realize that the same code segment is being written many times, it is best to cut-and-paste multiple times rather than risk a mistake creating a subroutine. 15. To make code more readable, write it like this: if (a .eq. 1) then result = result + 1 else if (a .eq. 2) then result = result + 2 else if (a .eq. 3) then result = result + 3 else result = result + a endif 16. A blank lines must start with a 'C'. 17. The Golden Rule: Regardless of the capacity of the machine your code is to run on, it is more important to make it small and run blindingly fast, than to maximize program readability and maintainability. -- Glen Reesor Opinions are mine, only mine, and definitely not my employer's.