Code-style: Cringe pics

Miscellaneous Topics
#61

looks around shifty eyed

Kinda hard to explain my GUI code, but I “kind of” do that in some areas. My GUI code itself doesn’t actually control anything in the engine, but sometimes the GUI needs to know if the game is in a certain state so it knows what to do with a button.

for example, these lines do not actually turn on and off accentMode, it just toggles highlighting/unhighlighting the button. But I plan to refactor it to just ask the game if highlight mode is on. For whatever reason it’s still using it’s own internal boolean. (and that’s completely retarded) Just a throwback from when my GUI wasn’t in it’s own class files like it should be. :confused:


   public void lockAccentMode(){accentModeLock = !accentModeLock;}
   public void accentModeOn(){accentMode = true;}
   public void accentModeOff(){accentMode = false;}

My new GUI system though, should eliminate this anyway. I just haven’t made it over to this area of code to refactor it into the “new” GUI code layout.

#62

I can’t resist the urge to edit your code, Rayvolution:

public void setAccentMode(boolean on) { accentMode = on; }

I found this:


int length= 0;
for(int i = 0; i < array.length; i++){
    length++;
}
System.out.println("Array has " + length + " elements.");

Going through some old code, I found this:


if(someCondition) {
	if(anotherCondition) {
		if(yetAnotherCondition) {
			SomeObject object = aParameter;
			if(ANOTHERcondition) {
				if(lastCondition) {
					AnotherObject object2 = getOtherObject();
					if(object2 != null) {

I removed the conditions and changed object names to remove confusion, my code wasn’t THAT terrible. But six nested if statements, anyone?

#63 
public void setAccentMode(boolean state) { accentMode = state; }

…since the state isnt always “on” :smiley:

#64

“On” can be true or false… But “state” must always be true!

#65

You win.

  • Jev
#66

eh? wouldn’t “on” be true and “state” be “the state you want to set it to”?

#67

If you have red and green apples, you could have boolean red equal to true or false. But if you had a boolean “color” it would always be true :slight_smile:

#68

Well now you’re comparing apples and rhinoceroses.

#69

Nah, she’s right (she, right?).
But I’d offer the compromise: [icode]boolean isOn[/icode].

#70

Once I wrote duplicate code.

#71

I always do this!
Thought i was the only one :smiley:

#72

Now that I think of it:

That’s what code folds are for!

#73

I always have hated it when people name their bools things like [icode]isRunning[/icode]. I have no idea why.

I also have a bad habit of [icode]naming_my_functions_like_this()[/icode].

  • Jev
#74

Ugh C function convention.

In Clojure (lisps in general I believe) the convention is hyphens (although I guess that’s only if you couldn’t figure out a good 1 word name): [icode](rand-int nitems)[/icode] which I’m not sure what to make of. It does kinda fit, (much better than camelCase in a lisp anyway) but still seems alien. I guess all styles can-be-abused.

#75

Inside some long complicated pathfinding method

Vector3f temp1 = …
Vector3f temp2 = …
Vector3f t3 = temp1.distance(temp2);
Vector3f m1 = temp1.distance(t2);

and so on with the variable names

#76

I dont like code that is inherently awkward to read.
A great example of this is the isState boolean expression.

For example, consider :

if (!isRunning())
start();

Read in my mind as :
“if not is running then start”

But if we name the boolean expression ‘state’ in place of ‘isState’ then it can be unclear at first glance what the expression represents with certain state names.