What's something that C++ beginners should do that'll help later?
As the title says, what's something that c++ beginners should start doing, or should know about c++ that will possibly help them later on?
Last edited on
closed account (E0p9LyTq)
1. Don't use using namespace std;.
2. Learn to use the C++ random objects (<random>)and functions/agorithms instead of C's srand/rand.
2. Learn to use the C++ random objects (<random>)and functions/agorithms instead of C's srand/rand.
| ...help them later on? |
As a professional or when learning other languages...
1. Indent correctly! It's the #1 thing you can do for readability. And don't be afraid to use spaces in your code, the characters won't bite you.
2. Use meaningful variable names. And perhaps even more importantly, don't use variables names that are too similar to each other. I've seen too many times where a programmer uses a variable names like "name", which can be a fine name by itself, but then uses "name1" within the same function in different places. If you need multiple name variables within the same function, given them distinct names to actually describe their purpose. Ex: student_name, teacher_name, first_name, last_name, etc.
3. Don't build the whole program at once and then sift through dozens of errors. Build each piece one at a time.
4. Understand compiler errors. Unlike errors that non-programmers might be used to, these errors are actually helpful once you read them. If you don't know what an error means, search it online and you're likely to find a similar scenario from a problem someone else had.
5. Make functions that are testable, and make tests for your functions. Have test cases where you know what the output should be given a certain input. Start by testing the simplest inputs possible, and then make the input bigger or more complicated once you know your function or algorithm can handle the basics correctly.
6. Always be thinking about reusability and refactoring. Does it look like you've written a very similar block of code multiple times with no or only minor differences? Figure out if you can factor the similar code into a function, possibly having the differences between the blocks handled by input parameters.
7. Use a debugger! Never just tell us "this program crashes" -- figure out where it's crashing, and you've already solved half the problem.
2. Use meaningful variable names. And perhaps even more importantly, don't use variables names that are too similar to each other. I've seen too many times where a programmer uses a variable names like "name", which can be a fine name by itself, but then uses "name1" within the same function in different places. If you need multiple name variables within the same function, given them distinct names to actually describe their purpose. Ex: student_name, teacher_name, first_name, last_name, etc.
3. Don't build the whole program at once and then sift through dozens of errors. Build each piece one at a time.
4. Understand compiler errors. Unlike errors that non-programmers might be used to, these errors are actually helpful once you read them. If you don't know what an error means, search it online and you're likely to find a similar scenario from a problem someone else had.
5. Make functions that are testable, and make tests for your functions. Have test cases where you know what the output should be given a certain input. Start by testing the simplest inputs possible, and then make the input bigger or more complicated once you know your function or algorithm can handle the basics correctly.
6. Always be thinking about reusability and refactoring. Does it look like you've written a very similar block of code multiple times with no or only minor differences? Figure out if you can factor the similar code into a function, possibly having the differences between the blocks handled by input parameters.
7. Use a debugger! Never just tell us "this program crashes" -- figure out where it's crashing, and you've already solved half the problem.
Just some thoughts:
- learn debugging and (unit) testing
- learn version control systems - like git, github...
- document your code - maybe learn a tool like doxygen
- make sure your code always compiles without warnings
- learn design patterns
- choose one coding style and stick with it - PascalCasing, camelCasing or snake_casing
- be clear about your priorities - robustness, performance, testabilty, maintainability,
- learn the C++ Core Guidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
- learn GSL: Guideline support library
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-gsl
https://github.com/Microsoft/GSL
- learn to use 3rd party libraries - depends a bit of the domain you want to work for like: banking, mathematical, physics, security...
- learn debugging and (unit) testing
- learn version control systems - like git, github...
- document your code - maybe learn a tool like doxygen
- make sure your code always compiles without warnings
- learn design patterns
- choose one coding style and stick with it - PascalCasing, camelCasing or snake_casing
- be clear about your priorities - robustness, performance, testabilty, maintainability,
- learn the C++ Core Guidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
- learn GSL: Guideline support library
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-gsl
https://github.com/Microsoft/GSL
- learn to use 3rd party libraries - depends a bit of the domain you want to work for like: banking, mathematical, physics, security...
Also:
http://en.cppreference.com/w/cpp/links
There are C++ idioms, and the list of libraries.
If you write some code, think about what could go wrong. Some classic problems are divide by zero, overflow, underflow, out of range errors for a particular problem. Write code to ensure that these things don't happen. Proper testing should uncover all the problems, but one should try to do a decent job in the first place.
There is a concept called contract programming which involves preconditions, postconditions, and invariants.
https://en.wikipedia.org/wiki/Design_by_contract
For OOP, this comes to mind:
https://en.wikipedia.org/wiki/SOLID
But that is just one of the things, OOP design is more complex than it might first appear.
http://en.cppreference.com/w/cpp/links
There are C++ idioms, and the list of libraries.
If you write some code, think about what could go wrong. Some classic problems are divide by zero, overflow, underflow, out of range errors for a particular problem. Write code to ensure that these things don't happen. Proper testing should uncover all the problems, but one should try to do a decent job in the first place.
There is a concept called contract programming which involves preconditions, postconditions, and invariants.
https://en.wikipedia.org/wiki/Design_by_contract
For OOP, this comes to mind:
https://en.wikipedia.org/wiki/SOLID
But that is just one of the things, OOP design is more complex than it might first appear.
Topic archived. No new replies allowed.