Refactoring woes
-
I thought "hey, I don't have a solid design on the generic interface for my video displays because I haven't a clue what all the differences between them are, so I'll write two or three, and then flesh out my general/abstract design based on those, and then backport/refactor the two or three drivers to use the new generalized design" It seemed like a solid plan. Solid enough that faced with a similar, or even the same problem, I'd still consider this approach. But whoa... I've quickly turned things into spaghetti and had to untangle the mess and try again. Now I'm at the point where the coding is like a protracted game of chess. I make a move, take a break, go think about something else. Come back, make another move, go do something else for half the day. At this rate, it will take me a week to refactor. Part of it is because generic programming doesn't always lend itself to refactoring very easily. There are a million reasons for this, some of which I'm (re)discovering. I still will use GP. But ZOMG what a mess I made. It's bad enough that I want to blame it on someone else. :laugh: I think maybe when I'm done I'll write an article about some of the ways GP can bite you.
Real programmers use butterflies
-
I thought "hey, I don't have a solid design on the generic interface for my video displays because I haven't a clue what all the differences between them are, so I'll write two or three, and then flesh out my general/abstract design based on those, and then backport/refactor the two or three drivers to use the new generalized design" It seemed like a solid plan. Solid enough that faced with a similar, or even the same problem, I'd still consider this approach. But whoa... I've quickly turned things into spaghetti and had to untangle the mess and try again. Now I'm at the point where the coding is like a protracted game of chess. I make a move, take a break, go think about something else. Come back, make another move, go do something else for half the day. At this rate, it will take me a week to refactor. Part of it is because generic programming doesn't always lend itself to refactoring very easily. There are a million reasons for this, some of which I'm (re)discovering. I still will use GP. But ZOMG what a mess I made. It's bad enough that I want to blame it on someone else. :laugh: I think maybe when I'm done I'll write an article about some of the ways GP can bite you.
Real programmers use butterflies
I've organized my code (in a program) around "loaded" (event), "unloaded" (event), public, internal and private; seems to help with refactoring, thinking about it, or doing nothing.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
I've organized my code (in a program) around "loaded" (event), "unloaded" (event), public, internal and private; seems to help with refactoring, thinking about it, or doing nothing.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
Yeah, that structure wouldn't really serve me here, and I don't have events as such. I do have one callback but I try to limit those at this level because program code doesn't live in ram on these little monsters, so no matter how efficient you write it, it still has to load it from flash over an SPI serial interface. Since the code *is* cached it is similar to a cache line issue you'd face in perf tuning for say a modern PC except the cache is terribly small. The same rules apply though - keep your code small, and the locality tight, and excessive callbacks like an event based model get in the way of that here. Not that it's impossible. It's just an uphill battle to make it work efficiently, so you end up losing more than you save here. I did work out a model eventually but backporting the code to make it work in the new system is a bear. The code was mostly copy pasted for the first three drivers because the goal wasn't to use that in production, but to use it as a prototype to flesh out the design. Well I did that, but I'm questioning whether it would be easier to just rewrite the drivers over the generalized layer rather than trying to port the existing code. Oh well, I'll work it out.
Real programmers use butterflies
-
I thought "hey, I don't have a solid design on the generic interface for my video displays because I haven't a clue what all the differences between them are, so I'll write two or three, and then flesh out my general/abstract design based on those, and then backport/refactor the two or three drivers to use the new generalized design" It seemed like a solid plan. Solid enough that faced with a similar, or even the same problem, I'd still consider this approach. But whoa... I've quickly turned things into spaghetti and had to untangle the mess and try again. Now I'm at the point where the coding is like a protracted game of chess. I make a move, take a break, go think about something else. Come back, make another move, go do something else for half the day. At this rate, it will take me a week to refactor. Part of it is because generic programming doesn't always lend itself to refactoring very easily. There are a million reasons for this, some of which I'm (re)discovering. I still will use GP. But ZOMG what a mess I made. It's bad enough that I want to blame it on someone else. :laugh: I think maybe when I'm done I'll write an article about some of the ways GP can bite you.
Real programmers use butterflies
Didn't you write a parser/lexer/n2-B*-LALR-@#D@-tree so a program can do this for you? :D Unrelated, but I had an issue this week and I thought of you the moment I found it. So I had this code.
if (something)
{
DoStuff();
}And the customer called and said, we always need to do more stuff! And so I opened the code, added more stuff and fired it up for a test run... Only to find that more stuff did not happen. I quickly found the error. I had put
DoMoreStuff();
inside of the if-statement because that's where most stuff happened, making this like the inverse of the braceless-if-statement-only-executes-next-line-problem. When I found it I though "this would never have happened to code witch!" :laugh:Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Didn't you write a parser/lexer/n2-B*-LALR-@#D@-tree so a program can do this for you? :D Unrelated, but I had an issue this week and I thought of you the moment I found it. So I had this code.
if (something)
{
DoStuff();
}And the customer called and said, we always need to do more stuff! And so I opened the code, added more stuff and fired it up for a test run... Only to find that more stuff did not happen. I quickly found the error. I had put
DoMoreStuff();
inside of the if-statement because that's where most stuff happened, making this like the inverse of the braceless-if-statement-only-executes-next-line-problem. When I found it I though "this would never have happened to code witch!" :laugh:Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
You know, I'd be open to changing my bracing style if I ever ran into the problem you think it causes. I'm just sayin' But for now I feel a little vindicated. :laugh:
Real programmers use butterflies
-
You know, I'd be open to changing my bracing style if I ever ran into the problem you think it causes. I'm just sayin' But for now I feel a little vindicated. :laugh:
Real programmers use butterflies
To be fair, I just wanted to get it over with and didn't really look where I was typing. Anyway, me nagging about your bracing style hasn't been about your bracing style for a long time, it's just something I do now, it's who I've become :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript