+1 for everything said.
Just a couple thoughts for the future.
Commentary
I know excess commentary is useful, especially for a beginner.
As you move forward, though, you should look to
reducing your commentary.
C++ code comes in two parts:
• the
interface (.h and .hpp files)
• the
implementation (.cpp files)
What this means is that for every module (like your "Rationals") you should have
two files open when you are working on it: the header and the implementation.
All the commentary about using the class belongs in the header.
Any commentary in the implementation should be restricted to technical details that no one needs to know in order to use the class.
Don’t repeat yourself.
If you do, you will wind up doing what you did on lines 12 and 27. Oops!
With that in mind, your class declaration (in the header) can be easily made to read like this:
1 2 3 4 5 6 7 8 9 10 11 12 13
|
class Rationals
{
private:
int num;
int denom;
void simplify();
public:
Rationals(); // --> 0/1
Rationals(int number); // --> number/1
Rationals(int numerator, int denominator);
void print(); // Print to standard output as, for example, "0/1"
Rationals operator+(const Rationals &another);
};
|
Notice that things like “simplify” do not need commentary, as the concept of “simplifying a fraction” is well-known and understood; unless it is doing something
different (which it shouldn’t be), then no explanation is necessary for anyone who has passed 5
th grade.
Thereafter, the only commentary in the implementation should be stuff that you don’t need to know to use the class. For example,
dhayden’s version of simplify() has nice, useful commentary inside the function
to explain what the code is doing. Line 48 can totally disappear.
Mind you, this is different than a = b; // set a equal to b
. Remember, commentary is not meant to repeat information that can be obtained just by glancing at the code. It is to explain, in general terms, why the code is doing what it does, and any non-obvious details. dhayden did this with his comment: it summarized a weird collection of negations to make things obvious.
Names Of Things
What you name things makes a huge difference in understanding. Your code is simple enough that there is no difficulty in understanding everything, but it can still be improved.
So far, you have used
three different ways to refer to the components of a fraction:
• num / denom
• top / bottom
• a / b
They all work, but you should choose
one and
stick with it. Consistency matters.
Rationals(int num, int denom);
Rationals(int num, int denom): num(num), denom(denom) {}
Likewise, the word “Rational
s” is plural, implying
multiple rational numbers. But the class is for a
single rational number. The fix is easy:
class Rational
Note the lack of an
s
: this is a single rational number!
I am aware that you may not have control over the name of your class when doing homework. Just keep stuff like this in mind when naming things.
Readability
Your code is already very clean. But as you have observed, there is more to readability than just clean code. The way you present it makes a difference.
tl;dr:
• Don’t repeat yourself
• Be consistent
• Information for users → header file
• Information about the implementation → with the code in the .cpp file
Hope this helps. :O)