5 ms·

This. To find an example, I did a search for “Commodore PET Basic programs”. Here’s a book from 1979 that shows what spaghetti code looks like, in my opinion:

• anigbrowl 4y ago
  Wow, that takes me back. I learned to program on a PET and would have devoured this book had it been available. As it was one of our math teachers was tasked with teaching the computer classes bu didn't have any programming knowledge beyond input/output, loops, and simple calculations. Books and manuals were hard to come by.
  • lamontcg 4y ago
    Also learned to program on a PET in BASIC writing code that was much messier than this because I was probably 10 years old. Might be why I'm good at restructuring horrible to read spaghetti code.
• Someone 4y ago
  > And this is high-quality BASIC by 1979 standards — it’s in a printed book after all. I don’t think that’s true, certainly not for books of that time period. Because the whole field was changing rapidly, writers would often work under tight schedules, and customers would buy about anything because they only had magazines and books to learn from and review sites didn’t exist. I also think that’s bad Basic for the time. Certainly, comment lines before subroutines would help.
  • pavlov 4y ago
    I would argue that the average program that got printed in a book was probably quite bad but still of a higher quality than the programs people wrote on their own, simply because the latter were usually written without any education or useful models of working programs. It’s like an iceberg of bad code: the underwater part nobody saw was astonishingly terrible by modern standards. That code might be running a business, but its author would never get exposed to professional programming. Today Excel often serves a similar purpose. (Excel isn’t spaghetti though since the execution model is completely different.)
  • codebje 4y ago
    It looks pretty typical for BASIC of the late 70s to me. You wouldn't want to waste characters on commenting code: machines of that era would have only a few KB of RAM, as low as 1K. For the same reason you don't want to waste characters on long, meaningful variable names or on well spaced code. Multiple statements per line isn't to save print space, it's to save RAM. Meanwhile, the program's pretty well structured for such a short bit of BASIC: subroutines start at multiples of 100, for example, and each subroutine starts and ends clearly, no shenanigans like jumping from the middle of one sub to another, no multiple exit points for subs, all as linear as it can be. The use of IF is limited to skipping forward a short way to conditionally execute a line or two only. GOTO only exists in those IF statements. I'd have been happy to have written code like this, back then. I am pretty sure that my uncle ran this exact program on his computer and printed out biorhythms on listing paper, in the mid 80s.
    • Gibbon1 4y ago
      I messed with some programs written in basic for industrial controllers that was written in late 1970's. There is a simple thing. On a lot of machines only spaghettified programs would even fit in the memory available. Academic CS researchers with their unlimited accounts on the institutions mainframe didn't have that worry.
  • deckard1 4y ago
    > comment lines before subroutines would help. That code looks normal to me. I have a ton of BASIC books and magazines. You're talking about a time period before full screen text editors were a thing. It's almost impossible to explain to anyone that didn't have to work with TI-99 BASIC, C64 BASIC, GW-BASIC/BASICA, etc. what it was like. Once you got to QBASIC/QuickBASIC it was done. Life was easy. A few years before that, and you're printing out pages on a dot matrix printer and going line-by-line to debug. You'll notice a distinct lack of white space between lines and that comments start with "REM" and a line number. You didn't even get labels for lines. The code looks like that because those were technology limits on really rudimentary devices. You were editing code inside the BASIC interpreter, often using some command like "LIST <line#>". It was awful. We take so much for granted today. Dual monitors. Color. More than 80x25 character display. Multiple screens and multitasking. Just getting to Linux in '95 and having F1/F2/F3/etc. switching terminals was a huge deal.
• Closi 4y ago
  Worth also noting the sort of wild limits with Basic too that are partially responsible for the code being spaghetti, including effectively an inability to add new lines in the code without adding a goto between previous statements.
  • bombolo 4y ago
    What are you talking about? gwbasic had a function to relabel all the lines. And the labels skip by 10 numbers exactly for the purpose of inserting lines. Then when you had hit the limit you'd ask the computer to relabel them in steps of 10 again.
    • klyrs 4y ago
      So many hours of my childhood. Wasted. Damn you. Why didn't you tell me about this then?
    • Closi 4y ago
      > gwbasic had a function to relabel all the lines. And the labels skip by 10 numbers exactly for the purpose of inserting lines. Then when you had hit the limit you'd ask the computer to relabel them in steps of 10 again. gw-basic was released c4 years after this book, and there was a huge change over that period: 1976 - Release of Apple I 1977 - Release of Apple II / Commodore PET 1979 - This book 1982 - Commedore 64 1983 - GW Basic This book is pretty much closer to the Apple I than gw-basic. Perhaps I should have specifically said developing basic in 1979 though as referenced in that book though (and there isn't just one sort of basic - there are so many dialects).
• thaumasiotes 4y ago
  > The first program listing is on page 24 of the PDF. Try to follow the logic of the program. Why does line 400 go to 280? What paths can lead to line 400? Who knows! Without looking at the post-program material, this isn't exactly a difficult question to answer. Line 400 is preceded by some print statements: 370 PRINT "PRESS 'E' TO END, SPACE TO CONTINUE" 380 GET R$:IF R$="" THEN [goto] 380 390 IF R$="E" THEN [goto] 120 400 L=0:GOTO 280 So we have a prompt that says "press E to end, space to continue", and then branches one of three ways: if you provide no input, the prompt is shown again; if you provide an E, the entire program restarts from scratch, and if you do anything other than that, the count of lines drawn on screen is reset to 0 and the next 18 lines of the chart are drawn. We can assume that line 400 will be hit whenever a piece of chart is drawn to the screen. The program's structure here is a nested loop: there is a loop between lines 280 and 400 (displaying the chart indefinitely, 18 lines at a time) containing another loop between lines 300 and 360 (displaying 18 lines of a chart, one line at a time). Why is this supposed to be an example of spaghetti code?
  • j16sdiz 4y ago
    Now imagine you have got a typo: 400 L=0:GOTO 290 This would be almost impossible to debug.
    • thaumasiotes 4y ago
      That would correspond to the following C: /* 280 */ do_something(); for (;;) { /* 290 */ /* display chart in blocks of 18 lines */ /* 400 */ L = 0; } when the correct code is this: for (;;) { /* 280 */ do_something(); /* 290 */ /* display chart in blocks of 18 lines */ /* 400 */ L = 0; } The bug is that the call to do_something() precedes the outer loop when it should be inside the loop. Is that easier to debug in C than it is in the BASIC program? What's the difference?
• version_five 4y ago
  Pretty sure we had that program on our home computer in the 80s (I was a young kid but I distinctly remember a biorhythms program). What impresses me reading it now is the "y2k" compliance. If the year entered is only two digits, it adds 1900, otherwise it takes the full year.