I can't help it...
"Then it becomes very difficult to remember all the things done on the way which will affect the end result in the first calling function. "
Uh, who cares what it does 4 layers down? The whole point of breaking things up into smaller functions is SPECIFICALLY to avoid the need to keep 5,000 lines of code in your head at once. Small functions inherently allow the developer to focus their thoughts on that small piece of code.
NOW, each function it calls needs to be intuitively obvious. I prefer writing ZERO comments in my code. Its much easier to write self commenting code. And in practice and based on feedback from several other developers, it is a more universal language.
Example (albeit longwinded, it is an extreme example)
(kind of non code specific)
Code: Select all
Funciton PerformSummationOnTextualData( aTextFileWithData ): Double
{
Duble Summation = 0;
DataString String = nil;
OpenTextFileWIthData( aTextFileWithData );
CheckIntegrityofData();
ReadDataStringFromFile( aTextFileWithData, DataString );
while( DataString <> nil )
{
AddDataToSummation( Summation );
ReadDataStringFromFile( aTextFileWithData, DataString );
}
return Summation;
}
If you get a file open error, which part of this that is not working should be obvious. If the numbers are not adding up right, then you might have issues with your summation function. If you are not reading in all data, then the read string function might be the place to look.
The point is this, if you want the specifics on how each segment works, comments or no, a good programmer will want to look at the function anyways. So just make the code itself readable and properly named.
How should it be named? Well, go through code of your OWN that is 3+ months old and you will learn. It is simply a matter of time and experience and bumping into your own code months down the road.
As far as efficiencies of calling gunctions within functions and compiler directives such as loncall or shortcall and blah blah blah... forget about it. Compilers already break your code up and re-do it in the most efficient manner anyways (well, mostly). Your code is just a basis for a good compiler to work off of. It is nowhere near the actual final code in the exe.