It can't be that bad without seeing code.
But I am afraid that I also wrote silly code in ucsd/apple pascal for a curriculum I gave at university: introduction in programming for social science students in 1980/81.
program ucsdpas;
{ this is not from my curriculum, it demo's an often seen error from the time }
var
count: integer;
label
StartLoop;
begin
count := 1;
goto StartLoop;
{2024 comment: This part of the code will never be executed }
writeln('This line will not be printed, silly.');
StartLoop:
writeln('Count: ', count);
count := count + 1;
if count <= 5 then
goto StartLoop;
writeln('Loop finished.');
end.
Goto's everywhere, a necessity, bad formatting (lack of indentation), some but not extensive validation of input and output, wrong choice in program flow by not examining what codeblock was executed most, which is a logic error, etc. some but sparse comments because the code was explained in an external booklet that came with it, explaining functional design and program flow, flowchart. Not yet any real modelling.
On the other hand, that was also due to language limitations at the time.
Then came TP1, with which you could write all kind of trickery because the compiler wasn't very strict (that's mild). So we wrote code using that trickery, just because we could!, like self modifying code and stack trickery.
From TP3 onwards things started to improve: the more people used it, the better the standards regarding code and comments improved.
Then came TP5.5 - TP7 with its quirky, still supported halfway OOP, that initially few understood, but modelling became quite common(by hand).
In the Delphi era, we became much more used to - a much more mature - OOP and things improved considerably with tools like modelmaker with its at the time unrivalled support for code generation based on documentation and an uml description to generate the program body. Certainly in a professional environment the future started to look bright. But bad code is of all times, we see it daily.
In summary: what now looks like bad code from yesteryear is partly due to language limitations. But also evolving programming paradigms, which in turn lead to bad programming because of over-use of components in Object Pascal.(sigh)
//recenty seen, simplified:
TBeepComponent=class(Tcomponent);
private
public
procedure beep;virtual;
end;
procedure TBeepComponent.Beep;
begin
system.Beep;
end;
A slight relief may be that programmers in other languages were even worse: BASIC, C. Forth.
And some much better, in my case, Fortran and COBOL.
I still love COBOL because of its structure, almost self-documenting.
i also still use it: many a phone call to fix COBOL issues because people know I am proficient in COBOL. (very well payed, btw)
Recent
