Return to Question

1. Yes, exctracted functions are private, but they visible for all members of this class; let’s imagine a class with a function with complex calculations (find intersections of geometrical primitives); I will extract 50 sub-functions and this will be a mess of functions visible in this class.
2. I am not concerned with performance overhead, but I am concerned with source file size. Instead of 150 lines of large function I will have 400 lines of 50 small functions to be written, documented, learned, remembered and read by others. Well, I exaggerating to explain the idea, but I had the cases.
3. Most of these functions don’t have any meaning outside of the large function context, so it is hard to name and document them, since function find_left_upper_corner_of_frastum_and_horizon_intersection() is crazy and preconditions like “array must be sorted, all characters must be lowercase”, etc. could be deadly and function without them could be dangerous if used by another developer in support.
4. People always say, “you are a human, find the balance!”, but when it is suggested to extract 3 lines of code to a separate function, making it 7 lines of code, where is a balance? What about Occam’s razor? To put in a nutshell, I love functional decomposition, I see that most of good software uses it, but until some technique invented better than “just nest a ‘utils’ or ‘details’ structure or namespace”, I will be in twenty minds about over-extracting functions. Please help me, if you have good recommendation here.

1. Yes, extracted functions are private, but they visible for all members of this class; let’s imagine a class with a function with complex calculations (find intersections of geometrical primitives); I will extract 50 sub-functions and this will be a mess of functions visible in this class.
2. I am not concerned with performance overhead, but I am concerned with source file size. Instead of 150 lines of large function I will have 400 lines of 50 small functions to be written, documented, learned, remembered and read by others. Well, I exaggerating to explain the idea, but I had the cases.
3. Most of these functions don’t have any meaning outside of the large function context, so it is hard to name and document them, since function find_left_upper_corner_of_frastum_and_horizon_intersection() is crazy and preconditions like “array must be sorted, all characters must be lowercase”, etc. could be deadly and function without them could be dangerous if used by another developer in support.
4. People always say, “you are a human, find the balance!”, but when it is suggested to extract 3 lines of code to a separate function, making it 7 lines of code, where is a balance? What about Occam’s razor? To put in a nutshell, I love functional decomposition, I see that most of good software uses it, but until some technique invented better than “just nest a ‘utils’ or ‘details’ structure or namespace”, I will be in twenty minds about over-extracting functions. Please help me, if you have good recommendation here.

With this I am still eager to hear your feedback on questions posted in form of comments to Natural language text fast tokenizer (Rev.3).

With this I am still eager to hear your feedback on questions posted in form of comments to Natural language text fast tokenizer (Rev.3). Here is the summary of these questions, so the link above is just for the context.

Function extraction is one of the hardest problems for me and I am very interested in your help here. Here is my reasoning.

1. Yes, exctracted functions are private, but they visible for all members of this class; let’s imagine a class with a function with complex calculations (find intersections of geometrical primitives); I will extract 50 sub-functions and this will be a mess of functions visible in this class.
2. I am not concerned with performance overhead, but I am concerned with source file size. Instead of 150 lines of large function I will have 400 lines of 50 small functions to be written, documented, learned, remembered and read by others. Well, I exaggerating to explain the idea, but I had the cases.
3. Most of these functions don’t have any meaning outside of the large function context, so it is hard to name and document them, since function find_left_upper_corner_of_frastum_and_horizon_intersection() is crazy and preconditions like “array must be sorted, all characters must be lowercase”, etc. could be deadly and function without them could be dangerous if used by another developer in support.
4. People always say, “you are a human, find the balance!”, but when it is suggested to extract 3 lines of code to a separate function, making it 7 lines of code, where is a balance? What about Occam’s razor? To put in a nutshell, I love functional decomposition, I see that most of good software uses it, but until some technique invented better than “just nest a ‘utils’ or ‘details’ structure or namespace”, I will be in twenty minds about over-extracting functions. Please help me, if you have good recommendation here.

Again, this list is short, just issues “on a surface”.

Here is the updated code for the code review; could you please take a look and suggest further ways to improve or confirm that this is ready to go code?