Prior to ASCII and EBCDIC being introduced in the mid 1960s, character sets were a disaster. ALGOL-60 tried to deal with the problem, with mixed success, by allowing separate Publication, Reference, and Hardware representations of programs. Various translators were needed to convert from the hardware representation on one machine to another differing machine.
My first language was BASIC on a PDP-8. BASIC has always used <, >, and = characters in relational operators. So I’m pretty comfortable with them. OTOH, BASIC used " to delimit string constants. So there’s that…
The key is to have good tools to help enforce consistency, per project per custom rules. We all agree on that.
Over time I think we’ll actually agree on a good set of rules.
I meant for keywords, like end if instead of END IF, not for variable and function names, where indeed both lowercase and uppercase should be allowed. I modified my comment above to make this clear.
Some people do quite the opposite: uppercases for all (or most of) Fortran keywords, and lowercases for the user defined names (procedures, variables, etc…). I won’t say this is what I prefer, but it actually makes sense.
You can add me to that list. I find dot operators easier to spot in code and Fortran (f77) was the language I tackled my first bigger projects with. I think I also belong to the minority preferring enddo over end do, since I instantly recognise it when combined, but initially often interpret the latter as two separate statements. This and the dot operators make code a lot more readable for me, no matter how much time I spent looking at (or writing) code using > and end do. On the other hand, I changed quite a few of my former habits (e.g., using upper and lower case to separate Fortran keywords from variable names).
However, all these preferences don’t matter compared to having consistency within a project.
In fact all the alternative syntaxes make sense. For example (/ was used because old punch-card systems often didn’t have [. But now we have a language with multiple syntaxes, and different people prefer different choices, and then you start mixing them in a single project once you have a lot of people contributing, so being able for a single project to limit to a subset seems like a win.
The late Alan Miller, one of the most prolific Fortran 90 open source programmers, used this style, for example in lsq.f90, so this could be called the Miller style.
Yeah, I’m with you on this one. do-enddo, if-elseif-else-endif, and so on all begin with a single keyword, so it seems like they should continue and end with single keywords. On the other hand, constructs like select case can end with end select because they are multiple-word keywords.
For capitalization, I reserve all capital letters for preprocessor macros, and I try to avoid short 1-3 letter macros. When doing linear algebra coding, I sometimes adopt the mathematical style of upper case for matrices and lower case for vectors, particularly when I’m programming with single-character variables. In these cases, the fortran looks more like the math equations. Other times, I mix case within variables, e.g. Navg for what would be typeset as N_{avg} in latex.
There are many languages that use alphabet character-based relational operators. The bourne shell for example uses -eq, -lt, -le, and so on. Many other shells use these same conventions, in part because the symbols <, >, =, and so on have already been used for other things.
Regarding apostrophes and quotes, if a code formatting tool converted one of my strings 'text..."hello"...text' to "text...""hello""...text", I would immediately delete it from my computer and never even consider using it again. What lunatic would think that looks better?
I much prefer [] over (//), and I think fortran was slow on the uptake on this one. The [] characters were not in the f77 (and prior) character set, but they should have been added and used for this purpose with f90.