6 ms·
“Ideally under 70 lines” is not “always under 70 lines under pain of death”. It’s a guideline. There are exceptions. Most randomly-selected 100-line functions
by stouset 11mo ago
“Ideally under 70 lines” is not “always under 70 lines under pain of death”.
It’s a guideline. There are exceptions. Most randomly-selected 100-line functions in the wild would probably benefit from being four 25-line functions. But many wouldn’t. Maturity is knowing when the guideline doesn’t apply. But if you find yourself constantly writing a lot of long functions, it’s a good signal something is off.
Sure, language matters. Domain matters too. Pick a number other than 70 if you’re using a verbose language like golang. Pick a number less if you’re using something more concise.
People need to stop freaking out over reasonable, well-intentioned guidelines as if they’re inviolable rules. 150 is way too many for almost all functions in mainstream languages. 20 would need to be violated way too often to be a useful rule of thumb.
- Kwpolska 11mo agoAs with all guidelines, some people will turn it into a hard rule, and build a linter to enforce it. Then they will split long functions into shorter ones, but with a lot of arguments. And then their other linter that limits argument count will kick in.
- n4r9 11mo agoSounds like an opportunity to guide that person.
- wouldbecouldbe 11mo agoGood luck Arguing with stubborn devs who know it all
- n4r9 11mo agoAt this point we're suggesting that we shouldn't implement some guidelines because there exist developers who will naively take it to extremes and stubbornly refuse to budge. Those developers will be an issue practically independent of the guidelines themselves.
- stouset 11mo agoYou mean like the stubborn devs who argue we shouldn’t have guidelines because one in a thousand times it doesn’t apply?
- VBprogrammer 11mo agoAnd someone else will use the idea that this is a misconception to justify putting hundreds of lines in one function. Some junior dev will then come along with his specific user story and, not wanting to tear the whole thing up, will insert his couple of lines. Repeat over a 10 year lifecycle and it becomes completely unmanageable. I remember trying to tease apart hundreds of lines of functions in a language which didn't have the IDE support we have these days. It was always painful. Even the most script like functions I've ever worked with benefit from comments like: # Validate that the payment was successfully sent. These subheadings can just as easily become functions. If you limit the context in each function it becomes a genuine improvement.
- Hackbraten 11mo ago> and build a linter to enforce it. That’s why linters allow you to suppress specific rules for a single statement (and ideally let you write a short comment that explains why you chose to suppress it.)
- lenkite 11mo agoWhen I was a junior developer working in the outsourcing industry, I regularly had to maintain projects where the entire codebase was in a few major functions. It was a stressful nightmare to debug - such projects destroyed my health. No feature could be developed without extensive forking of the codebase and prototyping to see what works and what doesn't. After several such bad experiences, I religiously incorporated my personal guideline of functions never crossing the upper limit of 100 lines - with some 1 in 10k exceptions like in the parsing domain or state machine dispatch. Short functions also heavily aid in unit testing. The only folks who believe in big functions are developers who haven't been exposed to large quantities of other people's shoddy code as a significant fraction of their working career. Once you have been through several such nightmares, you will worship small functions.
- eviks 11mo ago> It’s a guideline ... Pick a number It's using a parameter of secondary importance as a primary, so it's wrong with any number. The comment even has a helpful analogy to LOCs. People need to stop freaking out over reasonable, well-intentioned criticism of guidelines as if they were arguing something else like misundertstanding of that strictness of rules.
- stouset 11mo agoUntil we have an absolute metric to use for measuring comprehensibility, composability, and number of high-level concepts addressed by some unit of code, highly-correlated secondary metrics will have to suffice.
- eviks 11mo agoUntil then you don't have anything to "highly" correlate, so you can continue to guide people towards substance instead of questionable metrics
- stouset 11mo agoI would love for you to show me a high-quality code base where even 5% of functions exceed 70 lines. I for sure haven’t seen one. Most of the best, easiest to work on, and stablest projects I’ve worked in my 25-year career have had the overwhelming majority under 30 LOC, and maybe 1% over 70 LOC. As with all smells, yes, they are simply correlated symptoms of deeper issues and not necessarily proof positive. But they are correlated. Pretending they aren’t is nonsense. And yes, arbitrarily chopping things up to quiet a linter doesn’t necessarily solve the problem, much in the same way dumping perfume onto rotten eggs doesn’t fix the underlying issue. It’s a fast and easy warning to alert you to potential issues, but at the end of the day it’s still up to developers to exercise good judgment and development practice.
- eviks 11mo agoI don't understand what you expect here - you're treating these metrics as a sure undeniable sign of quality, so by definition the examples won't be high quality. So of course you "for sure haven’t seen one", what kind of circular logic is that? > Pretending they aren’t But you're the one doing the pretending, making up high correlation with nothing to correlate, and coming to circular conclusions (if you define it as smell, then yes, you aren't taking about roses)