4 ms·

I agree with all of this, except the part where they assume extracting a function is essentially free. Our profession seems to consistently underestimate or ev

by zellyn 3y ago

I agree with all of this, except the part where they assume extracting a function is essentially free. Our profession seems to consistently underestimate or even ignore the complexity of interactions between many little pieces. I would rather work on a module with 10 clearly-written 500-line functions than one with 500 clearly-written 10-line functions. Keeping in my mind the complex and variable interactions of a whole constellation of tiny functions is much harder than grinding my way through understanding a few more complex pieces of code. Have you ever worked in a codebase where the template method pattern was combined with too many levels of inheritance and each subsequent method is implemented at a different level of the hierarchy? Likewise for microservices and lambdas. The organizational complexity of an app atomized into 100 lambdas is mind-boggling, because you have to understand the implicit and emergent orchestration of distributed state as those lambdas transition from one to another. All that said, I definitely like this metric better than most others for the static complexity of a single function.

thanatropism 3y ago
I mean, since we split systems up because the whole can end up being worth more than the sum of its parts, there's definitely a knowledge of the whole to be kept besides knowledge of the parts. You have to budget for this.
AnimalMuppet 3y ago
> I would rather work on a module with 10 clearly-written 500-line functions than one with 500 clearly-written 10-line functions. Keeping in my mind the complex and variable interactions of a whole constellation of tiny functions is much harder than grinding my way through understanding a few more complex pieces of code. Maybe, maybe not. The real question is, how clean are the interfaces? How good are the functions at being abstractions? Write your functions to provide a clean interface to some functionality, not to be a set size. If the interfaces are clean, then it's better to have 10-line functions rather than 500-line ones. Why? Because I can be certain that this 10-line chunk doesn't affect the next 10-line chunk, except in these few, carefully-defined ways. In a 500-line function, I don't have that guarantee. I have to worry about how something 400 lines away affects this line. If I've broken that 500-line function up into 50 10-line function calls with clean interfaces, I can see whether that thing can affect this thing. But only break it up if you can do it cleanly. There's no point sawing a 500-line function up into 50 10-line functions just to have shorter functions. If the function doesn't decompose cleanly, you wind up with interfaces that are a mess, and you wind up with more complexity rather than less, because you added the complexity of the interfaces (and the indirection) to the existing hairball.

by zellyn 3y ago

thanatropism 3y ago

I mean, since we split systems up because the whole can end up being worth more than the sum of its parts, there's definitely a knowledge of the whole to be kept besides knowledge of the parts. You have to budget for this.

AnimalMuppet 3y ago

> I would rather work on a module with 10 clearly-written 500-line functions than one with 500 clearly-written 10-line functions. Keeping in my mind the complex and variable interactions of a whole constellation of tiny functions is much harder than grinding my way through understanding a few more complex pieces of code. Maybe, maybe not. The real question is, how clean are the interfaces? How good are the functions at being abstractions? Write your functions to provide a clean interface to some functionality, not to be a set size. If the interfaces are clean, then it's better to have 10-line functions rather than 500-line ones. Why? Because I can be certain that this 10-line chunk doesn't affect the next 10-line chunk, except in these few, carefully-defined ways. In a 500-line function, I don't have that guarantee. I have to worry about how something 400 lines away affects this line. If I've broken that 500-line function up into 50 10-line function calls with clean interfaces, I can see whether that thing can affect this thing. But only break it up if you can do it cleanly. There's no point sawing a 500-line function up into 50 10-line functions just to have shorter functions. If the function doesn't decompose cleanly, you wind up with interfaces that are a mess, and you wind up with more complexity rather than less, because you added the complexity of the interfaces (and the indirection) to the existing hairball.