I agree with HeelX, I generally don't comment most of my code. I'm anal about the design of my code, I like to make it look pretty and it needs all of the indentions to be correct or else you can't tell where each thing begins and ends, but I also use variables and functions that are easy to read. I don't ALWAYS comment, but I might every once in a while.
Here's a random code example from Kino One:
function skinchange()
{
var hp;
var newhp;
while(me)
{
newhp = my.health;
if (newhp < hp)
{
my.skin = ent_skins(me);
wait(1);
my.skin = 1;
}
hp = my.health;
wait(2);
}
}
You might not understand exactly what the code is for at first glance, but you do understand what it does. The code reads: "check the enemy's health, if the enemy's health is lower now than it was two frames ago, change the enemy's skin to his last one". At very first glance it doesn't look that way, but because of the name of the function and variables you can tell what the variables hold and what the function is supposed to do.
The code is used for flashing enemy models to their last skin which is a "white" skin used to achieve a "flashing" effect when an enemy is damaged.
My big problem is though, because of my lack of commenting a lot of times when you look at some functions you can't really tell what the variables are for, but I generally do that after working on a game for a while, and for prototyping, but when prototypes make it in the final game then the variables might be the same. It does make some things confusing, but for most global variables I TRY (don't always do) to make the variables understandable.
