Why these original FORTRAN quirks?
in [Fortran]
|
From: Richard Maine on 23 Oct 2006 14:46 Greg Lindahl <lindahl(a)pbm.com> wrote: > In article <aTyOFpHpvCHL092yn(a)visi.com>, > Richard Steiner <rsteiner(a)visi.com> wrote: > > >Yes, I could see 10 or 12 characters being quite useful, but things get > >tedious to type quite quickly. :-( > > Folks haven't gotten why this is an issue. The problem is not that a > programmer feels obligated to use the extra characters, it's that a > programmer's coworkers might. Yes. But using the language standard to enforce good programming styles isn't going to work. Anyway, not for Fortran. If your coworkers won't use reasonable variable names, then the Fortran standard isn't the place to look for a fix. Enforcing style choices is not the general approach of the Fortran standard... and that isn't likely to change, particularly as such a change would probably start by invalidating an awful lot of existing code that might have been considered good style for its day, but isn't today. The Fortran standard has a pretty explicit philosophy of facilitating rather than enforcing. In the specific case of variable name limits, the direction of the standard is exactly the opposite of keeping names short. The limit got bumped from 31 to 63 characters in f2003. I think I got those numbers right - not worth checking. Yes, there were actually complaints about the 31-character limit being a problem, mostly because... > Then again, the dominant style in C these days is using quite long > variable names, as a form of documentation. and people want to be able to call those C routines without having to map the names to something else. I didn't define those names. I personally think them ludicrous. But they exist, and the Fortran standard increased its name length limit to accomodate them. I'll also note that I continue to disagree with the claim that readability didn't suffer from the 6-character limit. I think that 63 is ludicrous in the other direction, but that 6 was too short. Yes, I read the explanations here about how some people dealt with the 6-character limit, but I don't buy those explanations. They sound to me too much like rationalizations of workarounds that tried to live within the limit. Maybe the resulting names were clear to those who spent all their time on the particular projects in question, but they aren't clear to me as an independent reader. The schemes also fall apart when code from multiple sources is used, and all the different code sources don't follow the same scheme. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: Greg Lindahl on 23 Oct 2006 16:19 In article <1hnnrqo.ms61yg735l2tN%nospam(a)see.signature>, Richard Maine <nospam(a)see.signature> wrote: >Yes. But using the language standard to enforce good programming styles >isn't going to work. Oh, I agree with that. But I did always like it that F77 didn't have pointers, which meant that my (*&*(&*( co-workers couldn't tie themselves in knots creating unreadable code using pointers like they always seemed to do with C. Some people *need* a straightjacket. Too bad there's no good way to get them into one. >I'll also note that I continue to disagree with the claim that >readability didn't suffer from the 6-character limit. I'll agree with you there, too. -- greg
From: Paul van Delst on 23 Oct 2006 17:11 Greg Lindahl wrote: > In article <1hnnrqo.ms61yg735l2tN%nospam(a)see.signature>, > Richard Maine <nospam(a)see.signature> wrote: > >> Yes. But using the language standard to enforce good programming styles >> isn't going to work. > > Oh, I agree with that. > > But I did always like it that F77 didn't have pointers, which meant > that my (*&*(&*( co-workers couldn't tie themselves in knots creating > unreadable code using pointers like they always seemed to do with C. I find the restrictions on Fortran pointers (compared to other languages where a pointer can point at anything) to make them relatively simple to use/understand. That doesn't mean I think they should be used just because they can, but surely if someone manages to write Fortran-pointer laden unreadable code, they would probably do the same sans pointers? > Some people *need* a straightjacket. Too bad there's no good way to > get them into one. Coding standards are a good start. Maybe followed with regular code reviews where code is projected onto a wall and the author has to justify it? It's enabled me to avert a fair amount of, uh, let's call it "code retooling". :o) >> I'll also note that I continue to disagree with the claim that >> readability didn't suffer from the 6-character limit. > > I'll agree with you there, too. Sometimes I have to get creative when I discover that the variable naming conventions I've adopted have inexplicably lead to variable names longer than 31 characters. I don't know *how* that happens.... :o) cheers, paulv -- Paul van Delst Ride lots. CIMSS @ NOAA/NCEP/EMC Eddy Merckx Ph: (301)763-8000 x7748 Fax:(301)763-8545
From: Terence on 23 Oct 2006 18:18 Joe Morris wrote: > >I think I still have the 4/1/61 Fortran manual around > > H'mmm...which FORTRAN manual are you referring to? Assuming that it's > an actual manual (I noticed that the date you give is April Fool's Day) > that doesn't tell me who published it, or for what implementation. ONLY IN USA is "4/1/61" April Fools day! In the rest of the world it is 4th january 1961 when that version of IBM Fortran came out internally with that "4/1/61" name, and I was introduced to on my first day with IBM. The NEXT day I was supposed to teach it! (To Balfour Beatty Engineering who went on to design all those Eiffel-tower-like electricity pylons, using a Fortran program I worked on with them on, which designed the towers from needed the cable direccions and numbers, top-down to the foundations and produced a list of parts for assembly).
From: glen herrmannsfeldt on 24 Oct 2006 13:42
In comp.lang.fortran krw <krw(a)att.bizzzz> wrote: (snip) > This_is_the_variable_that_holds_the_outside_loop_counter = > This_is_the_variable_that_holds_the_outside_loop_counter + 1; One of the advantages of the C ++ operator, though I agree that overly long variable names don't improve readability. For function/subroutine names I might believe that they could be a little longer than variable names, though. -- glen |