3 ms·
> Would testing it be easier if it were broken out further? In my experience, you get the most effective use of your time by testing at interface boundaries.
by war1025 6y ago
> Would testing it be easier if it were broken out further?
In my experience, you get the most effective use of your time by testing at interface boundaries.
How the code is structured inside of those doesn't terribly matter in most cases.
That said, you are almost always better off structuring a method as a linear set of steps rather than trying to turn it into some sort of "choose your own adventure" journey.
Basically a typical method of the sort I'm thinking of would be something like:
#{ Check early out conditions
...
#}
#{ Prepare the values
...
#}
#{ Perform I/O operation
...
#}
#{ Clean up / build return value
...
#}
You could break that out into four or five methods, but most likely the contents are going to be a bit of filler and then calling into some other library.
Easier to keep everything consolidated and avoid the spaghetti.
- t-writescode 6y agoThis method already looks like it’s been reasonably shrunk to a single unit, unless “prepare values” is a lot of business logic; and, you’re already past all the major conditional checking. Fair enough.
- wulouis0511 6y agoNeat idea, but I'd like to know how do you deal with nested block.
- war1025 6y agoUsually I will just add the same sort of thing at nested levels. Thinking on it more, the purpose of the `#{` `#}` is to denote "This comment is relevant for this section of code"
- joshuamorton 6y agoIf each section is only a few lines, you've doubled your function length without giving any context relevant to someone who has written code before. If those are long/complex enough that you need to keep track of the sections individually, yeah break them out! Like, what insight does "perform io operation" provide beyond what f.write() already gives?
- war1025 6y ago> what insight does "perform io operation" provide beyond what f.write() already gives? Often maybe it won't give any insight, in which case it gets left out. Basically, the general idea is that I am denoting and grouping chunks of code together sort of like section headers to form an outline of what is happening. A random example from a file I was working on recently: #{ Attempt to handle the case where Redis loses our access token # for some reason ... #}