3 ms·
I generally don't know where in the code to "defend" until I've actually written the algorithm -- I don't start writing during whiteboard coding or coding sessi
by SomeStupidPoint 9y ago
I generally don't know where in the code to "defend" until I've actually written the algorithm -- I don't start writing during whiteboard coding or coding sessions with a solution in mind, I start with the first (okayish) thing to come to mind and iterate from there as I run into problems or edge cases. (Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly.)
So in terms of writing flow, it usually goes something like core work function/code, often as helper functions -> control flow structure -> guarding, edge cases, etc.
This also works well for a conversation: how do we model/solve the core problem? how do we want this to actually execute? what are our constraints, special cases, etc? You're moving from the general (abstract problem) to the specific (guarding bugs in my code).
This has worked out reasonably for me.
- tome 9y ago> Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly Does it? Why?
- SomeStupidPoint 9y agoAn actual example of this concept coming up: I had a question about something with a distance formula, and the choice to either explicitly check the length of the points coming in, which were a list of coordinates, (either to ensure a particular dimension or a matching dimension) or another option to iterate over the components, which has a sane "dimension extension" behavior. It wasn't until I looked up the available floating point math functions that I knew their limits and could decide on how to implement the dimensionality handling. So in that case, my thought process went: Figure out the math -> Figure out how to apply it, eg map to a list of pairs of points (which also constrains math implementation) -> implement guarding on input to match contract