Bad Habits

I game, but I am cursed with thinking about all the game rules, why they were made, possible different issues they had while making it, how long it took, who came up with the idea, what their budget was… etc. etc. etc.

But boy do I love MAKING games ;D!

I always love trying to figure out how the devs did this or that, and then I realize I’m being shot at and well… now I’m dead! But its still fun to think about the development process :slight_smile:

I agree, making games is by far the coolest thing I’ve done in my life! … Is that sad? :slight_smile:

I have a terrible habit of being lazy and just making variables public instead of private w/ getters and setters…

If you’re using Eclipse, right click on your workspace, go down to source and hit generate getters and setters, and then select your variables you want to make them for! You can also let Eclipse automatically generate constructors for you, and I’m sure a plethora of other things for you!

I have my own code cleanup format that, quote:

Remove 'this' qualifier for non static field accesses
Remove 'this' qualifier for non static method accesses
Remove unnecessary blocks
Convert 'for' loops to enhanced 'for' loops
Remove unnecessary parentheses
Remove unused imports
Add missing '@Override' annotations
Add missing '@Override' annotations to implementations of interface methods
Remove unnecessary casts
Remove unnecessary '$NON-NLS$' tags
Add unimplemented methods
Organize imports
Format source code
Remove trailing white spaces on all lines
Correct indentation

That way, all that ‘organization’ crap comes last, and it is SOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO easy!

I love eclipse :slight_smile:

I don’t comment as much as I should and I sometimes I forget to hit Ctrl+Shift+F :persecutioncomplex:

I always save and then format every time I finish a function or a new line! It just is a good habit I got into I guess :wink:

I CTRL+SHIFT+S and CTRL+SHIFT+F just like opiop, constantly. No matter what I’m doing. It’s subconscious.

I also have a bad habit of using ridiculously short variable names.

So instead of having something like [icode]isJumping[/icode] or [icode]jumping[/icode], I end up using something like [icode]j[/icode]
It seems fine at first, but it comes to bite you in the ass later in development.

  • Jev.

I actually struggle sometimes to not name my variables something very long! But then I remember I’ll have to type it out every time I want to use it, and because I’m lazy and my keyboard keys are kind of small, I use medium size variable names :slight_smile:

Of course, space + c (or something like that, I csnt remember!) brings up a list of variables/functions whilst typing!

I love ctrl-space.
If I [sub]did [sub]not [sub]my [sub]productivity would [sub]slowly [sub]dwindle [sub]my[sub]productivity[sub]which [sub]would [sub]be [sub]less [sub]than [sub]convenient [sub]for [sub]me…[/sub][/sub][/sub][/sub][/sub][/sub][/sub][/sub][/sub][/sub][/sub][/sub][/sub][/sub][/sub][/sub]

EDIT: Subscripting is hard!

FTFY
Unfortunately, I can’t fix the broken English with a simple search-and-replace.

I’m bad about using the “System.out.println()” method of debugging. NetBeans provides a perfectly good debugger, but for some reason my mind goes into primitive mode when it comes time to solve a problem. Bugs bad, me smash with print statements! >:(

I’m not certain this is really a bad habit/method. Especially if you know where the error is happening (Exception Stack), but not the when (Which values cause it to mess up). You can use the print statements in an attempt to discover some of the values that are coming in before the crash/error happened and use them to insert an if (variable == THIS ONE I FOUND THAT HAPPENS JUST BEFORE THE CRASH) and then put your little debug point there. :smiley: And by then, you’ll normally have a better idea of just what’s going wrong in the first place just by reading variables and stuff that you might be able to solve it without going through the debugger. Otherwise, you sit there and have to sit there and go through the execution calls one by one and probably sit through enough that your finger hits next by habit and it crashes without you getting enough data. >.>

Another problem I have. Changing ideas mid project. In fact, I almost failed to finish a class project (One where I decided to go way over board and write a full LibGDX program for a relatively simple game that was meant to be done using Java Swing and the like) because after turning in a basic design idea document I thought “You know what, now that I’ve gotten this mostly coded, I’ve found that it doesn’t make for a fun game. But if I change this and this other thing…” Which is why I almost never finish a game.

Hows this,

Never used a debugger in my life
Never profiled
Everything is public
0 comments

Phwore!

I barely use the debugger… Most of my issues are just calling the incorrect variables, obvious NPEs or just trivial Java code mistakes. My high school programming teacher used his debugger exactly once when I was in his class, and that was because I had screwed something up very bad, and neither of us could figure it out for 20 minutes.

i always use public fields
no indenting
hopefully college cs will break me of these habits

No indenting would drive me crazy…
I always auto format my code after I write a few lines because I absolutely hate staring at my own crappy typing and spacing. It just drives me nuts!

Public fields have never been a problem for me because Eclipse can generate getters and setters rather easily. If it weren’t for that, I would probably use public fields just because I’m lazy!

What is the point of using getters/setters again?

Mostly being able to validate the incoming value, prior to assigning that value to a field. The most trivial case being not allowing null values.

If I want nice looking code, I just compile and decompile the code, then use the output of the decompiler ;D

Anyway I think a bad habit is to overdo encapsulation to a point where it serves not additional use
and makes the code bloated and hard to track.

Also unnesesary use of external libraries for small tasks that could be coded by a 5 liner.