6
\$\begingroup\$
// January

// This program inputs the # of days in January 1-31

// Brandon Summerlin

// 2/03/2023

    #include <iostream>
    using std::cout; using std::cin; using std::endl;

    int main() {
    //inputs the numbers
    cout << "input the number from 01 to 31: ";
    int number;
    cin >> number;

    const int singles = number % 10;
    const int tens = number / 10;

    cout << "tens: " << tens << endl;
    cout << "singles:" << singles << endl;

    //singles
    }
\$\endgroup\$
3
  • \$\begingroup\$ (realized I forgot to close the ending bracket so I apologize for that one) \$\endgroup\$ Feb 4, 2023 at 0:58
  • \$\begingroup\$ Welcome to the site. I went ahead and added the closing brace when I reformatted. \$\endgroup\$
    – Davislor
    Feb 4, 2023 at 2:08
  • \$\begingroup\$ Your title and the comment mentions January, but the program itself has nothing about January or 31. This is a bit confusing. Did you intend your program to always output the number of days in January (31), or check that the user enters 31, or something else? \$\endgroup\$
    – JiK
    Feb 5, 2023 at 9:39

1 Answer 1

6
\$\begingroup\$

Not a bad start. Since the program logic does what it does very cleanly, the only real tips I have are about formatting.

It’s customary, and a good idea, to indent the body of each of your blocks. In this program, there’s only one. So:

int main() {
    //inputs the numbers
    cout << "input the number from 01 to 31: ";
    int number;
    cin >> number;

    const int singles = number % 10;
    const int tens = number / 10;

    cout << "tens: " << tens << endl;
    cout << "singles:" << singles << endl;

    //singles
}

You should put in comments that are helpful, but avoid saying things that are obvious from the code itself. One thing that can go wrong is when the comment //singles seems to have gotten stranded at the end. You gave your variables good names, so a comment like //inputs the numbers in front of cin >> number seems either misleading (You input only one number, but the comment says “numbers.”) or unnecessary.

You write on a single line,

using std::cout; using std::cin; using std::endl;

You normally want to put statements like these on their own lines. In C++17 and up, you can instead write,

using std::cin, std::cout, std::endl;

I’d recommend putting your header files and using declarations in alphabetical, or some other logical, order, so you can easily see whether something is or isn’t there.

I also put a using declaration like this in my programs, because std:: was only added to cout and cin in ’98, and I’m old-fashioned. It would be a very bad idea to have, for example, using std::string;, because there is a lot of C++ code out there that uses the name string for something different. But cout, cin and endl are safe, because they’ve been around since the beginning and no C++ program ever declares some other cout. Not everyone agrees (and you can read the comments if you want to hear that perennial debate). “Never import a name from the standard library into the global namespace,” is an easier rule to follow than, “Only add an identifier to the global namespace if you’re sure that no other module will ever re-use the same name,” so that’s what some people recommend.

Finally, if I don’t bring this up, someone else is sure to: most people here recommend you end lines with << '\n' rather than << endl, unless you genuinely do need to flush your output. This will give you slightly better performance.

\$\endgroup\$
10
  • 2
    \$\begingroup\$ I agree with everything you said, but only have 1 thing to add: don't use using std::cin, std::cout, std::endl; at all. This tends to pollute the global namespace and can lead to clashes in names. For a tiny program, like this, it's fine but it's better to start with good practices from early on. This isn't enough to write a review about, so, I am giving this point to you. \$\endgroup\$ Feb 4, 2023 at 12:25
  • 1
    \$\begingroup\$ The "problem" doesn't manifest in this example. But if you try to create something more complex, throwing all the stuff into the global namespace is a pretty bad idea. I'm not saying your answer is wrong, but to just keep in mind to avoid this on more complex programs. Best practices should be practiced from the beginning, and trying to prevent an old habit is harder than creating good habits. \$\endgroup\$ Feb 4, 2023 at 14:41
  • 2
    \$\begingroup\$ I agree with you. But you completely missed the point I've made. \$\endgroup\$ Feb 4, 2023 at 14:57
  • 1
    \$\begingroup\$ @IsmaelMiguel Respectfully, I don’t think I did. If you bring string into the global namespace, that could be a serious problem because a huge number of programs define their own string. The canonical answer to why you shouldn’t import namespace std says something like, “When I see std::string, I know it’s from the STL. When I see string, I’m not sure.” This never happens with cout or cin. The other thing that could go wrong is if someone adds an identifier to a namespace you import that then breaks your code. This doesn’t happen when you enumerate your imports. \$\endgroup\$
    – Davislor
    Feb 4, 2023 at 15:16
  • 1
    \$\begingroup\$ Yeah, but you should point this out in the answer. This is the exception to the "rule". \$\endgroup\$ Feb 4, 2023 at 16:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.