Warning: style / reusability notes follow. The above solutions appear to be working and that's great. I just felt compelled to write this post because "good"/reusable function design is something newbies don't grasp right away. So I felt some feedback would be useful.
Design is one of the harder things to grasp. You can learn the syntax and everything, but learning how to effectively apply it and design programs in a way which makes them maintainable is
very tricky. It takes years to really get it.
the function calls another function although you can avoid it. |
Calling functions isn't necessarily something you should avoid. Ideally, functions should be limited to a very specific task and shouldn't step outside that task. Here, I would say just the opposite. I'd say that bb_4ac does "too much" and ends up becoming crippled as a result.
For example, what if the input was coming from a file? You'd have to rewrite the entire function. Or what if a, b, c were calculated from some other forumla? Any situation in which you don't get a,b,c directly from the user renders this entire function worthless.
Also the function name is a little wonky. I guess it's descriptive in the way that
TwoPiR
is descriptive, but
CalcArea
would be more descriptive and easier to remember.
A few design tips:
- have functions focus on a very specific task.
- user I/O should be its own thing. Avoid combining user I/O in a function that does anything else. A function which does calculations on some variables should have those variables passed to it, it should never assume they come from a specific source.
- don't be afraid of calling functions. It's true there's some overhead but it's very small.
- name functions (and classes, and variables, etc) based on what they do, rather than how they work. For example,
CalcQuadraticEquation
tells you exactly what the function does, whereas
bb_4ac
tells you
how it does it.
- the overall logic should be abstracted to where it can simply call a series of functions, rather than be a glob of code. This makes the flow of logic in the program easy to follow, easy to change, and easy to diagnose when problems come up.
A better way to structure this program might have been like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
|
#include <iostream>
using namespace std;
// prototypes
void GetABCFromConsole(double& a,double& b,double& c);
double CalcQuadraticEquation(double a,double b,double c);
void OutputResult(ostream& out,double result);
int main()
{
double a, b, c;
double result;
// the logic in main should be simple. Ideally there's minimal code here
// each function call is a "step" in the overall program flow
// step 1: get the input from the user
GetABCFromConsole(a,b,c);
// step 2: calculate the quadratic equation
result = CalcQuadraticEquation(a,b,c);
// step 3: print it
OutputResult(cout,result);
return 0;
}
// I won't write the function bodies for the above, but you can imagine how they'd look
|
Arguably, 'OutputResult' is small enough so putting it in it's own function might seem like overkill.... but that's a judgement call. Lots of programmers will tell you different things, and their styles will all differ. There's not really any right or wrong way to do it, there's just preference.
Anyway... my $0.02