• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 236
  • Last Modified:

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?
3 Solutions
käµfm³d 👽Commented:
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?
Julian HansenCommented:
Simple break by function not by size.

Functions are there primarily to do some work usually work that might need to be repeated.

Functions can also be used to break the code up into logical sections to make the code more readable and more manageable.

The rule is keep like functionality together - your manager may have a point but it comes down to how you do it - the overhead of calling a function should not be a consideration - in general it is negligable.

Big chunks of code are hard to read and keep track of - so breaking it up into


Might logically all be part of the same operation but by breaking it up into steps (inside functions) the reader is easily able to ascertain what code belongs to which function and can therefore get to grips with the code quicker.

As with any tool / methodology / paradigm - it is how it is applied that is important.
Subrat (C++ windows/Linux)Software EngineerCommented:
>>even if sees he 50 or more lines he hates it and ask to split it into two or more functions.
It's not mandatory. But if you are writing same block of code some where else in other place/in function, then it's better to keep that inside a function and do call that function whenever needed.

More over your code will be more readable and maintainable if you are using functions.
Use Function to perform a particular task. And to perform group of task you can make call to necessary functions.
Say I need to implement LogOnToGmail()....Calling this function will open browser and automatically login to gmail.

I may prefer
Each of these functions may call other User defined functions...

This is just an idea that I can say!
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

perlperlAuthor Commented:
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.
Julian HansenCommented:
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.
yes, a self restriction of 50 lines per function can help to get a better design. it would prevent from a few of the main design errors, such as using long if-else-if cascades or nested loops. also it should prevent from duplicating longer code sequences and put the code into a function instead.

it doesn't help from another annoying custom like creating a wrapper function calling another wrapper calling another wrapper ... where each function has only one call. or from using global variables where it wasn't necessary or where a singleton (class) object would be the better design. in any case the 50 lines only should you remind that c++ member functions are either properties of an object or steps of execution. for both, you should care that the design has the focus on the main functionality of the needed level and do the detail work in separate functions.

if performance in the nanoseconds area (not measurable for normal programs) is an issue you can make the functions inline (what would be done by good compilers anyhow). or you use a compiler like the Intel c++ compiler which is said to produce code that is a multiple times faster than normal c++ code. however, it has a high price and the executables would not run (properly) at different hardware.

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.

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now