Comments on: What spaghetti code looks like

By: Seçme Yazılar - 01 Aralık 2008 | Taylan Aktepe

Seçme Yazılar - 01 Aralık 2008 | Taylan Aktepe — Mon, 01 Dec 2008 19:59:32 +0000

[...] Spaghetti Codes Nedir? Kodlama tekniğinizi tekrar gözden geçirmenize neden olacak bir yazı! [...]

By: Eric Wendelin

Eric Wendelin — Tue, 04 Nov 2008 15:28:18 +0000

@Wouter:
Agreed that I might have used “ugly” instead of “spaghetti”, in either case the code is all over the place. Maybe it’s “paint splatter” code…

By: Wouter

Wouter — Mon, 03 Nov 2008 20:56:25 +0000

@Marco: “… but it’s a bug that wouldn’t have come up had you just fixed the original bug without introducing new code” – or perhaps you ADD new bugs when trying to fix the bug that shouldn’t have been there if the code had been written more clearly as well as thoroughly tested. After all, you cannot be entirely sure about what the code is doing, even when and if you know more or less what it is supposed to do.

However badly written, I wouldn’t call this ’spaghetti code’ though. The term ’spaghetti code’ was applied orginally to (Basic and Pascal) code when the execution jumped from one point to another through ‘goto’ statements…

By: Mark Sanborn

Mark Sanborn — Tue, 28 Oct 2008 15:36:01 +0000

Well what if you are in a Perl obfuscation contest? Spaghetti code can look beautiful when looking at with the right perspective. :P Good article Eric, keep em coming.

By: Eric Wendelin

Eric Wendelin — Fri, 24 Oct 2008 15:30:19 +0000

@Marco:
I still disagree about the spaghetti code cycle. A responsible coder would never let something properly designed to degrade so much. Bugs would be fixed without the downward spiral to crappiness.

With any luck, there are requirements to go back to or a programmer/client to ask. Obviously, rewriting should not occur if no one really knows what the program is supposed to do in the first place.

By: Marco

Marco — Thu, 23 Oct 2008 05:09:43 +0000

Dmitri makes a good point: once spaghetti code exists, there *is* a spaghetti code cycle. If code has been produced without tests and without code review, then simply “rewriting” it can often follow the script outlined by Dmitri. I wholeheartedly agree with avoiding spaghetti code in the first place, but, if you’ve already got it, the solution is less clear.

You described a case in which you figured out the code enough in order to determine what was causing the bug. Armed with this knowledge and the “obvious” design implied by the form itself, you’ll want to rewrite it and replace it. However, it’s entirely possible that you missed something (it’s spaghetti code, after all) and that that something will bite you later in the release and testing cycle. Granted, you should be able to fix it very quickly, but it’s a bug that wouldn’t have come up had you just fixed the original bug without introducing new code.

The decision to rewrite should definitely be based on how well-tested the existing code is.

By: Eric Wendelin

Eric Wendelin — Wed, 22 Oct 2008 15:23:46 +0000

@Dmitri:
That is the kind of attitude that promotes bad code, and frankly, there is no spaghetti code cycle. Just as Joshua said, if you follow good practice, comment your code for later, and THINK about your design then most bug fixes will be trivial.

This is because good design plans for change and even bugs, because they will show up.

There are rare times for quick fixes, but they should always be replaced by a solution that fits the design. Good refactoring is never change for change’s sake.

@Joshua:
I agree, there are times that projects need to die. If we spent all our time trying to upgrade old crappy stuff we’d never move forward.

By: Joshua

Joshua — Wed, 22 Oct 2008 07:17:38 +0000

Dimitri did you write it or something lol. If you follow good coding practices and design patterns you wont reach the point of spaghetti code.

I agree its terrible code and something else that really peeves me is inline event handlers on elements.

I’ve had to work on spaghetti code before and in many cases I’m not being paid enough to re-write it all just to maintain it. The last time I did that I ended up ditching the project halfway through, it was just too much effort to try to fix someone else’s poorly designed code.