Hacker News Reader

Comment by piokuc | Hacker News Reader

To me, the idea of inlining functions that are otherwise called only once is complete garbage. Yes, you reduce number of functions in your program but the program doesn't get easier to read, test, develop and maintain as the functions that you leave get longer... I stopped watching when I learned that that's presenter's idea of improving the original program. And it has _nothing_ to do with OOP and its flaws, you could as well "improve" this way well written functional programs... It's just wrong. Inlining functions is something your compiler is supposed to do for the programmer, a programmer is better off breaking his problem into small functions instead.

View on HN

I thought it was interesting. I've carried a "no long functions" rule in my head for so long it was really challenging to have that questioned.

I get the logic behind why he likes long functions that have the meat of the program in them. I've hit code bases before that have broken out bits of logic into separate functions that are badly named and defined and I ended up hopping around the program trying to work out wtf is going on.

As long as we keep the subroutines nice and tight and well-named they're an aid to understanding the program: I can guess what `writeTextToFile(text,filename)` does, and I'd rather see that in the main logic routine than 50 lines of the code that writes text to files.

I will carry on writing short functions, but it's good to know that I'm doing that for a reason, having challenged it.

Here's a fairly well reasoned argument to the contrary: http://number-none.com/blow/john_carmack_on_inlined_code.htm...

It boils down to the fact that it's very easy to have unexpected state dependencies/constraints in those smaller functions, that is non-obvious by just reading them. If they're called when those constraints are not met, it is a bug.

That's why one should try to make functions pure as much as possible.

I couldn't agree more. When I read your enormous procedures full of inlined functions, I still have to break it down into discrete, logical chunks in my brain. This is work, and there's a real chance I'll get it wrong. If you do it for me, I'm much more likely to understand your program in the way you intended.

I agree with you completely and I think this cannot be controversial. If we cannot agree that sort(my_list) is better than its inlined function, our profession truly is at square one.

The interesting part of this is that although you kind of know that positions with as little nuance as Brian's have to be wrong (because the world isn't simple), it's still important to think about why you hold your own positions instead of dismissing any challenge to them outright. I think it's good to think about why we use objects and whether we need to do it as much.

What we especially lack in programming is any evidence for our practices. The best we currently have is opinion and experience. That means a lot, but not as much as empirical evidence, and I think we tend to forget that too often.

Reply on news.ycombinator.com