Code-style: Cringe pics

Miscellaneous Topics
#41

I used it back then. I thought it made things more readable:


glBegin(GL_QUADS); 
{
    glVertex2f(...);
    glColor3f(...);
    glVertex2f(...);
    glColor3f(...);
    glVertex2f(...);
    glColor3f(...);
    glVertex2f(...);
    glColor3f(...);
} 
glEnd();
#42

One of the few “practical” reasons I’ve seen: http://stackoverflow.com/a/11971070/3517265

Using them so that you can copy-paste blocks of code, i.e. in tests. Also in switch statements, so you don’t have to hoist variables out of the cases.

#43

These blocks do at least help to isolate variables defined inside them as usual afaik.

EDIT: Which is actually what the link is about.

#44

It would be interesting to see the effects of these blocks around variables on the assembly generated by the JIT, for those bit twiddling, performance mongering hackers.
I expect that most of the time they have no effect whatsoever, quite possible they’re eliminated entirely by javac. Guess I’ll go check.

#45

Scopes don’t exist in bytecode. (yes, i know about stackframes)

Javac will reuse localvar slots earlier when explictly limiting scope.

HotSpot couldn’t care less about javac reusing localvars, it builds a completely unrecognizable new version from scratch, and again, and again, while inlining and optimizing.

TL;DR: no effect whatsoever on anything.

#46

Callsites like:

public void foo(String url, String path, String type, Boolean option1, Boolean option2, Boolean option3, Integer max)

And then in sample code:

//Just do this :-) foo(null, null, "Thing", null, null, true, null);

wtf???

#47

That’s basically what I expected.

#48

Note: javac does nothing. Nor do any of the mainstream java AOT compilers. That’s why a good decompiler can pretty much exactly reproduce your source from bytecodes.

#49

It does do some things, but yeah, the AST is unaffected.

#50

The JVM does optimisation at/just before runtime, which would make sense since it knows the right details about the system.

#51

It does it during runtime too, sometimes multiple times as it finds out more information and can produce better codepaths. I believe you can set the threshold at which the JIT will consider code “hot” too, which is nifty sometimes.
There’s a lot of good info on this wiki: https://wikis.oracle.com/display/HotSpotInternals/PerformanceTechniques

#52

Watching Ray’s livestream, I’ve noticed he does this:

}else{
#53

Well I mean he is the resident crazyman.

#54

At “compile” time. The details of when a compile occurs is VM, version and options dependent. Normally the “we’ve done nothing at AOT bytecode” is interpreted a rather large number of time before a compile will occur. All this kinda stuff is unspecified (and for good reason).

Yes the number of time a piece of code will be compiled is likewise VM, version and option dependent. I’m pretty sure that ATM the only time hotspot will recompile is if an assumption is proven wrong (something else is tickling the back of my brain but it’s not coming to the surface).

So it’s not a good idea to turn down (too far) the number of times a method is interpreted before compiling since you’ll be cutting short the collection of data for “profile guided” optimizations.

#55

I had to maintain a js project once that had a very special way of doing things. Can’t post actual code from the project, but it looked something like this:


for(var arrIndex = 0; arrIndex < arr.length; arrIndex++){
	for(var arrFooIndex = 0; arrFooIndex < arr[arrIndex].length; arrFooIndex++){
		for(var arrFooBarIndex = 0; arrFooBarIndex < arr[arrIndex][arrFooIndex].length; arrFooBarIndex++){
			arr[arrIndex][arrFooIndex][arrFooBarIndex]['Property'] = 'yay';
			//Lets loop some more ;)
		}
	}
}

Now imagine this going down up to 10 levels of nesting and add a bit of business logic into each layer, often referencing the objects of other layers. The project was very well documented and structured, but things like this required that you had to be extra careful with every little change. It didn’t help that there was very much redundancy, so often you had to change multiple loop trees, if you needed to change something.

Another thing that annoys me very much (it might be a bit off topic for code style) are date parsers in javascript. Somehow people resist using already established solutions and try to roll their own. And this is really hard to get right, especially if you you take different locales into account. In one project I had to help out with a problem on the frontend with datepickers, I found three different implementations (let’s call them hacks) of a dateParse method, each one used in different places of the application and one of them actually returned the correct dates sometimes… Fun thing is that this application ran on a platform, that had a js api and provided full support for localized dates and some other nice features. But hey, why not roll your own?

I once read a nice quote, sadly I can’t remember where I read it, but it fits nicely for this post:

#56

haha, I don’t even know where I picked that up. for whatever reason it just felt natural. I think it’s a sideeffect to me setting up my if/else statements by typing this one liner real quick then filling it in and spacing it out as I code a method:

if(){}else{}

Actually, one thing I do that I know makes some people cringe is how I “compress” my getters and setters at the end of my class files into one line. But I’ve always liked it this way;


	public int getTileId(int tileX, int tileY, int layer){return mapArray[tileX][tileY][layer];}
	public String getTileProperty(int tileID, String property, String def){return mtl.getTileProperty(tileID, property, def);}
	public Image getTileImage(int x, int y, int l){return mtl.getTiles().get(mapArray[x][y][l]);}
	public Image getCollisionImage(int x, int y, int l){return mtl.getTilesCollision().get(mapArray[x][y][l]);}
	public int getBrushSize(){return brushSize;}
	public void setbrushSizeUp(){if (brushSize < 20)brushSize += 1;}
	public void setbrushSizeDown(){if (brushSize > 1)brushSize -= 1;}
	public int getLayer(){return layer;}
	public void setLayer(int l){layer = l;}
	public void setGridMode(){gridView = !gridView;}
	public boolean getGridMode() {return gridView;}	
	public void lockAccentMode(){accentModeLock = !accentModeLock;}
	public void accentModeOn(){accentMode = true;}
	public void accentModeOff(){accentMode = false;}

this ones probably the worst of the bunch:


	public void setbrushSizeUp(){if (brushSize < 20)brushSize += 1;}
	public void setbrushSizeDown(){if (brushSize > 1)brushSize -= 1;}
#57

That’s it, we need an intervention.

#58

I don’t see the need for the on/off setters, unless reflection is used to tie functionality to UI. Having said that, eww!

#59

Not necessarily code-style, but this is a thing I do which some may find really cringy.

http://puu.sh/9guTQ/fa9e2aa2e8.png

(Yes, I know, I have a few warnings, I’ll fix those later :P)

I don’t have time to organise my code into fancy little packages. I’m sloppy when it comes to that. There are more important things to organise, like my mind. ::slight_smile:

I also format my code like this:


private void foo(double bar)
{
    System.out.println(bar);
}

I come from the dark land of C.

  • Jev
#60

I just wrote an exception that passes back a method to call at a catch site.