perlperl
asked on
programming stye in C++
I am looking for an opinion about C++ programming style.
I always argue with my manager a lot ;) my manager hates writing a C++ method that has many lines of code where he needs to scroll the screen **which i completely agree** but not everytime.
but even if sees he 50 or more lines he hates it and ask to split it into two or more functions.
well by doing this the runtime has to run more instructions to jump to functions and others...and this can hamper the performance.
I know there is no hard set limit but where do we draw a line to split a function into two or more?
I always argue with my manager a lot ;) my manager hates writing a C++ method that has many lines of code where he needs to scroll the screen **which i completely agree** but not everytime.
but even if sees he 50 or more lines he hates it and ask to split it into two or more functions.
well by doing this the runtime has to run more instructions to jump to functions and others...and this can hamper the performance.
I know there is no hard set limit but where do we draw a line to split a function into two or more?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
thanks for your comments.
sometimes, splitting a 100 line function into 3 or 4 functions and none of them are re-used or called by other. so just for the sake of readability, is it worth to split as this involves lot of instruction execution during runt time, specially if the function is called repeatedly.
i know there is no definite answer and specially in today's hardware where things run at lightning speed.
sometimes, splitting a 100 line function into 3 or 4 functions and none of them are re-used or called by other. so just for the sake of readability, is it worth to split as this involves lot of instruction execution during runt time, specially if the function is called repeatedly.
i know there is no definite answer and specially in today's hardware where things run at lightning speed.
Depends on the circumstances but yes it can make sense to logically split the code to make it more readable and more manageable.
As mentioned before the overhead for calling the function in 99.9% of situations is negligable and should not be a reason not to use this methodology.
If you are running embedded code with limited resources and execution time is so important that you have to squeeze every ounce of it out of the CPU then you might need to worry about the overhead of calling a function - but for the most part it is so small as to not matter.
As mentioned before the overhead for calling the function in 99.9% of situations is negligable and should not be a reason not to use this methodology.
If you are running embedded code with limited resources and execution time is so important that you have to squeeze every ounce of it out of the CPU then you might need to worry about the overhead of calling a function - but for the most part it is so small as to not matter.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Fast computer hardware is cheap.
Programmers are expensive.
So spending a little bit of time up front to make the code more maintainable can pay huge dividends in the future.
Programmers are expensive.
So spending a little bit of time up front to make the code more maintainable can pay huge dividends in the future.