C++
Read the code of others. You will often learn how to do something - or how not to....
KISS - Keep It Simple, Stupid. Don't do something complex when something simple will do.
Document your code. At the very least document what your functions. methods do. What are the inputs? What are the outputs? Any time you return a pointer you should indicate who owns the pointer (who is responsible for deleting it). If the caller doesn't delete it then how long is valid? Document your code. Usually you can just say what you're trying to accomplish and why.
The world is full of programming advice: user getters and setters, don't use global variables, separate responsibility, etc. etc. etc. It's important to know why you should do these things because you'll find that sometimes the reasons don't apply to your specific problem. This stuff is advice, not dogma.
Above all, solve the right problem. On more than one occasion I've had someone explain to me in perfect detail why some problem could not be solved. Then I'd go off and solve it. The reason is usually because the other person looked at the problem and said "this is an instance of problem XYZ and that can't be solved (or the performance would be unacceptable)." The solution is look at how the problem is DIFFERENT from XYZ and exploit the difference.
Learn to use the debugger. If you look through these forums you'll be amazed at how many questions could be answered if the user simply ran the program through a debugger and looked at what was happening.
Own your mistakes. If you admit when you've made a mistake, people will respect you enormously.
KISS - Keep It Simple, Stupid. Don't do something complex when something simple will do.
Document your code. At the very least document what your functions. methods do. What are the inputs? What are the outputs? Any time you return a pointer you should indicate who owns the pointer (who is responsible for deleting it). If the caller doesn't delete it then how long is valid? Document your code. Usually you can just say what you're trying to accomplish and why.
The world is full of programming advice: user getters and setters, don't use global variables, separate responsibility, etc. etc. etc. It's important to know why you should do these things because you'll find that sometimes the reasons don't apply to your specific problem. This stuff is advice, not dogma.
Above all, solve the right problem. On more than one occasion I've had someone explain to me in perfect detail why some problem could not be solved. Then I'd go off and solve it. The reason is usually because the other person looked at the problem and said "this is an instance of problem XYZ and that can't be solved (or the performance would be unacceptable)." The solution is look at how the problem is DIFFERENT from XYZ and exploit the difference.
Learn to use the debugger. If you look through these forums you'll be amazed at how many questions could be answered if the user simply ran the program through a debugger and looked at what was happening.
Own your mistakes. If you admit when you've made a mistake, people will respect you enormously.
If you're stuck with a problem, rubber duck debugging is an easy and fast solution.
http://blog.codinghorror.com/rubber-duck-problem-solving/
http://blog.codinghorror.com/rubber-duck-problem-solving/
Topic archived. No new replies allowed.