In defense of spaghetti code. *ducks*
-
I understand and mostly agree with your reasoning, but writing spaghetti code feels dirty, somehow.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
I feel the same way, and when I was less experienced I used to - if not outright refuse to write code like this, I would make excuses to myself to get away from it at least. Experience is an expensive teacher, but it taught me (among other things) that successful projects virtually never rest on great code. They rest on effective development practices, and those are more bespoke the smaller the team is. Time is money, and money is king. That's what makes me feel dirty - acknowledging that cold reality. If one is not something of a bean counter when one plans out their coding one could do better - by the clients.
To err is human. Fortune favors the monsters.
-
I ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, but questionable in terms of how effortlessly one can make changes (whereas maintainability is more about stepping away for a month and being able to pick it up again, mostly - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
Wait till you have to modify that code 5 years from now. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, but questionable in terms of how effortlessly one can make changes (whereas maintainability is more about stepping away for a month and being able to pick it up again, mostly - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
There's spaghetti and there's spaghetti.
if (oldState == "state1" && newState == "state2")
{
}
else if (oldState == "state2" && newState == "state3")
{
}
else if .. else if .. else if .. else { }
// line 1000This may feel like spaghetti, but as long as your code reaches one or more if-statement sequentially and it's readable and you can follow it's not so bad. It's quite easy to refactor, should you ever want to.
public class StateClass
{
public static string oldState;
public static string newState;
}public class DifferentClass
{
//...
StateClass.oldState = "whatever";
StateClass.newState = "something";
//...
SomeControl.Text = StateClass.newState;
}public class AnotherClass
{
private object field1;
//...
private object field90;
//...
if (StateClass.oldState == null) throw new Exception("State not set.");
if (StateClass.oldState == "state1" && StateClass.newState == "state2")
{
SomePublicOrStaticVar = "";
}
else if (StateClass.oldState == "state2" && StateClass.newState == "state3")
{
}
else if .. else if .. else if .. else { }
// line 1000
//...
}Now it's going real spaghetti-like. You'll always have to wonder what will happen everywhere once you set or read either oldState or newState. Also, your code has to run in a specific order, but in different classes so it's not at all obvious or even logical. Not sure what SomePublicOrStaticVar does, but setting it or reading it at the wrong time is sure to mess up something somewhere. Having 90 private fields is also a huge strain on your cognitive abilities. Everything you do in such a class you have to wonder "will this mess up other methods that rely on this field?" Believe me, I know X| I've had code like this mess up Form1 because a user changed something on Form2 (which had no relation to Form1 whatsoever). To me, it mostly comes down to this, how many variables do you have to worry about at any given time and how visible are those variables among your different classes? Large code chuncks aren't the problem (although slicing them up can improve readability and maintainability). Lots of if-statements aren't a problem either, as long as they don't work on too many different (public) variables. When functions have their input and output and nothing else to worry about you can rewrite to your heart's contents if you wanted to and the function may remain a black box if it returns the correct output. I think you're good enough to go for the first spaghetti.
-
I understand and mostly agree with your reasoning, but writing spaghetti code feels dirty, somehow.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
I have the impression that OP interchanges 2 things: purpose built single use code, and code with horrible control flow and global data access. I've written code for running on DSPs, on the bare hardware, and everything was purpose coded with a thin hardware abstraction library I made. In my case I had only 16K program memory and 2K RAM. hardware limits aside, when you are programming close to bare metal, it starts to be less and less useful to implement generic frameworks.
-
I ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, but questionable in terms of how effortlessly one can make changes (whereas maintainability is more about stepping away for a month and being able to pick it up again, mostly - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
I, two have written spaghetti code when in the embedded world a simple if ends up with so many 'just in case' else if combined with testing or trying to bust it. The funniest thing is a brand new shiny software grad looks over your shoulder and makes suggestions in the end you say have at it. He thinks the a switch will work better takes a "spaghetti unmaintainable mess" refactors to make it better and the code when compiled won't fit on the chip (8-bit PIC, cheapest possible) raises H,E, double hockey sticks that the chip is wrong goes to Boss basically says 'Idiot is using the wrong chip' orders the correct chip, code runs but too slowly and doubles the price. Egg on face, goes away hurt. Short story if it works it ain't stupid.
-
I ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, but questionable in terms of how effortlessly one can make changes (whereas maintainability is more about stepping away for a month and being able to pick it up again, mostly - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
-
Wait till you have to modify that code 5 years from now. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Are you sure you read my OP? Why would I have to modify code 5 years from now that costs $1k-2k to rewrite?
To err is human. Fortune favors the monsters.
-
If your diagrams are riddled with:
honey the codewitch wrote:
so many conditions around state changes and such
then, how can you trust the accuracy of them diagramz?
"If we don't change direction, we'll end up where we're going"
Because as complicated as they are, the flows are coherent.
To err is human. Fortune favors the monsters.
-
Because as complicated as they are, the flows are coherent.
To err is human. Fortune favors the monsters.
Interesting. If there is no maintainability argument against spaghetti, then the only argument against it is that spaghetti carries a greater risk of subtle typos. Whereas a generic machine could be "proven" to be correct with a great effort. It is not a clear bet, but I think that I too, would lean towards: pasta.
"If we don't change direction, we'll end up where we're going"
-
I ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, but questionable in terms of how effortlessly one can make changes (whereas maintainability is more about stepping away for a month and being able to pick it up again, mostly - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on.
Knowing why this is a bad idea separates the seniors from those who think they are seniors but are not. Even on the off chance you can make sense of spaghetti, in a year or two it'll be harder if you come back to it. If it's handed off to another dev, it'll be harder. As an aside, if a rewrite is only $2k, then it sounds like there should be no need for a diagram at all. But anyway, if it will be used for anything customer facing, there should be _some_ design to the code. Otherwise, don't do it. If it's a personal script that'll never leave your own machine that's fine or maybe even for a prototype/POC. But at the end of the day, people talk about saving time with a poor design simply because they never learned proper design to begin with and time is the number one excuse people use to not do something. It doesn't take much effort to avoid spaghetti despite not having the best stellar design.
Jeremy Falcon
-
I, two have written spaghetti code when in the embedded world a simple if ends up with so many 'just in case' else if combined with testing or trying to bust it. The funniest thing is a brand new shiny software grad looks over your shoulder and makes suggestions in the end you say have at it. He thinks the a switch will work better takes a "spaghetti unmaintainable mess" refactors to make it better and the code when compiled won't fit on the chip (8-bit PIC, cheapest possible) raises H,E, double hockey sticks that the chip is wrong goes to Boss basically says 'Idiot is using the wrong chip' orders the correct chip, code runs but too slowly and doubles the price. Egg on face, goes away hurt. Short story if it works it ain't stupid.
Things like a long if statement rather than a switch, assuming that made an actual difference, isn't what constitutes spaghetti code. Optimizations that are not "normal" to fit on a microcontroller or having to rollup loops for performance, etc. isn't spaghetti. And those can be documented in code as well. Comments have zero impact. There is rarely a reason to not have some organization with your code, even if the cost of a function call is expensive.
Jeremy Falcon
-
Are you sure you read my OP? Why would I have to modify code 5 years from now that costs $1k-2k to rewrite?
To err is human. Fortune favors the monsters.
In 5 years, you'll know the answer. Ravi is an old timer (said with love) and is very experienced.
Jeremy Falcon
-
I understand and mostly agree with your reasoning, but writing spaghetti code feels dirty, somehow.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
If it feels dirty, it's because it is. Trust your instincts.
Jeremy Falcon
-
In 5 years, you'll know the answer. Ravi is an old timer (said with love) and is very experienced.
Jeremy Falcon
I've been programming since 1986, and professionally since 1996.
To err is human. Fortune favors the monsters.
-
honey the codewitch wrote:
The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on.
Knowing why this is a bad idea separates the seniors from those who think they are seniors but are not. Even on the off chance you can make sense of spaghetti, in a year or two it'll be harder if you come back to it. If it's handed off to another dev, it'll be harder. As an aside, if a rewrite is only $2k, then it sounds like there should be no need for a diagram at all. But anyway, if it will be used for anything customer facing, there should be _some_ design to the code. Otherwise, don't do it. If it's a personal script that'll never leave your own machine that's fine or maybe even for a prototype/POC. But at the end of the day, people talk about saving time with a poor design simply because they never learned proper design to begin with and time is the number one excuse people use to not do something. It doesn't take much effort to avoid spaghetti despite not having the best stellar design.
Jeremy Falcon
Jeremy Falcon wrote:
Knowing why this is a bad idea separates the seniors from those who think they are seniors but are not. Even on the off chance you can make sense of spaghetti, in a year or two it'll be harder if you come back to it. If it's handed off to another dev, it'll be harder.
Perhaps I wasn't clear in my original comment, but I tried to be explicit about the low cost of a rewrite. There is no justification for spending $1000 to possibly save $1000 down the road. It makes no sense. There's little justification for even spending $500 to again, possibly save $1000 down the road when the downside is that you go dark in terms of client visibility as you're developing the framework in the alternative. Edit: What we have is a fundamental disagreement, which you're trying to paint as hubris, and that's insulting. I think my contributions here speak for themselves, as well as my extensive history of successful development projects. I wish you'd be a little bit more circumspect about what you write here. It would be nice to keep it civil. :)
To err is human. Fortune favors the monsters.
-
Interesting. If there is no maintainability argument against spaghetti, then the only argument against it is that spaghetti carries a greater risk of subtle typos. Whereas a generic machine could be "proven" to be correct with a great effort. It is not a clear bet, but I think that I too, would lean towards: pasta.
"If we don't change direction, we'll end up where we're going"
Regarding the flows, the reason they are complicated is we're dealing with 3 buttons, and on top of that, an e-paper screen with a 3 second refresh. Buttons must ergo be contextual based on the screen, and transitions between screens must be minimized. Furthermore, the machine sleeps. When it sleeps it runs just like a hard reset on wakeup, but with a different "wakeup reason" so you use that to determine whether you were awoken vs powered on. There's a maintenance screen that can be gotten to by holding all 3 buttons for 10 seconds. Finally, there are inactivity timeouts on each screen, polling intervals for the server CU, and and a watchdog timeout to make sure it doesn't hang. So like I said, it's coherent - it's just complicated. :)
To err is human. Fortune favors the monsters.
-
Things like a long if statement rather than a switch, assuming that made an actual difference, isn't what constitutes spaghetti code. Optimizations that are not "normal" to fit on a microcontroller or having to rollup loops for performance, etc. isn't spaghetti. And those can be documented in code as well. Comments have zero impact. There is rarely a reason to not have some organization with your code, even if the cost of a function call is expensive.
Jeremy Falcon
While I hear you, I do have one niggling nit to pick with your suggestion that comments *do* have zero impact if you mean they have zero negative impact on your codebase. They do. Comments are extra maintenance, and often get stale. They should be used as sparsely as possible and no sparser. For the most part, code should be self documenting. This is not as true in embedded where you often can't afford the necessary abstractions to express intent, such as using the STL algorithms everyone is familiar with. In the case of embedded comments tend to be more necessary.
To err is human. Fortune favors the monsters.
-
I have the impression that OP interchanges 2 things: purpose built single use code, and code with horrible control flow and global data access. I've written code for running on DSPs, on the bare hardware, and everything was purpose coded with a thin hardware abstraction library I made. In my case I had only 16K program memory and 2K RAM. hardware limits aside, when you are programming close to bare metal, it starts to be less and less useful to implement generic frameworks.
In my case, I opted for making the code flow with the rather complicated flowcharts I was provided. Rather than abstract everything to make it cleaner, because of the reasons I stated before, I decided that at the very least the code could follow the documentation, however messy. At least the documents and the code match somewhat. :)
To err is human. Fortune favors the monsters.
-
I ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, but questionable in terms of how effortlessly one can make changes (whereas maintainability is more about stepping away for a month and being able to pick it up again, mostly - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
I'd only have a problem with spaghetti code if there was a fairly straightforward way to simplify it (maybe with a table of state transitions) or if it would have to evolve to support a stream of new capabilities in subsequent releases. I worked on telecom call servers for many years, where spaghetti code made it a pain to work on various products. The problem is hundreds of supplementary services that modify the behavior of basic calls. If some of their logic is inserted into the basic call code, it soon becomes spaghetti. More services were implemented every release, so you also got a bunch of developers all needing to add more spaghetti to that code. When I was tasked with rewriting one of these products, the design eliminated the spaghetti by separating all of the services' state machines. It used static and dynamic chains of responsibility with observer capabilities, which allowed state machines to be triggered, after which they could override or reuse basic call behavior. I'd write an article about it, but I think the design is overkill for most domains. However, it would likely be very useful when developing software that supports a lot of bidding conventions for contract bridge.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I'd only have a problem with spaghetti code if there was a fairly straightforward way to simplify it (maybe with a table of state transitions) or if it would have to evolve to support a stream of new capabilities in subsequent releases. I worked on telecom call servers for many years, where spaghetti code made it a pain to work on various products. The problem is hundreds of supplementary services that modify the behavior of basic calls. If some of their logic is inserted into the basic call code, it soon becomes spaghetti. More services were implemented every release, so you also got a bunch of developers all needing to add more spaghetti to that code. When I was tasked with rewriting one of these products, the design eliminated the spaghetti by separating all of the services' state machines. It used static and dynamic chains of responsibility with observer capabilities, which allowed state machines to be triggered, after which they could override or reuse basic call behavior. I'd write an article about it, but I think the design is overkill for most domains. However, it would likely be very useful when developing software that supports a lot of bidding conventions for contract bridge.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I'm almost doing that, but I actually have several state machines working in tandem, which, while kind of unfortunate due to the spinning plates factor, was very expedient. The codebase is small, and a rewrite wouldn't be terribly expensive given how little time it took me to write it in the first place. I've found with a lot of embedded stuff it's like that. You *have* to keep it small and efficient, so the rules and priorities change a bit as the landscape shifts.
To err is human. Fortune favors the monsters.
