TigerStyle: Coding philosophy focused on safety, performance, dev experience
22 points
1 hour ago
| 5 comments
| tigerstyle.dev
| HN
keyle
8 minutes ago
[-]
I was enjoying what I was reading until the "Limit function length" part which made me jolt out of my chair.

This is a common misconception.

   Limit function length: Keep functions concise, ideally under 70 lines. Shorter functions are easier to understand, test, and debug. They promote single responsibility, where each function does one thing well, leading to a more modular and maintainable codebase.
Say, you have a process that is single threaded and does a lot of stuff that has to happen step by step.

New dev comes in; and starts splitting everything it does in 12 functions, because, _a function, should do one thing!_ Even better, they start putting stuff in various files because the files are getting too long.

Now you have 12 functions, scattered over multiple packages, and the order of things is all confused, you have to debug through to see where it goes. They're used exactly once, and they're only used as part of a long process. You've just increased the cognitive load of dealing with your product by a factor of 12. It's downright malignant.

Code should be split so that state is isolated, and business processes (intellectual property) is also self contained and testable. But don't buy into this "70 lines" rule. It makes no sense. 70 lines of python isn't the same as 70 lines of C, for starters. If code is sequential, and always running in that order and it reads like a long script; that's because it is!

Focus on separating pure code from stateful code, that's the key to large maintainable software! And choose composability over inheritance. These things weren't clear to me the first 10 years, but after 30 years, I've made those conclusions. I hope other old-timers can chime in on this.

The length of functions in terms of line count has absolutely nothing to do with "a more modular and maintainable codebase", as explained in the manifesto.

Just like "I committed 3,000 lines of code yesterday" has nothing to do with productivity. And a red car doesn't go faster.

reply
mjlawson
3 minutes ago
[-]
Zero technical debt certainly is... ambitious. Sure, if we knew _what_ to build the first time around this would be possible. From my experience, the majority of technical debt is sourced from product requirement changes coupled with tight deadlines. I think even the most ardent follower of Tiger Style is going to find this nigh impossible.
reply
baalimago
31 minutes ago
[-]
I would not hire a monk of TigerStyle. We'd get nothing done! This amount of coding perfection is best for hobby projects without deadlines.
reply
stouset
21 minutes ago
[-]
This seems pretty knee-jerk. I do most of this and have delivered a hell of a lot of software in my life. Many projects are still running, unmodified, in production, at companies I’ve long since left.

You can get a surprising amount done when you aren’t spending 90% of your time fighting fires and playing whack-a-mole with bugs.

reply
hansvm
7 minutes ago
[-]
Which parts of it seem objectionable?
reply
andai
18 minutes ago
[-]
reply
userbinator
33 minutes ago
[-]
Limit function length: Keep functions concise, ideally under 70 lines. Shorter functions are easier to understand, test, and debug.

The usual BS... yes, shorter functions are easier to understand by themselves but what matters, especially when debugging, is how the whole system works.

Edit: care to refute? Several decades of experience has shown me what happens. I'm surprised this crap is still being peddled.

reply
puchatek
7 minutes ago
[-]
This one, like some others in this style guide, can also be found in Clean Code. Not sure why you feel the need to call it "BS". Nobody is saying that your 75 line function is bad.

It's a reasonable guideline. Juniors won't do this automagically.

reply
stouset
20 minutes ago
[-]
It’s a lot easier to understand entire systems when they’re composed of small, pure, straightforward parts.
reply
vlovich123
17 minutes ago
[-]
Yeah, you can’t build a building unless you’re certain that every brick, rebar, and cement is all solid and meets a quality bar. Of course you need architectural schematics to make sense of the broader picture, but you need quality control on the pieces being put in place too.
reply
danparsonson
21 minutes ago
[-]
The low level stuff is also important.
reply