Forum > Other

TP legacy shiitcode

(1/10) > >>

Weiss:
Not the first time I am trying to use some ancient TP code, and naturally wonder if back in a day they could read what they wrote. Everything, beginning from naming variables, to user input validation (often none) hold no water. Scarce comments, or no comments. Needless copying of arrays. I am very new myself, but that code is written by PhD and such.

And, code published in articles sometime definitely never been compiled, because it contain errors, syntax and logic errors as well. Sometimes I can unwind the logic and see what was meant, and re-write. But then I wonder, if article was published and being referenced in other work, how come no one reviewed for 30 years?

440bx:

--- Quote from: Weiss on April 30, 2024, 04:16:01 am ---how come no one reviewed for 30 years?

--- End quote ---
A number of possibilities come to mind.  Among them:

1. those who reviewed it found the code to be "fine", they would have coded it the same way (or maybe worse.)

2. those who reviewed it found the code atrocious (as you apparently did) but, figured that they would keep their mouths shut because criticism isn't always welcome.

3. they have a PhD in computer science with a minor in covfefe from trump university and the whole thing went so far above their head international space station folks sighted a ufo.

One important thing to keep in mind: just because something is published doesn't mean it's any good. 

Thaddy:
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.

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---program ucsdpas;{ this is not from my curriculum, it demo's an often seen error from the time }varcount: integer;labelStartLoop;begincount := 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 thengoto 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)
--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---//recenty seen, simplified:TBeepComponent=class(Tcomponent);privatepublic  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)

Joanna:
Maybe the TBeepComponent=class(Tcomponent)
Could be used to replace the standard beep with other sounds?

Thaddy:
Yes in system.OnBeep. But this component is an example of the silly over-use of components...
Programmers don't need them, screen drawers love them, they can't help themselves but it is bad coding. Worse if you register it for design time on the components panel...

Navigation

[0] Message Index

[#] Next page

Go to full version