|
Nice one!
Swindle CON
discharge VENT
charged ION
tradition
CONVENTION
"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 originally had
Sisters place charged for assembly
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
