Dealing work and code

Previous topic - Next topic

erico

I have a tough time dealing work and coding all together(+life).
I´m an amateur coder...I´m essentially structuralist and am very found of expressionism.

All things considered, I try to document it and modulize it the best I can, I also try to be very methodic.
If I start over a deeper coding project, some 5 days away from it is enough to ruin my understanding of it at all... :(

Lately I started on simpler stuff so to manage it done. Going good so far...
I would sincerely like to know your thoughts on this, as it seems most of you have jobs and get coding going a lot deeper then I could possibly understand.
How do you pull the rabbit of the hat?

Kitty Hello

If you can't remember what old code does, just split it into smaller functions and give them proper names, like:
FUNCTION split_string_at_commas_take_care_of_quotes:

Use comments a lot, especially for function headers.
Use longer variable names.

http://thc.org/root/phun/unmaintain.html
Read this, and do the opposite.

Quentin

Look for topic "Clean code development". There are also some good books about it. e.g. one from Robert C. Martin. I don't agree with all of his statements, but it's very interesting.

Other topics you can look for:
DRY - Don't Repeat Yourself
KISS- Keep It Simple, Stupid
....

and many others.

A good start to get more knowledge about it could be:

http://www.clean-code-developer.com/

Learning those principles and working with them made my life as a programmer easier. Even if I have to maintain/change older programs.

Albert

It's good if you can continue coding on your mobile phone (without compile) or on your netbook, when you are on the go, when you're waiting, or before fall asleep. If you travel a lot a day then just continue coding on your mobile (public transport powa, not while you driving!).
I'm using DropBox, you can download your source file to your Android/iPhone or Windows Mobile PDA, and then sync it back to the cloud. If you're using a device where you cannot compile: even better, you can progress more if cannot hit the build button every 5 seconds. (Anyhow I've glScriptBasic compiled to Android, and I can code small .gbas file and run too on my Android! Which is good, no error handling :( and there are some bugs in it, but it works)

Also concentrate on mini projects, prototypes. Anything you can complete within 5 days. Simple board game, mini platformer, experimenting new technics or game play mechanics. If you make some, maybe you get an idea to develop one further, and using up some of the technics you developed earlier.

erico

All advices taken...thanks :nw:

This is really a struggle for me. Hope it helps new users too.

Slydog

#5
Some great advice in these posts!   :good:
Here's some advice from my experience:

Comments:
Too much commenting can be as bad as too little.  You *shouldn't* need to comment every line, just one comment for each small block of code.  When scanning for a certain part of code, too many comments makes this difficult.

Variables:
Use meaningful variable names.  This helps reduce the need for detailed commenting.  For example:
Code (glbasic) Select
pos = pos + 5.0  // Increase bullet position by 5,  . . . or . . .
INC bullet_position, 5.0  // No need to comment as it's self explanitory


Consistency:
Use a good and consistent coding style, and variable / function naming method.  That way you don't have to first figure out what the code is supposed to do, before you start digging into the details.  Here's where I break my own 'rule' about variable names.  If you ALWAYS use the same name for the same purpose, you can keep the name short, which seems to help make the code easy to read.  For example, I tend to ALWAYS use fn$ for my file name variables.  Later on, I'm never confused by what I meant by 'fn$' as it's always the same.

Variable Prefixes:
I *used* to prefix my variable names (back in Visual Basic times!) with a data type indicator, such as 'f_speed' to mean the speed variable is of type 'float'.  But I found that just bloats and clutters your code, making it almost unreadable.  However I still use prefixes (sometimes suffixes) to identify what a variable represents, and I find it makes my code easier to follow.  For example, my sprites all start with 'sp_', such as 'sp_bullet'.  When referring to 'sp_bullet' anywhere in my code, I automatically know it refers to a sprite.  Other examples I use are 'fn_' to hold filenames, 'v_' to indicate a vector TYPE, etc.  If you ALWAYS use the same style for suffixes, you don't always need to fully describe your variable names.  I above referred to 'bullet_position' in the comment section, but if you always name your position variables with '_pos' this avoids confusions and shortens your code, so 'bullet_pos' would be acceptable in this case.

Libraries:
Keep reusable code in libraries / modules.  My game has 15 generic libraries.  These libraries can be used by ANY of my future games and don't include any game specific code.  My game logic is therefore quite small with commands such as 'guiMainMenu.Display()', I don't manually draw each menu item by hand each time.  I created a GUI library that hides the common GUI display / event details.

TYPES:
Kind of an extension on modular programming.  Use TYPES anywhere you need related variables for more than one purpose.  Ex: create a 'Position' type that holds 'x', 'y', 'width', 'height'. So many game elements can use these common variables, so don't confuse your code with 'player_x', 'enemy_x'.  The great advantage to this is you can add FUNCTIONS to TYPEs.  So the above TYPE could have a 'IsCollide()' function that takes an 'x','y' position and checks if it's inside the object's boundary.
My current project (WIP) :: TwistedMaze <<  [Updated: 2015-11-25]