Functions Should Be Short And Sweet, But Why?

Re:Functions Should Be Short And Sweet, But Why? by kingrolo on Wednesday January 22, 2014 @04:54AM (#7101738)

I worked on a massive codebase once many years ago (C#/.NET) which had been built by a relatively competent outsourced team. Somewhere along the way some consultant on the UK side of the business had insisted that each function could be no more than 5 lines long. It was horrible to work with - it took so long to find the place you actually needed to make changes, and it seems like they'd just started inventing layer names in order to facilitate it.

So yeah, small functions good, but you can take it to extremes.

[ Parent | on HN ]

Re:Functions Should Be Short And Sweet, But Why? by sigmaml on Wednesday January 22, 2014 @06:14AM (#7101949)

I worked on a similar project; the US consultant insisted that each method should be less than 25 lines. The code involved several decision trees. This rigid limit made the code quite inconvenient to follow and enhance. After much sweat and swearing on both sides, the limit was increased to 40 lines!

[ Parent | on HN ]

Re:Functions Should Be Short And Sweet, But Why? by lostcolony on Wednesday January 22, 2014 @08:35AM (#7102429)

I've run into that.

Compounding that issue, I've run into cases where people pulled out code into functions, realized that in two places the behavior was ~slightly~ different, and they addressed it by adding a variable, 'shouldThing' or something, that serves just as a boolean flag as to which bit(s) of logic you should fire. So now rather than just have to focus on the code that needs changing, I've got to go to an entirely different section/file, and wade through code that doesn't even relate to what I'm trying to fix.

[ Parent | on HN ]