How big should a function be
I have been reading a book called "clean code"
and they seem to be advocating functions should
do only one Tiny microtask and that they should
be really small just a few lines take as few
args as possible Preferably none and preferably
return nothing.
I am working on my first program now and I want
to do everything right. I could follow that advice
it would turn one of my functions into 3 or 4
but
Is this really the best way to write functions?
and they seem to be advocating functions should
do only one Tiny microtask and that they should
be really small just a few lines take as few
args as possible Preferably none and preferably
return nothing.
I am working on my first program now and I want
to do everything right. I could follow that advice
it would turn one of my functions into 3 or 4
but
Is this really the best way to write functions?
Find the way in between too many functions calls also make programs slow due to function call overhead!!
mahinkhan22 is correct, compilers won't always know to inline function calls so ignore that part of your book. Think about the purpose of a function, it's to prevent the need for you to write the same code to perform the same task at multiple points in your program. This is what you should keep in mind when developing a program.
I didn't know that function calls affected runtime speeds. I thought the compiler took care of all of that.
OP: Functions are very good for creating re-usable code, so anything you need to do 2 or more times, put that into a function. If you only do something once, only use a function if you like how that splits up your code for readibility.
Personally, I love functions that return something. That way I can use them in-line. I know people that prefer void functions, passing addresses in and then modifying the label directly, but I much prefer to just output the result so I can use it on the same line as something else.
The best functions are the ones that do something very general and basic with very few inputs.
Try and stay away from static variables for functions that may be called multiple times in your main loop, and avoid doing things like cout that could be done in your main and make for unexpected console messages when you try to reuse code. Also, name your functions with a verb, Like run_scipt() or get_status(). That will help the user to understand the difference between the function and the label.
OP: Functions are very good for creating re-usable code, so anything you need to do 2 or more times, put that into a function. If you only do something once, only use a function if you like how that splits up your code for readibility.
Personally, I love functions that return something. That way I can use them in-line. I know people that prefer void functions, passing addresses in and then modifying the label directly, but I much prefer to just output the result so I can use it on the same line as something else.
The best functions are the ones that do something very general and basic with very few inputs.
Try and stay away from static variables for functions that may be called multiple times in your main loop, and avoid doing things like cout that could be done in your main and make for unexpected console messages when you try to reuse code. Also, name your functions with a verb, Like run_scipt() or get_status(). That will help the user to understand the difference between the function and the label.
One piece of questionable advice doesn't discredit the entire book. If you're worried about it then look up a review of the book online. By the way you haven't given us the title yet.
IMO there's so much other stuff for you to be thinking about that to even approach the subject of run-time optimization this early on is stupid. Don't get me wrong, this topic WILL come up in the future but it's best not to worry about it until you have a solid foundation built.
IMO there's so much other stuff for you to be thinking about that to even approach the subject of run-time optimization this early on is stupid. Don't get me wrong, this topic WILL come up in the future but it's best not to worry about it until you have a solid foundation built.
Oops, sorry you did give us the title in your first post. If the reviews are good then I wouldn't worry about it. I just went and read some of the negative reviews and the author does get blasted a few times for making this suggestion. But that seems to be the only negative thing people have to say about it.
The advice is not necessary a bad advice. Having one big function doing 100 different things can be hard to follow and change. Don't worry about it too much. Just keep it in the back of your head. Yes function calls can affect speed but speed is not often not that important that it makes a difference and modern compilers are quite good optimizing away much of the overhead of function calls.
Tell someone what the function does. If you use the word 'and' then it is too big.
e.g. 'This function calculates the value and prints it out' = bad, does two separate things - split it up
e.g. 'This function calculates the value and prints it out' = bad, does two separate things - split it up
| I didn't know that function calls affected runtime speeds. I thought the compiler took care of all of that. |
It does as long as you make sure time-critical functions can be inlined (when using LTO/WPO, that's not an issue anyway).
| The advice is not necessary a bad advice. |
Not only isn't it bad advice, having small functions that do one particular task (but do it properly) is one of the most important cornerstones of good program design.
| I could follow that advice it would turn one of my functions into 3 or 4 |
You aren't supposed to split up your functions in parts 1-4 if that's what you're asking.
Among the things you want to achieve with having short functions is good code readability and reusability. Moving a sub-task into its own function gives it a name which tells the reader what it does - a bunch of loops and calculations wouldn't have done the same. This is part of writing self-explaining code that does not need a comment every five lines to explain what it does.
If you find a sub-task that you will likely need to perform as part of yet another task, it should have its own function. If you find yourself copy and pasting your own code (with or without minor modifications), you most likely neglected to do that properly. That's the part about reusing code.
Likewise, if you have two tasks X and Y, where you always have to perform Y after having performed X to maintain program integrity (to put it in general terms), they should be merged into a function and you should make sure that you can never do X alone accidentally. A lot of other practices indirectly follow from that, such as RAII.
OP:
In general, I try to code like I write essays.
First thing to do is to decide what your code will do, and what order it will do it in. Then you basically just run down the list of things that you're doing and if you see yourself repeating anything (except in the context of loops), take it out of order, and write it on a separate sheet of paper. Once you have done that, you have your outline.
Now you need a draft. Run through your list and bang out code for everything. Tweak it until it compiles and runs. Boom! Rough draft is finished! During this phase, everything that you took out should be in a different function, but you only need the function once, and you can call it from different points in the program to calculate things.
Now you need to refine and make a final draft. Look through your code and make sure again that you're not repeating anything. If you are, copy that code, and put it into it's own function and go through the rest of the program and replace any further instances of doing the same thing with a procedure call. Then make your code pretty. Optimize what you're doing by trying to bring it down to simpler steps. As you go through this process, you'll find that you're making even more functions.
Usually when I'm finished, none of my functions are less than four lines long, or more than about twenty lines long, and they provide a very specific purpose. For example, I have a code snippet that I wrote that gets plugged into many programs that basically iterates through a deque/vector/list and finds an entry based on certain search parameters, and then returns the iterator to the function that called it. I know this sounds general, but it's that way on purpose. That's so it will work with all of the programs I write, not just the one that I happened to be working on when I designed it.
In general, I try to code like I write essays.
First thing to do is to decide what your code will do, and what order it will do it in. Then you basically just run down the list of things that you're doing and if you see yourself repeating anything (except in the context of loops), take it out of order, and write it on a separate sheet of paper. Once you have done that, you have your outline.
Now you need a draft. Run through your list and bang out code for everything. Tweak it until it compiles and runs. Boom! Rough draft is finished! During this phase, everything that you took out should be in a different function, but you only need the function once, and you can call it from different points in the program to calculate things.
Now you need to refine and make a final draft. Look through your code and make sure again that you're not repeating anything. If you are, copy that code, and put it into it's own function and go through the rest of the program and replace any further instances of doing the same thing with a procedure call. Then make your code pretty. Optimize what you're doing by trying to bring it down to simpler steps. As you go through this process, you'll find that you're making even more functions.
Usually when I'm finished, none of my functions are less than four lines long, or more than about twenty lines long, and they provide a very specific purpose. For example, I have a code snippet that I wrote that gets plugged into many programs that basically iterates through a deque/vector/list and finds an entry based on certain search parameters, and then returns the iterator to the function that called it. I know this sounds general, but it's that way on purpose. That's so it will work with all of the programs I write, not just the one that I happened to be working on when I designed it.
Don't split your code into functions just for the sake of it. Usually a function should perform, well a function. Not an incomplete partial task (there are exceptions).
It is more important to think about breaking your problem down into solvable logical units. Then seek to create a function to provide each of these solutions.
Whenever you perform a whole task with a few pieces of data, you have an opportunity to turn that task into a function. Particularly look for tasks that need repeating over and over and try to make them into a function.
Don't expect to get this right from the beginning. How best to break a program down into logical units is an ongoing learning process.
It is more important to think about breaking your problem down into solvable logical units. Then seek to create a function to provide each of these solutions.
Whenever you perform a whole task with a few pieces of data, you have an opportunity to turn that task into a function. Particularly look for tasks that need repeating over and over and try to make them into a function.
Don't expect to get this right from the beginning. How best to break a program down into logical units is an ongoing learning process.
Topic archived. No new replies allowed.