The problem you are posing is not a problem of coding, conventions or coding practice, rather, a problem of readability and ways text editors shows the code you write. This same problem is apearing also in the post:

http://programmers.stackexchange.com/questions/195989/is-it-ok-to-split-long-functions-and-methods-into-smaller-ones-even-though-they

Splitting a function into sub-functions make sense when implementing a big system with the intent to encapsulate the different functionalities it will be composed of. Nevetheless, sooner or later, you will find yourself with a number of big functions. Some of them are unreadeable and difficult to maintaint wether you keep them as single long functions or split them is smaller functions. This is particularly true for the functions where the operations you do, are not necessary in any other place of your system. Lets pickup one of such a long function and consider it in a broader view.

Pro:

• Once you read it, you have a complete idea on all the oprations the function does (you can read it as a book);
• If you want to debug it, you can execute it step by step without any jump to any other file/part of the file;
• You have the freedom to access/use any variable declared at any stage of the function;
• The algorithm the function implements its fully contained in the function (encapsulated);

Contra:

• It takes many pages of your screen;
• It takes long to read it;
• It is not easy to memorize all the different steps;

Now lets imagine to split the long function into several sub-functions and look at them with a broader prospective.

Pro:

• Except the leave-functions, each function describes with words (names of sub-functions) the different steps done;
• It takes very short time to read each single function/sub-function;
• It is clear what parameters and variables are affected at each sub-function (separation of concerns);

Contra:

• It is easy to imagine what a function like "sin()" does, but not as easy to imagine what our sub-functions do;
• The algorithm is now disapeared, it is now distributed in may sub-functions (no overview);
• When debugging it step by step, it is easy to forget the deepness level function call you are coming from (jumping here and there in your project files);
• You can easily loose context when reading the different sub-functions;

Both solutions have pro and contra. The actual best solution would be having editors which allow to expand, inline and for the full depth, each function call into its content. Which would make, splitting functions in sub functions the only best solution.

The problem you are posing is not a problem of coding, conventions or coding practice, rather, a problem of readability and ways text editors shows the code you write. This same problem is apearing also in the post:

Is it OK to split long functions and methods into smaller ones even though they won't be called by anything else?

Splitting a function into sub-functions make sense when implementing a big system with the intent to encapsulate the different functionalities it will be composed of. Nevetheless, sooner or later, you will find yourself with a number of big functions. Some of them are unreadeable and difficult to maintaint wether you keep them as single long functions or split them is smaller functions. This is particularly true for the functions where the operations you do, are not necessary in any other place of your system. Lets pickup one of such a long function and consider it in a broader view.

Pro:

• Once you read it, you have a complete idea on all the oprations the function does (you can read it as a book);
• If you want to debug it, you can execute it step by step without any jump to any other file/part of the file;
• You have the freedom to access/use any variable declared at any stage of the function;
• The algorithm the function implements its fully contained in the function (encapsulated);

Contra:

• It takes many pages of your screen;
• It takes long to read it;
• It is not easy to memorize all the different steps;

Now lets imagine to split the long function into several sub-functions and look at them with a broader prospective.

Pro:

• Except the leave-functions, each function describes with words (names of sub-functions) the different steps done;
• It takes very short time to read each single function/sub-function;
• It is clear what parameters and variables are affected at each sub-function (separation of concerns);

Contra:

• It is easy to imagine what a function like "sin()" does, but not as easy to imagine what our sub-functions do;
• The algorithm is now disapeared, it is now distributed in may sub-functions (no overview);
• When debugging it step by step, it is easy to forget the deepness level function call you are coming from (jumping here and there in your project files);
• You can easily loose context when reading the different sub-functions;

Both solutions have pro and contra. The actual best solution would be having editors which allow to expand, inline and for the full depth, each function call into its content. Which would make, splitting functions in sub functions the only best solution.