|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
honey the codewitch wrote: They should be used as sparsely as possible and no sparser. To use your wording with Ravi... you may wish to re-read what I said. It was in the context of having to do something not considered normal. Which clearly includes the scenario you referring to.
That being said, I disagree with the premise of being too sparse with comments. I'm not a junior programmer. I don't have the time nor inclination to tell people comments like // assign variable x to y are bad. That should be a given for senior level chats. This is actually the reason I visit CP less and less these days if I'm being honest.
If comments get stale, that's not the fault of comments but the developer. There reasons tools like doxygen and jsdoc exist. Again, if this is code that is for your personal use only, all of this is overkill. But when being paid for it, that tends to suggest it's not.
Jeremy Falcon
|
|
|
|
|
My point in making the statement about comments going stale is not about assigning blame. I thought that was a given, considering assigning blame doesn't do anything.
My point was that it is extra maintenance.
To err is human. Fortune favors the monsters.
|
|
|
|