Thank you Bill and Mecej4 for your comments.
It’s not the change in terminology that bothers me anywhere near enough as the insistence that the new usage is the only possible one, trampling roughshod over what may be lengthy traditional and common usage – there is no other in language. Fortran Standards are usually honoured in the breach than the observance, I find.
For me, the additions in Fortran 90 et seq. made the ting into a different language, and it might have been called a different name, even though it encapsulated the whole of Fortran 77. We know that it was poorly thought through because its deficiencies showed through rather quickly. Those additions and alternatives showed to me that the committee at the time – and for all I know, right up to the present – didn’t like Fortran and its foibles at all. They seem to have wanted it to be Algol, which I suppose ought to have pleased me, because I cut my teeth on Algol, and consider it to be a far superior framework for programming. However, I soon discovered that Algol was implemented rather differently – if at all – on different computers, and Fortran had the benefit of near-ubiquity. That hasn’t stopped it being a bizarre, cobbled-together, ill thought-out programming language. A bit like English, I suppose.
To return to the intent of the current thread, my approach to all this has been for many years to have my source code in different files. In the early days of the PC most of those files contained only one subprogram, but now they are much larger as up to a point, a couple of thousand lines is not challenging to any editor. I always have a block of comments at the start of each such source code module, listing its subprogram contents and giving their start line number. I update the list once or twice perhaps each year, as the line number only needs to be approximate to find the routine easily, then I copy the whole block and paste it into another file called WHEREIS.FOR. That is then where I search for a particular routine if I have forgotten where it is.
I also add the source code file name to any subprogram call, like this:
CALL NEW_FILE ( … ) ! SS_9
Where in this case SS_9.FOR is the source code file where SUBROUTINE NEW_FILE resides.
As for COMMON blocks, which I use for preference and from habit, they are listed in a related file called WHATIS.FOR (why they are .FOR files I don’t know, probably because I’m looking at .FOR files when I consult them) along with descriptions of what the variables are. I also list the meanings of all arrays, even though I tend to add comments of explanation in the source code.
I find that the linker messages about the lengths of named COMMON blocks to be invaluable in finding problems in other peoples’ code. I don’t seem to get on with INCLUDE, because I treat each subprogram on its own and I like to see how things are declared. For that reason, I don’t think I should ever get on with USE as a substitute.
A reason why COMMON blocks are different lengths in different routines relates to the size of the individual variables. Back in the late 60s and early 70s when one could easilly find oneself programming on a British made computer, INTEGERs had the same two 24-bit words as REALs. One doesn’t get 48-bit INTEGERs these days, and one was far less likely to get a bad round off effect with 48 bit single precision REALs than with 32-bit REALs, and if DOUBLE PRECISION was there at all, it would have been 96 bit rather than 64 bit, not that it was useful in a computer that might have 32k of those 24 bit words. I found that this variable length issue occurred far more commonly (pun intended) than programmers declaring the arrays to be of different length (although one case I looked at recently in another post the chap had altered the order of the variable names in one routine – I’d never seen that before).
