Spaghetti Code - some common perceptions and errors

I came across a site called 250bpm, it has some interesting articles, though most of them are from around 2013. From the many articles this one called "In defense of Spaghetti Code" found here. It is rather interesting for a couple of reasons

What is Spaghetti Code?

Well for starters, spaghetti code is something that is complicated, has a complex and tangled control structure (source: Wikipedia)

It sounds yummy, so what's wrong?

While it is called Spaghetti Code, it has nothing to do with food, it is called so because of the complex tangled code.

The Author of the article discusses about a function that spans 1500 lines of code that was parsing a network protocol. This was code written about 30 years ago. The issue was that through time, the code was altered by vendors to accommodate their requirements.

The code looked something something like

int new_sequence_number (int old_sqn)
{
    return old_sqn + 1;
}

this was changed to

int new_sequence_number ( int old_sqn, int foosoft)
{
    if (foosoft)
        return old_sqn + 2;
    else
        return old_sqn + 1;
}

The idea was that vendor would pass a true for the new version of the protocol, which would change the sequence count based on the vendor. Then another vendor's standards were added and the code looked like

int new_sequence_number ( int old_sqn, int foosoft)
{
    if (foosoft == 2) // ver 5.34.2
        return old_sqn + 3;
    else if (foosoft)
        return old_sqn + 2;
    else
        return old_sqn + 1;
}

you can read the original blog article for a details on this. Then another vendor that had value of 4 also used 2 as a step value. So going by that the code would look like a big blob of if statements setting the step value.

While there are many ways to manage this with minimal changes to the code and still keeping it manageable.

1. The function have a step value parameter added like

int new_sequence_number (int old_sqn, int step)
{
    return old_sqn + 1 + step;
}

Since the code was written about 30 years ago, the version might not have optionals, etc but the step value could be determined from the vendor code foosoft. Say something like

int new_sequence_number (int old_sqn, int foosoft)
{
    int step = get_step_for_vendor( foosoft );
    return old_sqn + 1 + step;
}

where the function get_step_for_vendor would have the series of if's or a switch case to determine the step value. With modern languages and enhancements to languages, there could be many techniques to handle this kind of a scenario. While this was not about techniques to manage this code better and the body of the code was not available either. My take on this is that the paradigms and the way code is written changes and the methodology used reflects the time when that style was popular. It might be surprising to many new developers that there was a time when a function could be long, and by long I mean really LONG. most of the code was repetitive and the point to consider is that the legacy languages included options like Cobol, RPG, Basic, C amongst others. These did not offer some of the flexibility that is available today.

What's available today?

There is another article on the same site, called "A case for unstructured programming" this was interesting given this example, Instead of the code

if (x) 
{
  doStuff1();
  doStuff2();
}

why can we not ise the unstructured way of using

if (!x) goto stuffed:
doStuff1();
doStuff2();
stuffed:

The immediate association this example made with me was of the guard statements in Swift 2.0, the way the guard statement works is the code is executed only when the condition is not met. Which is equivalent of

  if (condition) {} else {
    // do whatever you want here
  }

The part that evaluates to true is not important here, what is is the part that does not evaluate.

Summary

There are many interesting discussion topics related to development. Unfortunately the field of CS (Computer Science) as compared to IT (the generic everything computer related) has been diluted. There is lesser discussion and interest in the deeper subtleties and options given how popular development/programming has become. Keep an eye out for more articles.