Yes and no. I find short lambdas easier to read. In lisp you have flet, labels, which allows you to name the elements without introducing external functions.
But of course there are cases where the proposed is useful, e.g. for reuse. I can imagine
applyModifierscould be called in more than one place.Anyway, upvoted because it’s an interesting discussion.
I once, many years ago, worked with a programmer who had a strict rule of not introducing any functions unless the block of code was used at least twice.
Every code base they were the main developer on had source files thousands of lines long with if-statements nested to the 9 levels of hell.
We worked mostly in Perl and Deplhi (Pascal). Reading old code was… interesting. It’s wild when your Perl code is more readable than your Pascal.
I’m happy to say I don’t work with them anymore.
So yeah, break things into functions and name your functions and variables sensibly. Your future self will thank you.
I never trust a programmer who has any “strict rules”.
That sounds like the evil mirror of my one former professor who limited function length to 8 lines of code in assignments
Not making functions unnecessarily is a pretty good rule, but like all rules, it can be ignored for good reasons. Strict adherence to any rule (in programming) is fraught.
Yeah there is some overhead with a function call, but for our use case (low-traffic web and batch jobs) that wasn’t a big deal. And the rest of their code wasn’t exactly tuned for performance either.
Yes, it was the dogmatic approach to it that was the most infuriating.
Yeah there is some overhead with a function call
Not necessarily, since compilers can inline functions as an optimization
Yes, but Perl 5 did not, except for constant functions. Either way, the effect of that was outweighed by several orders of magnitude by the rest of the WTFs in that code.
All that is a bit beside the point I was trying to make, which is write readable code.
Use your own judgement to find a balance between readability and performance. Use profiling tools to find hotspots where performance is a concern and optimize those. Base your practices on evidence not dogma.
Yup just wanted any newbie types scrolling by to not take that as something that is always true, when writing in most compiled languages it is completely up to the compiler.
I can agree with this, mostly. More recently I’ve been trying to become aware of how much knowledge I’m encapsulating within functions, preferring to hide more stuff in them rather than less, and avoiding shallow functions that just, say, wrap a single line just passing along the arguments. I’ve realized over my career that I’d prefer a longer function that I can just read straight through rather than jump between a bunch of shallow functions trying to piece things together.
Honestly, as long as the functions you are creating are pure and reasonably named, I think its pretty much always a win to wrap any coherent operation up into one.
I mean, that’s a reasonable rule of thumb, but there are definitely limits. It seems that they chose to follow the rule regardless of practicality. Helper functions are nice and good. Almost as good as recursion. Recursive helper functions are nicer and gooder
Yeah, there are some examples out of “clean code” that are absolutely ludicrous on the “tons of tiny functions” end.
I’d also say letting map/filter and other common operations show is entirely fine.
I think the at least twice thing comes from Avoiding Hasty Abstractions (AHA) rule / convention, as a counter / caveat to DRY
you can also just add comments i guess. but yeah, both would work fine.
