10) Pretend that the next person to read your code is an angry psychopathic killer that knows where you live.
I am being a bit of a hypocrite here, as my code is often unreadable and badly commented. It is important to have readable code, especially if you are sharing it or publishing it, or going back to it later. Every programmer has started a project, came back 2 weeks later and found it difficult to understand what the hell they wrote.
Oh yeah, and try and limit your use of goto's. People seem to hate those.
9) Pretend that the next person to use your program is an angry psychopathic killer that knows where you live.
In the end, your program is written for the user. The program needs to be concise, and easy to use. If you are putting your program online or even selling it, you must always always include a readme.
8) Staying up till the early hours of the morning buzzed on coffee is never good for your code.
For me, staying up late drinking red bull makes me write very bad code very fast.
7) Quality, not quantity.
As I have said before, the amount of lines in a code is not a valid measure of how good a program is. Infact, its probably better if you don't write so many lines. Concise code is better than huge code. Use switches instead of loads of if's, and for loops rather than repeating things etc.
6) You will never learn everything about a programming language.
There is no person who knows everything about a programming language. There is always always more to learn. Sign up for an account on http://stackoverflow.com/ - the community there is very helpful.
5) You will become frustrated, and feel like giving up on some projects. Don't.
Google is your best friend, and if you can't find what you are looking for, ask. The feeling you get when you see your code finally compile. Besides, most of the time its usually something small and easily remedied.
4) Try and learn some new languages.
A lot like normal languages, generally people who know more languages are better at communicating. Also, they can easily go to new places. It is a good idea to get various types of programming languages under your belt, such as Python, Java and C++.
3) Never copy and paste code.
Its good to read and learn from more experienced programmer's source code, but just copy and pasting it from the internet means you learn nothing. See if you can re-write it in a more efficient or clever way. If you must copy and paste it, at least make sure you understand it.
2) Programming should be fun.
Especially for a teenage programmer who is not being paid, programming should be fun and an enjoyable hobby. Programming is a fun thing to do; it improves your maths and logic skills, kills time, and nothing beats the feeling you get when you see "Linking ->" in the output window after hours of writing.
1) Practice makes perfect!
You learn more from experience then you do from reading. Try different things out see if they work. See if you can replace those goto's with a for switch, or a do while switch.
Thanks for reading!
Interesting. Few comment of mine :
ReplyDelete« my code is often unreadable and badly commented » You have the assumption here that it is good to comment. This is wrong.
Many programmer write bad code and think it is ok because they put comment to explain the mess they created. In the first place, good code don't require much comment, because it is readable and comprehensible.
Are comment bad ? No, but they shouldn't explain what your code does. Your code explain what it does. Comment provide extra informantions, that cannot be fixed by better code. For example, you are using a third party API, and a bug in it force you to use a workaround, put a comment to explain that, and preferably a link to the description of the problem and the workaround. So any programmer can no why you didn't used the straightforward way.
It is an application of the DRY principle : duplication is evil, so Don't Repeat Yourself. If comment repeat what your code does, you are going into trouble : you must maintain both code and comment (so maintenance require more work) and you have a risk to have discrepancies between code and comment, which is even worse than no comment at all.