|
That was good too! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
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 would have to agree. Having worked with Fortran (spaghetti land), "spaghetti code" was often quite efficient. We tried to reduce it's complexity but it just got slower. At least it was not a large piece of code and it was commented. It's still running somewhere. Long live Fortran. Yikes.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
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 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 have programmed a lot of PLCs and while I had a lot of more resources in hardware than you, my coding options were way smaller.
Using JMP to control the flow of the program (IF-Else, Calls, partial returns...) was a must.
There were no other options.
But as you say, having to program like this, it doesn't mean that the code flow has to be ugly, weird or confusing.
The different between clean or crappy programs depends mostly on the person programing it, not on the methodic or the language.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I agree, Bruno. If you need to build a shed, you don't use sky scrapper blue prints.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
If it feels dirty, it's because it is. Trust your instincts.
Jeremy Falcon
|
|
|
|
|
Daniel Pfeffer wrote: writing spaghetti code feels dirty, somehow.
Well, spaghetti sauce does stain...
|
|
|
|
|
My grad school prof stressed "go to" less programming techniques to avoid spaghetti.
Structured code and a few comments was the rule, even with Fortran (which was not easy).
We also used PL/I, Ada, Pascal, C (C++ was in the early stages of use).
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Wait till you have to modify that code 5 years from now.
/ravi
|
|
|
|
|
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've been programming since 1986, and professionally since 1996.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Then you should know better.
Jeremy Falcon
|
|
|
|
|
I do know better. Much better. When I was a less experienced developer, I used to refuse to write expedient code like this, and my projects would suffer in cases where it was called for, particularly given that a lot of abstracted tends code to not survive contact with real world changes.
Again, we have a disagreement. Not only that, a lot more programmers here seem to agree with me than with you, so maybe this doesn't have so much to do with what I don't know or lack of experience, and again, a lot more to do with us simply disagreeing.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Ok, if you want to talk in $s, also post how much did you actually billed (I guess you have an hourly rate)? Then we would agree that it might be cheaper to keep writing spaghetti code.
$1k for a full rewrite seems low at a glance... it's less than a working week (in some cases a 1MD)...
Eusebiu
|
|
|
|
|
It was about a day of work.
That's typical for a lot of IoT codebases. You're dealing with kilobytes of RAM and very little room to store code.
Projects don't sprawl - they can't.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Ok. So, if you won't touch that again and the client takes the responsibility on that, then I can understand that... $500 < $1000.
Eusebiu
|
|
|
|
|
$500 would be roughly the cost of developing an abstraction to despaghetify the code, not to write the code.
To err is human. Fortune favors the monsters.
|
|
|
|
|
One month is just enough. 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
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 { }
This 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 { }
}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 
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 don't think this is spaghetti code; it's just long and complicated. Spaghetti jumps all over the place and would obscure the actual logic far more than this example does (which is completely hypothetical. Not real world at all, by the way.)
Last year I tried a challenge -- to rewrite a hangman game from the late 70's, which was written in an early dialect of BASIC with GOTOs and GOSUBs all over the place, into a modern language. The code was very short, barely a page of A4 when printed out. But to understand this very simple program, I had to print it, and draw lines all over it to work out the program flow, which took over an hour. Imagine if it went to more than two sides of paper! I found a line that was unreachable and would never be executed. Even the person who wrote it wasn't aware. Just a bit of structure, named procedures etc. simplified and clarified it enormously.
But I suspect that what the OP is talking about is something a bit different from that. The code may have had a lot of IFs and branches, but writing it in a clear way with meaningful names, rather than abstracting it all to classes, may have been the right call in this instance. But do a reality check: give it to a colleague and see how long it takes them to figure out the flow and logic.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
