General Coding Tips For N00bs


telecoda

Still Fresh
Joined
Dec 5, 2006
Messages
45
Location
Surrey, UK
Website
Visit site
I've been around the block a few times coding wise, new to the GP2X though.

Thought it might be worth compiling a list of tips to make life easier for new developers though.

Feel free to add a few yourselves.

These are a few tips to make life generally easier in the long run, instead of ripping off your eyelids in frustration as it JUST WON'T WORK!


i.) Make regular copies of your working code. As soon as you get to a point in your code when something is fully working. Take a copy of the full directory structure. Year ago I never adopted this and would just rework the same old tired piece of code. Introduce a bug somewhere and be unable to unravel my mess.
(Didn't do this last week and got in a hell of a state with forward declares and includes in my code and took me two evenings to get back to square one....)

ii.) Working code first, optimised code second. Get something working first, THEN concentrate on speeding it up to eek out the optimum performance possible later. Drop in your ARM assembly later when you're ready. A C/C++ function will do at first.

iii.) The debugger is your friend. Step through the code when it is failing, look for uninitialised pointers,variables etc.

iv.) If something can fail code for it to fail. If you are calling an initialisation function that returns an error code. Add some so to check if was successful or not. Don't let your code blindly continue assuming everythings ok.

v.) If you spot a bug in your code, fix it now. Otherwise you'll forget it and it'll come back and bite you later, in one of your 3am coffee induced debugging sessions.

vi.) Don't be afraid to ask. Noboby knows everything. There is a great community here, a few people with god like abilities do appear to know everything GP2X related but the are not shy sharing their knowledge.

vii.) Start small. Don't run before you can walk. If you are completely new to coding there is a LOT of stuff you've got to learn. Toolchains, language syntax, computer logic in general, help libraries like SDL.
We all started with a "Hello World" app of some sort. Feel a sense of a achievement even if you have only got that far. There are an awful lot of people in this world who couldn't even do that.


viii.) Stick at it, have fun. If you run into a problem, be like a dog with a bone. Keep at it until you crack it. The sense of achievement afterwards is what keeps us idiots coding time and time again with often no financial reward.

Take or leave this advice. ;)
 
Nicely worded!

When coding and putting hours and hours of work into a project, go out and buy yourself a USB key (or similar). Frequently place your backups onto this key, and any other bits you consider essential. PC Harddrives fail, programs crash and corrupt the registry, viruses are nasty, etc. don't assume nothing will happen to you, or you could be crying after losing the entire source code to a project you've spent the last month on.
 
For i) I would actually suggest using source control rather then manual backups since the server is usually on a separate machine.

I have had one scare in the past when my hard drive crashed and we lost a weeks worth of good work. Thankfully we had a spare test copy on someone else's machine.

I have one little article full of links for C++ programming specifically: http://parabellumgames.no-ip.org/articles/...-c-programming/

And currently in the middle of writing another for things like common programming standards while writing TicTacToe.
 
Yaustar,

I agree completely with the source control aspect. However its just yet another thing to learn when they are taking their first tentative steps.

I was coding a version of Bombjack on the spectrum in assembler years ago, and some bastard stole the cassette (yes old skool) with the source code on it. doh! :angry:
 
telecoda posted on Feb 12 2007 at 09:27 AM said:
Yaustar,

I agree completely with the source control aspect. However its just yet another thing to learn when they are taking their first tentative steps.

I was coding a version of Bombjack on the spectrum in assembler years ago, and some bastard stole the cassette (yes old skool) with the source code on it. doh! :angry:

There could be tens of thousands of ideas here, but must start at the very beginning. (But be mindful of Squidges comment .. always backup; every significant change, copy to another directory; every few signficiant changes, copy to flash, another machine, gmail, whatever :)

