this post was submitted on 03 Sep 2026
34 points (92.5% liked)
Programming
28403 readers
264 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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.
That sounds like the evil mirror of my one former professor who limited function length to 8 lines of code in assignments
I never trust a programmer who has any "strict rules".
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