> Practice, practice, practice is not necessarily good advice if you don't know what you're doing. Your example is good about learning good program structure;

> Practice, practice, practice is not necessarily good advice if you don't know what you're doing. Your example is good about learning good program structure; that can save you a lot of time. You can only learn so much that way though. Sometimes you just have to make mistakes. I've written a lot of code that is bad. But if I hadn't written that code and I was tasked to do again I'd do it the same way because there is no other experience to tell me not to do that. My sum knowledge of programming is everything I learned from school and from reading -- but the majority comes from actually writing a whole lot of crap. It's interesting but in my experience: > Subroutines must have one entry point and one exit point, and accomplish one task. My subroutines almost always exit early at the top if any pre-conditions fail to be met. This is much better than a ton of nested if statement for each pre-condition. But in general it's best not to exit somewhere in the middle. > Add lots of comments in your code to help others or even yourself in case you forget what your thinking was. In practice, comments are pretty hard to maintain. I usually ask new applicants how they ensure a project can easily be passed off to others and if they just answer comments then that's generally a bad sign. Good hires will often laugh when mentioning comments and then describe other things like good naming, etc.