In defense of spaghetti code. *ducks*
-
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 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.
-
honey the codewitch wrote:
More importantly, progress remains visible with the spaghetti approach
Of course. Ideals should not be applied blindly. They should be followed when they provide benefit.
honey the codewitch wrote:
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
I really, really dislike the claim that abstractions make anything better when no one can provide any evidence at all that future needs of any sort will be needed. If requirements exist, or a roadmap is known or even if someone expressed a desire for a future feature then maybe consider it. But don't do it 'just in case'. Doing so it no better than gambling on the big wheel in a casino (one of the worst odds games in play.) It does not insure any economic future advantage but it does guarantee complexity which future programmers must then maintain (and so must be paid for.)
You covered something very well here that I was thinking about earlier regarding abstractions paying for themselves. :)
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 yare 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
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.
-
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.
:laugh:
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
-
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.
Define "spaghetti code".
-
Define "spaghetti code".
Spaghetti code lacks an easily understandable flow to it. It jumps around in less than obvious ways, basically.
To err is human. Fortune favors the monsters.
-
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.
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
-
The spec was spaghetti, so my choice was to design directly to spec, or try to abstract it. I chose the former, and I'm pretty happy with the result. Including coming in under budget.
To err is human. Fortune favors the monsters.
I've never been over budget. I also don't accept ridiculous schedules. You can have it fast, cheap, and / or good. Pick 2.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
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 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.
-
Solid plan.
To err is human. Fortune favors the monsters.
-
I've never been over budget. I also don't accept ridiculous schedules. You can have it fast, cheap, and / or good. Pick 2.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
I don't know if I'd say never in my case, but it has been long enough that I couldn't point to a situation where I did. When I said under budget I mean the project is due on the 10th of next month.
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.
Something I overlooked yesterday is that you have a detailed spec in the form of these "flow diagrams". It's great when it's easy to see how code implements the spec. If that means spaghetti, so be it. Any blame then lies with the spec writer. :-D
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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.
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
-
honey the codewitch wrote:
More importantly, progress remains visible with the spaghetti approach
Of course. Ideals should not be applied blindly. They should be followed when they provide benefit.
honey the codewitch wrote:
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
I really, really dislike the claim that abstractions make anything better when no one can provide any evidence at all that future needs of any sort will be needed. If requirements exist, or a roadmap is known or even if someone expressed a desire for a future feature then maybe consider it. But don't do it 'just in case'. Doing so it no better than gambling on the big wheel in a casino (one of the worst odds games in play.) It does not insure any economic future advantage but it does guarantee complexity which future programmers must then maintain (and so must be paid for.)
jschell wrote:
dislike the claim that abstractions make anything better
True (in absolute), but in general they help. Indeed, if you just need to print to the standard output, you don't need abstractions (and you don't start with those, ofc) but as soon as some requirement changes that and you will want to do file, on screen, on some API, then abstractions will be better (than, IDK, local ifs, switch even local functions).
jschell wrote:
But don't do it 'just in case'
In general (again), you do it because you care about things like clean code, maintainability and avoid cases like 'only God and me knows... now only God'. :laugh: I've never heard anyone saying that it coded that beautiful/maintainable code 'just in case'... while I've heard a lot of times that the developers were not aware of some clean code principle or did not know how to really implement it.
Eusebiu
-
Something I overlooked yesterday is that you have a detailed spec in the form of these "flow diagrams". It's great when it's easy to see how code implements the spec. If that means spaghetti, so be it. Any blame then lies with the spec writer. :-D
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Well, I don't know... if the spec writer is bad at writing specs, does that mean you need to write bad code? I don't think so... because it's your job to write the code and saying that it's the specs fault, it's a weak excuse. ;) If I see a bad spec, I would discuss this with the writer. Maybe (s)he is junior and does not know/understand the system very well... who knows?!
Eusebiu
-
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.
honey the codewitch wrote:
There is no justification for spending $1000 to possibly save $1000 down the road. It makes no sense.
This is not your decision to take; it's the clients/management/call it what you want. You cannot possibly know what's down the road. Ofc, we don't know your contributions - you might be a 10x developer! You don't need to feel insulted if someone says your decision is not of a senior developer - everyone makes mistakes and no one is always right! The thing is that some of the arguments are not adding up... I just wonder why you posted this knowing (because you 'ducked') that this is not common/best practice. Are you looking for validation? :) (you will probably find it from junior developers or some devs that know your project).
Eusebiu
-
Well, I don't know... if the spec writer is bad at writing specs, does that mean you need to write bad code? I don't think so... because it's your job to write the code and saying that it's the specs fault, it's a weak excuse. ;) If I see a bad spec, I would discuss this with the writer. Maybe (s)he is junior and does not know/understand the system very well... who knows?!
Eusebiu
The worst type of spec is one that fails to address all scenarios that are important to a product's behavior. The developer must then ask the spec writer for clarification or decide what to do in such cases. If the flow diagrams cover all possibilities, they pass this key test. But yes, they should be simplified if possible. Reviews really help to avoid bad specs. Just as there are code reviews, there should also be spec reviews.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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:
what a senior should know
In general, you are right! He is just arguing that in his very particular case it's better to break the rules (and by better he means time to deliver and money saved, not technical excellence or performance improvements). Unfortunately, he did not paint the entire picture - only the parts that supported his decision. Who knows?! Maybe in his very particular case the decision was correct.
Eusebiu
