Straight forward program vs void functions
Is it better to write a code (approx 200lines) in one go or in like 4-5 void functions? Why? In what situation would it be the opposite?
If you are talking about writing a great big function (like main()) that does everything versus breaking it up into smaller functions...
You should always take the time to carefully craft a correct solution -- and in my (not so humble) opinion, there is never a need for giant functions.
That said, the ability to craft good solutions is an acquired skill. There is nothing wrong with creating something of a playground function to understand the needs of the code better, and then rewriting it to something better organized.
You should always take the time to carefully craft a correct solution -- and in my (not so humble) opinion, there is never a need for giant functions.
That said, the ability to craft good solutions is an acquired skill. There is nothing wrong with creating something of a playground function to understand the needs of the code better, and then rewriting it to something better organized.
| That said, the ability to craft good solutions is an acquired skill. There is nothing wrong with creating something of a playground function to understand the needs of the code better, and then rewriting it to something better organized |
Not to hijack the thread, but this triggered a question of my own. When I have to write a complex class, I usually write my code WITHOUT classes first. Then change it so it works with classes and objects. Is that weird? I just feel its easier to write the code without classes first, as writing a complex class from scratch seems daunting and intricate. Then when I have my entire code written, I simply make the necessary changes to turn it into a class-based program.
Anybody else do this? Is this a bad practice?
Last edited on
Hi,
Consider that you are writing a book: would you write the whole thing with 1 giant chapter? If you did have chapters, would you write them with one paragraph? And the paragraphs with one giant sentence?
Chapters, paragraphs and sentences are a kind of Divide & Conquer approach, and a type of abstraction: this in turn aids understanding. One should do the same for coding. Understanding is important for design, implementation, and later maintenance of the code: you are not the only one reading or working on the code.
Other things to aid understanding include good meaningful function and variable names. The code should ideally read like a story of what is happening. This can make it self documenting, and comments can be used for other things like the expected range of valid values for a variable, say. Here is a comical reply to one of Duoas' topics awhile back :+)
http://www.cplusplus.com/forum/lounge/176684/#msg872881
I have that link bookmarked, and have used it a number of times - credit to Norm Gunderson for writing it :+)
As for how many LOC should be in a function: some give a rough guide of 40 LOC per function, some say even less. As Duoas says, there is some skill in making a good solution. Candidates for code that could go into a function might include the body of loops or if statements, or rather any compound (block) statement. That is: code between braces {} . I like to have switch statement cases call a function. More obviously is code that might otherwise be repeated.
Sometimes it is worth it to put just a few lines into a function. A great example is a swap function: even if it is only called once, it helps understanding.
Good Luck !!
Consider that you are writing a book: would you write the whole thing with 1 giant chapter? If you did have chapters, would you write them with one paragraph? And the paragraphs with one giant sentence?
Chapters, paragraphs and sentences are a kind of Divide & Conquer approach, and a type of abstraction: this in turn aids understanding. One should do the same for coding. Understanding is important for design, implementation, and later maintenance of the code: you are not the only one reading or working on the code.
Other things to aid understanding include good meaningful function and variable names. The code should ideally read like a story of what is happening. This can make it self documenting, and comments can be used for other things like the expected range of valid values for a variable, say. Here is a comical reply to one of Duoas' topics awhile back :+)
http://www.cplusplus.com/forum/lounge/176684/#msg872881
I have that link bookmarked, and have used it a number of times - credit to Norm Gunderson for writing it :+)
As for how many LOC should be in a function: some give a rough guide of 40 LOC per function, some say even less. As Duoas says, there is some skill in making a good solution. Candidates for code that could go into a function might include the body of loops or if statements, or rather any compound (block) statement. That is: code between braces {} . I like to have switch statement cases call a function. More obviously is code that might otherwise be repeated.
Sometimes it is worth it to put just a few lines into a function. A great example is a swap function: even if it is only called once, it helps understanding.
Good Luck !!
Topic archived. No new replies allowed.