Link to home
Start Free TrialLog in
Avatar of perlperl
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?
Avatar of kaufmed
kaufmed
Flag of United States of America image

well by doing this the runtime has to run more instructions to jump to functions and others...and this can hamper the performance.
Are you running on an embedded system, or running calculations that are time and/or memory sensitive? Why would you be concerned with this on today's hardware?
ASKER CERTIFIED SOLUTION
Avatar of Julian Hansen
Julian Hansen
Flag of South Africa image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of perlperl
perlperl

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.
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.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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.