At one time it was essential to nurse one's dinosaur through every operation, devoting agonising weeks to paring away all non-essential bits of code, carefully crushing storage and recycling every variable to save space, painstakingly timing the different possible ways of coding inner loops and so forth to avoid blowing huge amounts of extra cumulative machine time. I have had to argue niceties of coding in front of committees in order to justify computing allocations for research projects.
As compilers and systems changed, so did the diktats. Sometimes it was important to use three-branched FORTRAN IFs instead of logical ones wherever possible. One needed to copy from 'high' storage to 'low' when accessing variables repeatedly. One needed to minimise the number of CALLs, to keep stretches of code short between labels etc etc ad nauseam. As optimising compilers improved, it was possible to see what programming styles the compiler couldn't improve on!
Now that machines are so much vaster and faster, much of this painfully acquired experience becomes irrelevant and it is rightly more important to write in ways which other programmers can follow without too much pain. Unfortunately, there have been various fashions, some of them apparently rather subjective. There has been an era when 'block structuring' was taught, producing a generation of computer science graduates with a distinctive world view. Large organisations sometimes issue decrees about house style, to the despair of programmers who for possibly very good reasons have differing approaches.
There are fads such as 'avoid FORTRAN labels completely' which have some grounding of sense (IF - THEN - ELSE can aid clear thinking, but can involve much repetition of code). There are nightmare expanses of text explaining every minute detail of the code which is buried somewhere amongst it (curious how programmers who do this are always dyslexic, which badly shakes one's confidence in the programming!) There are program suites built up of thousands of tiny and elementary modules which call each other in unfathomable sequences. I once became so exasperated with some corporate diktats which seemed to be based largely upon one V.I.P.'s personal prejudices that i wrote a tongue-in-cheek article [link here] which caused an interesting polarisation of the audience.
It is certainly a rounding and sobering experience to see what happens when one moves code from one system to another. Since the Age of the VAX may well be approaching an end this needs to be kept in mind at the C.T.S.U. It is well worth looking over the guidelines in the programming manual to make the most of the system of the moment; but beware too of life without system services, without character sub-strings, without dummy function names or whatever is your bagge in the bleak future world!
Probably most important are the ergonomics and speed of a package as seen by a user; the resources it gobbles up; and the way it copes with errors - both internal ones (which inevitably happen) and user mistakes, system collisions and general misunderstandings. We don't really have the resources to create decent instruction sheets for the users, let alone any kind of documentation for other programmers and, as with all research except the military, everything is done in a tearing hurry for results: the initial drawing-up of specifications is nearly unknown; horses are constantly changed in mid-stream; activity jumps from point to point as crises are managed; and finally everything ends up in a dusty box in some cellar as life moves on.
Hmn, i seem to have forgotten the point of this harangue...