|
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.
|
|
|
|
|
I fully understand the maintenance aspect, but that's nothing to do with blame. Unless you consider telling a coder to not be lazy with code blame then sure. But, I'll repeat again the context of what said and me referring to specific scenarios. This does not disqualify me from understanding what maintenance is.
Jeremy Falcon
|
|
|
|
|
If comments get stale, that's not the fault of comments but the developer.
To be clear, this is what I was talking about when I brought up blame. When you're assigning a fault to someone that's blame.
And again, I don't think it's productive. People make mistakes. Code gets stale. It happens to everyone.
My comment was about maintenance.
To err is human. Fortune favors the monsters.
|
|
|
|
|
This is going nowhere. You have more time to argue than I have a desire to be here. Tootles.
Jeremy Falcon
|
|
|
|
|
Hello? You're the one that started arguing with *me*. I'm simply defending my position.
Not only that, you couldn't keep it to debate, and had to insult my professional abilities and experience.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Nope. Wrong.
And a senior should know better.
Jeremy Falcon
|
|
|
|
|
That doesn't even make any sense. You're seriously arguing that I'm the one that started arguing with you? 
Okay man. Get on with your life.
To err is human. Fortune favors the monsters.
|
|
|
|
|
You're not stopping with the replies... you can have the last word if arguing online is that important to you.
Jeremy Falcon
|
|
|
|
|
At this point I think you're here to troll. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
Jeremy Falcon wrote: If comments get stale, that's not the fault of comments but the developer.
The same with code.
In the PLC world it is a wide extended practice to just add a "AND 0" at the beginning of a code segment to anulate it. That's even worst than commenting it out, because it appears in the cross references as well, commented code doesn't.
I once refactored a program of the "Senior" that taught me whe I started, because it was a PITA to work with it.
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.
|
|
|
|
|
Nelek wrote: The same with code.
100% agree.
Nelek wrote: In the PLC world it is a wide extended practice to just add a "AND 0" at the beginning of a code segment to anulate it. That's even worst than commenting it out, because it appears in the cross references as well, commented code doesn't.
Nelek wrote: I once refactored a program of the "Senior" that taught me whe I started, because it was a PITA to work with it.
For sure man. Not a big fan of titles and there are some that are "senior" but for them it really means they just spent more years not really learning. Buyer beware. Gotta find the good ones.
Jeremy Falcon
|
|
|
|
|
Also, and I repeat, code should be self-documenting as much as possible for the most part. But, the context of this entire chat is about crap code. This is completely contradictory to the subject at hand for the conversation you started.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Also, and I repeat, code should be self-documenting as much as possible for the most part
I said the same thing in my post. In fact it was a fundamental part of my position.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Self documenting code is ofcource the best. That is if it's really documenting in a fashion that anyone can understand. To achieve that means lots of time spent on clever naming.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
