Bad habits to avoid?

[GMWolf]

I have to say university courses (mine, at least) really dont help with learning helpful commenting.
Early in the first year, they would ask for use to comment every single line. for example:

var x = 10; //create new variabble called x, and assign 10 to it.

while(x > 5) { //while x is greater than 5 -_-
    x -= 1; //subtract 1 from x
   show_debug_message(x); //print x to consol
}

(though we dont code in GM )
Thats increadibly stupid, as you are just rewriting the full code in english. Since i already new programming fundamentals, i certainly lost a couple marks for insuficient commenting..
Luckily that was only for the first couple weeks in general programming, but when writing assembly, we are still expected to comment everything like that -_-

Just as Yal said, Its much better to write what your code is about to do. eg:

//Print values 9 through 5.
var x = 10; //counter
while(x > 5) {
    x -= 1;
    show_debug_message(x);
}

 

[TheouAegis]

Well writing assembly makes a tad more sense to comment everything, but I think there they mean more like explaining what each block of code is supposed to do.

LDA #0
STA $01
STA $02
LDA n
LSR
ROL $01
ROL $02
LSR
ROR $01
ROR $02

Like, what the hell is going on here?!? Hence comments (I know it's not correct syntax, but it's just for example) would help out summarizing the whole block rather than each line. (FYI, it was from a password generator in an NES game, in case you're still wondering what's going on.)

 

[GMWolf]

Well writing assembly makes a tad more sense to comment everything, but I think there they mean more like explaining what each block of code is supposed to do.

LDA #0
STA $01
STA $02
LDA n
LSR
ROL $01
ROL $02
LSR
ROR $01
ROR $02

Like, what the hell is going on here?!? Hence comments (I know it's not correct syntax, but it's just for example) would help out summarizing the whole block rather than each line. (FYI, it was from a password generator in an NES game, in case you're still wondering what's going on.)

Yes, again, write what the purpous of the code, not what it does...

 

[chico_haze]

Don't scatter and repeat gamepad or keyboard input code throughout multiple objects.

I'm curious about this one as I'm still trying to find the best way to handle this myself. Do you have just one object that detects all input? How do you distribute that input to all the different objects that might use it?

Right now I'm using a script to sort of abstract user input, so instead of referencing a keyboard or gamepad check, objects that need input would use something like

if( scr_user_input("fireweapon") ){ //fire weapon }

This has been working ok for me, but I wonder how other people handle it.

 

[GMWolf]

I'm curious about this one as I'm still trying to find the best way to handle this myself. Do you have just one object that detects all input? How do you distribute that input to all the different objects that might use it?

Right now I'm using a script to sort of abstract user input, so instead of referencing a keyboard or gamepad check, objects that need input would use something like

if( scr_user_input("fireweapon") ){ //fire weapon }

This has been working ok for me, but I wonder how other people handle it.

I would not use strings, but enums instead.

Most of the time i build a generic input object, with a bunch of variables like xAxis, yAxis, jump, etc. other objects can then check the input object for these inputs.
I can then extend these objects with inheritance to support other input types.

 

[Yal]

I would not use strings, but enums instead.

Most of the time i build a generic input object, with a bunch of variables like xAxis, yAxis, jump, etc. other objects can then check the input object for these inputs.
I can then extend these objects with inheritance to support other input types.

I wouldn't even use enums, I'd use macros since they're color-coded and can have string values if needed.

 

[obscene]

I'm curious about this one as I'm still trying to find the best way to handle this myself. Do you have just one object that detects all input? How do you distribute that input to all the different objects that might use it?

Right now I'm using a script to sort of abstract user input, so instead of referencing a keyboard or gamepad check, objects that need input would use something like

if( scr_user_input("fireweapon") ){ //fire weapon }

This has been working ok for me, but I wonder how other people handle it.

I have one script ran from one controller object in the begin step that polls all the controls and sets their values to global variables. Then the object only have to check that those global variables instead. In objects where one object might have to check the same control several times I get the global once and save it as a local.

I've helped a few people with various projects and there's nothing worse than finding 20 instance of "if keyboard_check(vk_space)" as keyboard checks are very slow and doing it 20 times in one step is so, so bad.

 

[Yal]

I have one script ran from one controller object in the begin step that polls all the controls and sets their values to global variables. The the object only have to check that those global variables instead. In objects where one object might have to check the same control several times I get the global once and save it as a local.

I've helped a few people with various projects and there's nothing worse than finding 20 instance of "if keyboard_check(vk_space)" as keyboard checks are very slow and going it 20 times in one step is so, so bad.

Indeed. And having 20 inline calls to check a button means 20 times as many places you can mess up if you decide to change up the controls layout later. And furthermore, I personally think having to type out that thing over and over is both boring AND makes the code harder to read (since it easily leads to really long lines of text, especially if you have combos for pressing two buttons at once or such). I keep my local key variables (SO much better than globals if you ever want to add in co-op multiplayer) three characters long in most cases (k_r is short for Key Right, for instance) to help alleviate that. K being pronounced like 'key' is awesome for the mnemonicness