Taking huge "leaps of faith" while coding
-
If I may jump into your very interesting discussion with a small observation drawn from decades of practice: "Design top-down; implement bottom-up" To take your example:
DrawRectangle(Point startPoint, int width, int height)
What happens if width or heights are negative numbers? What if they are 0? Do I throw an exception? Should I just ignore it? Either you design exhaustively and are prepared to contemplate all possibilities or you start from the other end and discover all the obscure conditions and corner cases as you build up your project. I could keep hammering down this point discussing integration of external components and other such things, but assuming you accept my suggestion and start building from bottom up, it could be quite a long time before you have something that you can start debugging. You can shorten this time (I call it the "valley of despair") by building unit tests. These will give you some confidence that at least individual bricks more or less work. If your initial top-down design was not completely crap, the bricks you made will fit (approximately) in your project. It is now the time of integration tests and functional tests to shake up your edifice and smooth any rough corners that remain. Throughout this process document, document, document. If you need the DrawRectangle function in another project, it's much easier if you know all the little quirks it has without having to read the code.
Mircea
Let's talk about Draw Rectangle, because I actually solved that problem in the wild.
draw::rectangle(destination,rect16(0,0,99,99),color_t::purple);
The draw class acts on "draw destinations" which are like canvases. The first argument is always this target. In this case
destinationabove The second argument is always the location(s) of the object to be drawn - in this case, a rectangle with unsigned 16 bit coordinates. (my lib uses rect16 for that, or srect16 for signed) gfx/include/gfx_positioning.hpp at master · codewitch-honey-crisis/gfx · GitHub[^] Before I built the drawing operations, I built up the position elements, as shown in that file. Rectangles can be normalized, or denormalized, and have a fundamental orientation in my libraries. For draw::rectangle, the orientation is irrelevant, so rect16(99,99,0,0) would be equivalent to that routine.rect16 newrect = myrect.normalize();
// or
myrect.normalize_inplace();That will ensure the rectangle's dimensions are intelligible to this routine. Some routines honor the rectangle orientation, such as draw::bitmap, which can flip the bitmap on the x and/or y axis. I built this constructively. Or at least, i'd get to the point in the drawing code where I needed, say a rectangle element, and then I went back and designed the positioning elements as exhaustively as I could at the time. I then continued where I left off with my new toolbelt of rects, points, sizes and paths. Doing this I've managed to create a library that has survived several years with hardly any major architectural changes, and very few breaking code changes, none recently. I was careful. I was fastidious. And one thing I did that I don't normally do is I designed for completeness rather than for use cases, primarily because I didn't have all the use cases my end users (including me) would use it for in front of me. So I envisioned a model of completeness and coded to that. Take a look at that positioning code and you'll find I covered pretty much every eventuality. Like I said, I normally don't code that way, but in this case, breaking my rule served me well.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
Let's talk about Draw Rectangle, because I actually solved that problem in the wild.
draw::rectangle(destination,rect16(0,0,99,99),color_t::purple);
The draw class acts on "draw destinations" which are like canvases. The first argument is always this target. In this case
destinationabove The second argument is always the location(s) of the object to be drawn - in this case, a rectangle with unsigned 16 bit coordinates. (my lib uses rect16 for that, or srect16 for signed) gfx/include/gfx_positioning.hpp at master · codewitch-honey-crisis/gfx · GitHub[^] Before I built the drawing operations, I built up the position elements, as shown in that file. Rectangles can be normalized, or denormalized, and have a fundamental orientation in my libraries. For draw::rectangle, the orientation is irrelevant, so rect16(99,99,0,0) would be equivalent to that routine.rect16 newrect = myrect.normalize();
// or
myrect.normalize_inplace();That will ensure the rectangle's dimensions are intelligible to this routine. Some routines honor the rectangle orientation, such as draw::bitmap, which can flip the bitmap on the x and/or y axis. I built this constructively. Or at least, i'd get to the point in the drawing code where I needed, say a rectangle element, and then I went back and designed the positioning elements as exhaustively as I could at the time. I then continued where I left off with my new toolbelt of rects, points, sizes and paths. Doing this I've managed to create a library that has survived several years with hardly any major architectural changes, and very few breaking code changes, none recently. I was careful. I was fastidious. And one thing I did that I don't normally do is I designed for completeness rather than for use cases, primarily because I didn't have all the use cases my end users (including me) would use it for in front of me. So I envisioned a model of completeness and coded to that. Take a look at that positioning code and you'll find I covered pretty much every eventuality. Like I said, I normally don't code that way, but in this case, breaking my rule served me well.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
If I understand you correctly, you followed my mantra: "Design top-down, implement bottom-up".
Mircea
-
If I understand you correctly, you followed my mantra: "Design top-down, implement bottom-up".
Mircea
Indeed.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
If I may jump into your very interesting discussion with a small observation drawn from decades of practice: "Design top-down; implement bottom-up" To take your example:
DrawRectangle(Point startPoint, int width, int height)
What happens if width or heights are negative numbers? What if they are 0? Do I throw an exception? Should I just ignore it? Either you design exhaustively and are prepared to contemplate all possibilities or you start from the other end and discover all the obscure conditions and corner cases as you build up your project. I could keep hammering down this point discussing integration of external components and other such things, but assuming you accept my suggestion and start building from bottom up, it could be quite a long time before you have something that you can start debugging. You can shorten this time (I call it the "valley of despair") by building unit tests. These will give you some confidence that at least individual bricks more or less work. If your initial top-down design was not completely crap, the bricks you made will fit (approximately) in your project. It is now the time of integration tests and functional tests to shake up your edifice and smooth any rough corners that remain. Throughout this process document, document, document. If you need the DrawRectangle function in another project, it's much easier if you know all the little quirks it has without having to read the code.
Mircea
-
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life. So if you've ever been in that situation, I imagine you hate it as much as I do. It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it? Some kind of process management? Some clever form of testing I'm not familiar with? Tai chi?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I can always plan my coding in minimal incremental steps that allow to use mock data to test results of each step. But I am unsure how possible that would be in your case, after all I never did hardware related stuff.
-
I can always plan my coding in minimal incremental steps that allow to use mock data to test results of each step. But I am unsure how possible that would be in your case, after all I never did hardware related stuff.
I typically do that too, but every once in awhile a solution has too many moving parts that all need to work together before you know if any of it works. A good example was my SVG renderer. Without actually seeing what it was rendering you couldn't easily test it. And for that to happen, a lot of things needed to go on under the covers - you had the parsing, the conversion to internal data structures suitable for rendering, and the actual rasterization process. All to make something visible at all. Otherwise, it's really difficult to figure out what your values should be when they're all based on multiple trig function outputs. Rock, meet hard place. Luckily it doesn't happen all that often, and also the thing that inspired my OP has now been implemented. Finally. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I typically do that too, but every once in awhile a solution has too many moving parts that all need to work together before you know if any of it works. A good example was my SVG renderer. Without actually seeing what it was rendering you couldn't easily test it. And for that to happen, a lot of things needed to go on under the covers - you had the parsing, the conversion to internal data structures suitable for rendering, and the actual rasterization process. All to make something visible at all. Otherwise, it's really difficult to figure out what your values should be when they're all based on multiple trig function outputs. Rock, meet hard place. Luckily it doesn't happen all that often, and also the thing that inspired my OP has now been implemented. Finally. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Yes, I do encounter that too and I go first with smallest possible example - mock expected parsing results and compare actual parsing results, then mock that into expected internal data structure and compare actual results The last step would be a real pain, but still, mock that and compare actual results until they match (or you find out you were bad at mocking that part :laugh: ). Did something like this with ZPL graphics label export. Testing code for text to image is often painful.
-
Yes, I do encounter that too and I go first with smallest possible example - mock expected parsing results and compare actual parsing results, then mock that into expected internal data structure and compare actual results The last step would be a real pain, but still, mock that and compare actual results until they match (or you find out you were bad at mocking that part :laugh: ). Did something like this with ZPL graphics label export. Testing code for text to image is often painful.
I guess maybe part of it is I'm lazy? I can't fathom drilling down that much testing say, that SVG process. Some of it, like testing the parsing code, sure. But testing the data structures is very difficult without working with how they're actually used by the rasterizer engine. It would be very difficult, but not impossible to design the tests. However, is it more work than testing the whole and risking the possibility of a goose chase over the whole mess if it goes sideways? In some cases yes, I think. In this case, I guess if I'm being totally honest with myself, I *chose* not to validate the data structures and rendering process individually - or the parsing code for that matter, but testing that is not a huge deal and I did a little while making it). But it paid off in the end, in any case. Since it worked, it would have been wasted effort to implement those tests, even though knowing that beforehand is impossible. It was certainly a gamble.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life. So if you've ever been in that situation, I imagine you hate it as much as I do. It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it? Some kind of process management? Some clever form of testing I'm not familiar with? Tai chi?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I run(*). (*) Moderate distances, currently 4-5 miles three times a week. Seriously, I have this situation often. My stuff helps operate a 60-100 ft long printing press, so it's expensive and painful to debug. First, I have an emulator for the operational bits that manage the hardware. I can debug at my desk quite a lot. When I have to make an ascent on the mountain like you describe, I tend to walk the code in the debugger and verify things along the way. If I have a complicated new API, I'll write throwaway test drivers that concentrate on just operating the API so that I understand sequences and dependencies, which are often the most poorly-documented. This lets me understand the API with a fixed, easily repeated scenario.
Software Zen:
delete this; -
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life. So if you've ever been in that situation, I imagine you hate it as much as I do. It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it? Some kind of process management? Some clever form of testing I'm not familiar with? Tai chi?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I would believe you while coding you would know what each section is suppose to return. Been there I too get frustrated because I know what I want to happen. To reach that point I realize how many little pieces need to be implemented. Then realize that some parts could be reused for another section that has yet to be written. I try to test groups of code that work together. All trying to reach the goal of a functioning app. Take breaks after 20-30 minutes. Don't go 2-3 hours STR8. Wish you the best. Peace,
-
I guess maybe part of it is I'm lazy? I can't fathom drilling down that much testing say, that SVG process. Some of it, like testing the parsing code, sure. But testing the data structures is very difficult without working with how they're actually used by the rasterizer engine. It would be very difficult, but not impossible to design the tests. However, is it more work than testing the whole and risking the possibility of a goose chase over the whole mess if it goes sideways? In some cases yes, I think. In this case, I guess if I'm being totally honest with myself, I *chose* not to validate the data structures and rendering process individually - or the parsing code for that matter, but testing that is not a huge deal and I did a little while making it). But it paid off in the end, in any case. Since it worked, it would have been wasted effort to implement those tests, even though knowing that beforehand is impossible. It was certainly a gamble.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I am not so lucky with complex code, so I prefer not to gamble. But hey, no risk - no fun :laugh:
-
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life. So if you've ever been in that situation, I imagine you hate it as much as I do. It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it? Some kind of process management? Some clever form of testing I'm not familiar with? Tai chi?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Firstly, experience tells you how to develop systems that are testable. However, when push comes to shove, experience allows you to develop cognitive skills that can cope with lining up 5 or 6 ducks in order to get something working. Just so long as nobody interrupts you while you're juggling china ducks.
-
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life. So if you've ever been in that situation, I imagine you hate it as much as I do. It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it? Some kind of process management? Some clever form of testing I'm not familiar with? Tai chi?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Whenever that happens to me, I sit back and ponder, then realize a better design would have avoided the problem. CQ de W5ALT
Walt Fair, Jr.PhD P. E. Comport Computing Specializing in Technical Engineering Software
-
honey the codewitch wrote:
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it
Rarely, but it's a PITA and I get pretty stressed. Usually for nothing but occasionally it proves to be a can of worms and I have to go back and try to debug the code, which causes more frustration until I get to the point where I post a stupid question here on CP that makes no sense to anyone but me then I get away from it for a while and behold I figure it out.
If you can't find time to do it right the first time, how are you going to find time to do it again? PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com Latest Article: EventAggregator
1:Limit and validate input before attempting to process any further logic. 2:Handle any out of bounds input and/or dependency failures with effective error handling and comprehensive logging to allow forensics to show how and why the error was thrown and the inputs or dependency that caused it. 3:make sure the functionality of the new logic is well documented for allowable inputs, desired outputs, snf dependencies, with stakeholders responsible for the requirements well documented so there is no ambiguity about who wanted what, why, and when. If for whatever reason you can't do all of those in your work, something is very wrong with the overall approach and you are in deep doo-doo. I had to code "add-on" features and funcitonality to 3rd party business critical enterprise apps many times. 1,2, and 3 made it possible to do so with minimal stress because the proposed logic could be matched to what stakeholders agreed it was supposed to do (except for defects I created in the logic of course which is my own fault).
-
I don't have a debugger, so the debug sessions are .. interesting.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
On one Arduino project I did I tested some of my classes by writing a wrapper executable on the PC and using that as the "mock-Arduino" that drove the class so I could debug it, but I'm not sure with your stuff that would work too well.
-
On one Arduino project I did I tested some of my classes by writing a wrapper executable on the PC and using that as the "mock-Arduino" that drove the class so I could debug it, but I'm not sure with your stuff that would work too well.
Winduino: A Tool to Prototype Arduino Projects on the PC[^] :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Winduino: A Tool to Prototype Arduino Projects on the PC[^] :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Neat. I didn't go as far as you did, just some wrappers to source/sink stuff to prove out the logic.
-
Neat. I didn't go as far as you did, just some wrappers to source/sink stuff to prove out the logic.
It started out that way for me too, and then I got a bit obsessive about the project, as happens with me. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
