Follow Slashdot stories on Twitter


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Submission + - Not All Bad Code is Spaghetti Code 2

Hugh Pickens writes writes: "Judah Johns writes that many programmers interchangeably use the term “spaghetti code”, with “bad code” and while all spaghetti code is bad code, not all bad code is spaghetti code. Spaghetti code is an especially virulent but specific kind of bad code related to the dreaded (and mostly archaic) goto statement, a simple and powerful control flow mechanism that makes it difficult to reason about code, because if control can bounce about a program, one cannot make guarantees about what state a program is in when it executes a specific piece of code. On the other hand people usually use “bad code” to mean “ugly code”, but if it’s possible to determine why a piece of code is bad and ugly, and to figure out a plausible fix, it’s already better than most spaghetti code. "Spaghetti code is incomprehensible and often unfixable but if you know why you hate a piece of code, it’s already above spaghetti code in quality, since the latter is just featureless gibberish." What causes spaghetti code? Goto statements were the leading cause of spaghetti code at one time, but goto has fallen so far out of favor that it’s a non-concern. "Now the culprit is something else entirely: the modern bastardization of object-oriented programming," writes Johns adding that inheritance is an especially bad culprit, and so is premature abstraction: using a parameterized generic with only one use case in mind, or adding unnecessary parameters. "I recognize that this claim – that OOP as practiced is spaghetti code – is not a viewpoint without controversy. Nor was it without controversy, at one time, that goto was considered harmful.""
This discussion was created for logged-in users only, but now has been archived. No new comments can be posted.

Not All Bad Code is Spaghetti Code

Comments Filter:
  • A C++ header that also contained the implementation (and was not wrapped in ifdef/define) where in the constructor, a pointer to itself would be stored in a global variable (also defined in the header) and any calls to member functions would be routed through this global variable.

    If anyone using this were to create more than one instance of the object, the code would become very unpredictable - yet it was written by a supposed "expert" and was almost used in a commercial product.

  • He came across one case where an intern used inheritance badly and concludes that all code that uses inheritance is bad.

When speculation has done its worst, two plus two still equals four. -- S. Johnson