Sujet : Re: TeX and Pascal [was Re: The joy of FORTRAN]
De : Pancho.Jones (at) *nospam* proton.me (Pancho)
Groupes : alt.folklore.computers comp.os.linux.miscDate : 03. Oct 2024, 08:59:44
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vdlitg$3kuh8$2@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
User-Agent : Mozilla Thunderbird
On 10/1/24 16:14, The Natural Philosopher wrote:
On 01/10/2024 15:57, Pancho wrote:
In essence just because you can do something clever, doesn't mean you should.
That is what I loathed about compscis. As practising software engineers we specialised in 'good clean workmanlike well documented and structured code'.
Our job was to get the puter to do its job in the most understandable and maintainable way.
Not to impress people with the elegance complexity and incomprehensibility of our REGEX statements.
If all we had was vi and a C compiler, that's what we used.
And knowing that
p=(x>y?3:2);
Yeah, I remember people criticising this 30 years ago, but programmers are used to it now, so it doesn't confuse people.
produced identical assembler to:
if (x>y)
p=3;
else
p=2;
there was a strong temptation to use the latter as being sufficiently simple for the time serving amateurs whose failure to complete the project was why we we employed at all...
We weren't employed to be clever. We were employed to write working code. And document it.
Yes, it is best that code is obvious. Standard design patterns are good too. A familiar complex pattern, is much easier to understand than an unfamiliar one.,
Documentation can be problematic, in that people modify the code but not the comments. I tend to write a header comment block explaining what I initially designed a class is for. A story more than a line by line explanation. Like you, I also start by writing comments and then I fill in the code. That is to help me remember what I'm doing, like notes. Sometimes I leave these comments, sometimes I don't.