Yeah, barely any of my code has comments on it. It makes it hard to go back to something a couple years back, but if you keep up with your knowledge, it all comes back within 5-10 minutes.

The quote is a joke, Will. If you don't comment your code, others will have an impossible time understanding what it does. Also, it gets tiring trying to remember what significance FLAG2 has in your function after you've been absent from your code for a while.

Personally I've made it a habit to make a comment every time I do anything significant. If I turn on FLAG2, I make a comment. If I manipulate a vector with the "vec_" functions, I make a comment. Generally you should make comments that streamline the steps the computer should be going through in your function, such that if you read nothing but the comments in your function it should be clear what you're trying to accomplish.

Guess I have mutated to an unreal programmer

If you are a lone wolf it might be the case that you take less benefit from exhaustive commenting than if you work with others. What I have learned during programming for my bsc thesis, is that if you properly select the names of your variables, functions, methods, classes, interfaces etc.pp. you get your code very well self-documented. It doesn't mean that you should'nt do comments, though, of course... ;-)

Exactly what HeelX said, plus if you comment TOO many lines, your code will become unreadable. You can easily over see small lines of code (i=0; for example) and so on.

I just make comments when i get the feeling that i could forget what this code does. And i often give a comment line to every function/class i declare, just to be 100% sure what function it is.

HeelX is right. The code should also speak for itself. Otherwise it is too complicatedly written. No need to comment what function PLAYER_GetName() does.

i usually cooment, when i need //TODO , to add features toa function.. or
//Improve optimization
//or examplain, int a is a skill means "exame : area" send from the caller function...

or that sort of things..

Well the comments I do mainly are for auto generating documentation (I'm working on a template project).

All other comments are for my own understanding. I have coding guidelines, naming conventions and pick meaningful names, but still I explain some algorithms with comments because otherwise I would not understand anymore what I'm doing there.

For people not commenting at all or having a 1:1 comment code ratio I would advice you to grab a good book. 'Clean code' for instance introduces nicely to self commenting code (like HeelX said) by naming things right.

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:



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.