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.
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)
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
Ph: (301)763-8000 x7748
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:
> 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.