5 ms·

> LOC is often a rough approximation for complexity. I would argue that the word you are looking for is "containment". Is there any real difference between ca

by bsder 1y ago

> LOC is often a rough approximation for complexity. I would argue that the word you are looking for is "containment". Is there any real difference between calling a function and creating a "const varname = { -> insert lots of computation <-; break retval;}" inline? If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom. It also ossifies the interface if you have the function as you have to rearrange the function signature to pass in/out new things. Premature optimization ... mumble ... mumble. Even Carmack mentioned this almost 20 years ago: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Given that we've shrugged off "object-itis" which really demands small functions and given modern IDEs and languages, that kind of inline-style seems a lot more useful than it used to be.

RHSeeger 1y ago
> If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom. I feel exactly the opposite. By moving "self contained" code out of a method, and replacing it with a call, you make it easier to see what the calling location is doing. Ie, you can have a method that says very clearly and concisely what it does... vs making the reader scan through dozens or hundreds of lines of code to understand it all. Chapter 12 of Kent Beck's book Tidy First? is about exactly this.
- bsder 1y ago
  Do not cite Kent Beck as a software authority. Consider this your semi-regular reminder that Kent Beck is part of the posse (along with Ron Jeffries and Martin Fowler) responsible for the software disaster that was the "Chrysler Comprehensive Compensation System". They were also proponents of Smalltalk--which leads to object-itis and the concomitant tiny functions. As for your "function documentation", the primary difference between that assignment and a function is solely ossified arguments. And ossified function arguments is something that I would put under "premature abstraction". At some point you can pull that out into a separate function. But you should have something that causes you to do that rather than it being a default.
  - RHSeeger 1y ago
    > Do not cite Kent Beck as a software authority. I didn't. Rather, I stated my opinion on the subject and then noted that there is a book that discusses the same (so clearly I'm not the only one that thinks this). > As for your "function documentation", the primary difference between that assignment and a function is solely ossified arguments. No, it's not. It's that the code being moved to a function allows the original location to be cleaner and more obvious.
saghm 1y ago
I find out useful to split things up sometimes to reduce the number of things in scope at a given time. I've found that this both makes it easier for me to reason about, and anecdotally over the years it seems to correlate with my coworkers finding it easier to review as well, although I suppose it's possible that there's a bit of selection bias in terms of teams being more likely to hire people (and individuals to join teams) with similar mindsets.
shakadak 1y ago
> If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom. I do the computation in my head each time I read it. If it is a function I can cache its behavior more easily compared to a well defined block of code. Even if it's never used anywhere else, it's read multiple time, by multiple people. Obviously, it has to make sense from a domain logic perspective, and not be done for the sake of reducing lines of code, but I have yet to see a function/module/file that is justified in being gigantic when approaching it with domain logic reasoning instead of code execution reasoning.
Sohcahtoa82 1y ago
An example I'm dealing with right now... At my job, we're not a SaaS. Our software is distributed as cloud images that customers run in their own environments. I need to run regular vulnerability scans on built images. So, I need to do several things: - Stand up EC2 instances with our image - Run our software setup - Start the scans - Wait for the scans to complete - Destroy all the instances - Download the scan reports - Upload the reports to S3 - Create Jira tickets based on findings Now, I COULD easily write it all as one big function. But I tend to prefer to have one "main" function that calls each step as its own function. When looking at the main function, I can much more easily tell what the program is going to do and in what order. In other words, I much prefer style A from Carmack's post.

by bsder 1y ago

RHSeeger 1y ago

> If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom. I feel exactly the opposite. By moving "self contained" code out of a method, and replacing it with a call, you make it easier to see what the calling location is doing. Ie, you can have a method that says very clearly and concisely what it does... vs making the reader scan through dozens or hundreds of lines of code to understand it all. Chapter 12 of Kent Beck's book Tidy First? is about exactly this.

bsder 1y ago
Do not cite Kent Beck as a software authority. Consider this your semi-regular reminder that Kent Beck is part of the posse (along with Ron Jeffries and Martin Fowler) responsible for the software disaster that was the "Chrysler Comprehensive Compensation System". They were also proponents of Smalltalk--which leads to object-itis and the concomitant tiny functions. As for your "function documentation", the primary difference between that assignment and a function is solely ossified arguments. And ossified function arguments is something that I would put under "premature abstraction". At some point you can pull that out into a separate function. But you should have something that causes you to do that rather than it being a default.
- RHSeeger 1y ago
  > Do not cite Kent Beck as a software authority. I didn't. Rather, I stated my opinion on the subject and then noted that there is a book that discusses the same (so clearly I'm not the only one that thinks this). > As for your "function documentation", the primary difference between that assignment and a function is solely ossified arguments. No, it's not. It's that the code being moved to a function allows the original location to be cleaner and more obvious.

saghm 1y ago

I find out useful to split things up sometimes to reduce the number of things in scope at a given time. I've found that this both makes it easier for me to reason about, and anecdotally over the years it seems to correlate with my coworkers finding it easier to review as well, although I suppose it's possible that there's a bit of selection bias in terms of teams being more likely to hire people (and individuals to join teams) with similar mindsets.

shakadak 1y ago

> If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom. I do the computation in my head each time I read it. If it is a function I can cache its behavior more easily compared to a well defined block of code. Even if it's never used anywhere else, it's read multiple time, by multiple people. Obviously, it has to make sense from a domain logic perspective, and not be done for the sake of reducing lines of code, but I have yet to see a function/module/file that is justified in being gigantic when approaching it with domain logic reasoning instead of code execution reasoning.

Sohcahtoa82 1y ago

An example I'm dealing with right now... At my job, we're not a SaaS. Our software is distributed as cloud images that customers run in their own environments. I need to run regular vulnerability scans on built images. So, I need to do several things: - Stand up EC2 instances with our image - Run our software setup - Start the scans - Wait for the scans to complete - Destroy all the instances - Download the scan reports - Upload the reports to S3 - Create Jira tickets based on findings Now, I COULD easily write it all as one big function. But I tend to prefer to have one "main" function that calls each step as its own function. When looking at the main function, I can much more easily tell what the program is going to do and in what order. In other words, I much prefer style A from Carmack's post.