My personal preference is to always separate end from the rest of the statement, makes reading statements easier.
I think for one time I completely agree (and giving the high degree of subjectivity of the matter I’m even a little worried about that 
)
Really, this all resonates too well with what I see in the codebase I work what I struggled with while debugging and, even more specifically, how much my weird mind values the 3 space indent making the body of a do or if align with the iterator/condition.
As several people have already mentioned, the choice in these matters is rather subjective. The most important thing as far as I am concerned is that the style is consistently used. At the very least within one example. I have seen code, ugh, where the indentation varied from none (or even negative) to four spaces within the range of a single screenful. That plays havoc on my ability to comfortably read it.
1 Like
While I agree that a four spaces indent could be too much for deep nesting, I still use four spaces because it encourages me to avoid deep nesting, which could be considered unclean.
With two a two spaces indent I have problems to recognize which lines are aligned, if the nesting is too deep.
2 Likes
A possible but (un)popular choice between four and two space indentation is to use three, which at least for me brings the right balance between too deep indentation and being to cluttered. Possibly due to binary counting the three is usually not considered.
5 Likes
Three spaces are fine for fixed form.
Nice poll, which I discovered just now. Many people don’t realize a good, constant programming style is essential.
- snake_case for variables, and with enough letters to tell what it is right away. There is nothing worse than trying to remember what that variable
xyis, in a code you wrote yourself six months ago and you probably forgot things since then. Those of you old enough to have programming experience in 8-bit computers of the 80s (when only the first two letters were significant) know exactly what I’m talking about. - camelCase for procedures. PascalCase is better, but I save it for library procedures. I saw this convention somewhere years ago and adopted it. You can still read procedure names easily and they clearly distinguish themselves from snake_case variables.
- Two spaces for indentation is optimal. I usually see four spaces in other people’s programs, presumably because many editors/viewers default Tab space to four. Also, indenting the body of a procedure (as C programmers often do) serves no purpose other than wasting horizontal space.
- End statements should have spaces for better readbility. Not only that but
end subroutine foois better thanend subroutine(according to the F standard the latter is actually treated as a syntax error).
(1) and (2) above are interchangeable. Either use snake_case for variables and camel/Pascal case for procedures or vice versa; both are good enough. Mixing them, however, is a masochistic act - you just pay additional time to figure out if go_figure(x) is a function call or a vector element.
A problem with capitalization is that Fortran doesn’t care about it and you can easily type camelcase instead of camelCase without realizing it for ages. There should be a compiler flag (perhaps not enabled by default) to treat those two as different. So far the only compiler I’ve seen that does that is the old SunStudio Fortran compiler, later on included in Oracle Developer Studio, and now a dormant/abandoned project.
Lastly, a joke I’ve seen somewhere years ago: Real programmers never indent their code, never name their variables in a sane way, and never add comments. It was hard to write the code, it should be hard to understand it. 
2 Likes
For Chinese programmers, comments are often in Chinese, and Chinese characters generally occupy 2 words wide (as well as Japanese/Korean), so I believe Chinese programmers will be more inclined to indent 4 spaces, or the priority is 4-space > 2-space > 3-space.