NEVER FORGET to have a 'debug option' that builds in a pile of printf or other stdout type logger. In C and variations you can #if or #ifdef it out so its not in the runtime distribution, but you can do the equivilent in every language. Printing to the console/screen is easily the most valuable debugging technique, bar none. Likewise you could dump to permanenet storage if you need to look at lots of data. A third option is to log to an array .. make an array 1000 lines long and log to the last one; when you run out, loop to the top and blank out a few, so its easy to find. Then you can look at coredumps or the like to see where things crashed, even in release code.

I'm forever hiding numbers aned junk in the bottom right of the screen and then when you game crashes, just loko for the junk therel "oh, it says abf so it died before foofoo, thus it was in code section blurgo"

jeff
 
Last edited by a moderator:
skeezix posted on Feb 12 2007 at 05:14 AM said:
There could be tens of thousands of ideas here, but must start at the very beginning. (But be mindful of Squidges comment .. always backup; every significant change, copy to another directory; every few signficiant changes, copy to flash, another machine, gmail, whatever :)

NEVER FORGET to have a 'debug option' that builds in a pile of printf or other stdout type logger. In C and variations you can #if or #ifdef it out so its not in the runtime distribution, but you can do the equivilent in every language. Printing to the console/screen is easily the most valuable debugging technique, bar none. Likewise you could dump to permanenet storage if you need to look at lots of data. A third option is to log to an array .. make an array 1000 lines long and log to the last one; when you run out, loop to the top and blank out a few, so its easy to find. Then you can look at coredumps or the like to see where things crashed, even in release code.

I'm forever hiding numbers aned junk in the bottom right of the screen and then when you game crashes, just loko for the junk therel "oh, it says abf so it died before foofoo, thus it was in code section blurgo"

jeff
Yeah, I did this for Dance2x and it was really useful.

Shameless plugs to reports of projects I did at University:
http://parabellumgames.no-ip.org/yaustar/dance2x.php
http://parabellumgames.no-ip.org/yaustar/mgs2d.php
 
Last edited by a moderator:
Since you mostly wont be doing this for profit, you might leave some projects for a while and come back to work on them later, so there are three things I advice you with:
1) Make your different versions of code back ups in folders numbered as (alpha 1, alpha 2, ...) so you know exactly which version is prior to the other one.
2) Choose meaningful variable names (but avoid long variable names, they affect performence).
3) Use comments as much as you need them, do not worry, the compiler drops those comments so your executable files won't suffer any decrease of performence.
 
sehs33 posted on Feb 12 2007 at 04:21 PM said:
Since you mostly wont be doing this for profit, you might leave some projects for a while and come back to work on them later, so there are three things I advice you with:
1) Make your different versions of code back ups in folders numbered as (alpha 1, alpha 2, ...) so you know exactly which version is prior to the other one.
2) Choose meaningful variable names (but avoid long variable names, they affect performence).
3) Use comments as much as you need them, do not worry, the compiler drops those comments so your executable files won't suffer any decrease of performence.

2? ... Compile time performance ? Are you sure you want to say this?
 
Last edited by a moderator:
How is also a WIP article that I am writing but currently has the content which applies to the thread.

http://psppics.gr-p.com/images/TicTacToe.zip

sehs33: 2) is an old wives tale. Short variable names was used in the very old days because it sped up compiler times. It doesn't affect performence at all.
 
Am talking about the performence while running :)
In fact it does have an effect on performence on all interpretted languages and languages that need a virtual machine in general, you can test this with a Java application or a Flash movie, I assume it doesn't have a simillar effect on C\C++ applications.
 
Yup, can't emphasise the importance of decent comments enough.

As a hobbiest coder you are likely to have large gaps between having a chance to work on some code.

Comments help to diffuse the "what the hell was I thinking of there" fug.

I have often revisted old code and looked at it and thought, hey thats a pretty neat way of doing something when I actually wrote it myself.

Also the odd silly comment helps when going back to old code to raise a smile. Afterall we ARE doing this for fun.
 
Back
Top