|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
modified 17-May-23 7:54am.
|
|
|
|
|
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.
modified 17-May-23 8:35am.
|
|
|
|
|
honey the codewitch wrote: There is no justification for spending $1000 to possibly save $1000 down the road. It makes no sense.
Despite needing a diagram? Something isn't adding up. Not sure how many people you've employed before but $500-$1K is a joke. Seems that the diagram would take longer than the code according to you. Which makes no sense. People don't diagram something that takes 1-2 days to develop.
honey the codewitch wrote: I wish you'd be a little bit more circumspect about what you write here. It would be nice to keep it civil.
I'm not being uncivil. I'm just challenging you. If saying a senior programmer knows why this is a bad idea is being uncivil in your book, then that's just oversensitivity.
I could also say that always arguing with people (this is where you say you're not) is also being uncivil. But, this is the Internet. Arguing is a way of life here. This is where you say you're just defending your position. And so am I. But, don't make it seem like I'm a bad guy here because I speak of what a senior should know.
But don't worry, this is easily solvable. I'll just stop replying to your click baits.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Despite needing a diagram?
I already have a diagram, which I made the code closely follow.
Jeremy Falcon wrote: Not sure how many people you've employed before but $500-$1K is a joke.
You've maybe never done embedded? Projects don't sprawl when you have kilobytes of RAM and less than 1MB to store your code.
Jeremy Falcon wrote: I'm just challenging you.
I'm sorry but that's false. If you were just challenging me you wouldn't be insinuating things like I think I'm a senior developer when I'm not - that's insulting, and it's nonsense. You should know better.
Jeremy Falcon wrote: I could also say that always arguing with people (this is where you say you're not) is also being uncivil.
There's nothing uncivil about a debate. This is about the statements you made that specifically did not further it.
I stand by what I wrote.
To err is human. Fortune favors the monsters.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
