next »

[JobLeonard]

Try

[Belimoth]

 

[ThemsAllTook]

Try

What I experience watching this must be what it's like for my parents if I ever talk about programming around them.

[uselessffs]

What I experience watching this must be what it's like for my parents if I ever talk about programming around them.

You should have a look at the functional programming paradigm then, its possibilities are mind-blowing!
I despise Java precisely because it's almost impossible to even simulate function objects in it, contrary to C/C++ and C#, and you end up writing dirty blocks of code for what should take a line or two...

[methozoid]

Code:

if(fading == 0)
{ ... }
else if(fading == 0)
{ other methods }

Lesson to myself: NEVER EVER write code if you haven't slept for 20+ hours..

[Evan Balster]

Haha, that's why I don't let myself do late-night coding sessions any more.

[JobLeonard]

Depends, if it's the "easy, dumb typing that requires time but little mental effort", that's easier late in the evening for me. Basically, when I know what I'm going to do before I start coding.

[Dr. Cooldude]

So I'm currently working on a school project (It's a game rental application), and this abbreviation made me chuckle a bit

Code:

GamesForm gf = new GamesForm();
gf.Show();

EDIT: Just updated from source control and now it looks like this

Code:

if (gf == null || gf.IsDisposed) gf = new GamesForm();
gf.Show();

gf.IsDisposed...

[impulse9]

After performing some find/replace through the code I saw this and laughed.

Code:

end->SetDescription("Potion of end");

[Kekskiller]

Minimalizing error messages to the very essence:

Code:

debugStep("legacy fail", "important");

[d]

Ahem:

Code:

// fopen is kinda janky
#pragma warning(disable: 4996)

[sublinimal]

Code:

// no

[Dacke]

Gotta love the Java 7 multicatch

Code:

try {
   mainController.getDaxploreFile().writeUploadFile(uploadFile);
} catch (TransformerFactoryConfigurationError | TransformerException | SQLException | DaxploreException | SAXException | IOException | ParserConfigurationException e1) {
   // TODO HAHAHAHAHAHA
   e1.printStackTrace();
}

[Quarry]

WHAT, ECLIPSE WHY DIDN'T YOU TELL ME ABOUT THAT D:<

[Geti]

Gotta love the Java 7 multicatch

While that's nicer than a million catch statements for all the subclasses of exceptions, the whole "Exceptions fucking everyhere" part of java is one of the reasons I never feel like I'm having fun writing it. Like, I write fun things in it but writing the code is a constant source of furrowed brows and feeling mad. :/

To stay on topic, had a giggle at how banal and undocumented some of the behaviour of KAG's engine is.

Code:

this.setTeamNum(-1);
print(this.getTeamNum()); //255

the team is stored in a u8, so this is expected if you know the internals, but some people have already started modding with it and are having some amusing wtf moments.
For the record, the get/set functions take an int, so the literal -1 doesn't even generate a warning. Troll interface is troll. Will it ever be fixed? Only time will tell.

[Quarry]

nope it won't be

[Geti]

It's been in "the shame hole" for a few months now, maybe it'll bubble over into "low priority" eventually/

[George Michaels]

Code:

vec distance_norman /* #SoFunny */ = f_vec::normalize(f_vec::subtract(next, collision));

Found in an old version of my Ai code..

[heisenbergman]

Gotta love the Java 7 multicatch

holy crap this is news to me.

[Dacke]

While that's nicer than a million catch statements for all the subclasses of exceptions, the whole "Exceptions fucking everyhere" part of java is one of the reasons I never feel like I'm having fun writing it. Like, I write fun things in it but writing the code is a constant source of furrowed brows and feeling mad. :/

I think exceptions are one of the better solution to a necessary evil. Programs will get runtime errors and you have to deal with it somehow. I know a few approaches, in falling order of explicitness:

1. Throw exceptions
2. Have multiple return values and return explicit error-values (possibly the best approach, as seen in Go)
3. Have special function that check for errors (database.isCorrupt())
4. Return error values in-band (often null or -1)
5. Let it crash as soon as something goes remotely wrong
6. Keep going with a corrupt data state, which may make the program crash at some point

Option 5 or 6 is often the most fun to write, that's how I usually write small programs that just have to work for me (like personal scripts). But for production-ready code you want to explicitly handle every bloody error, which is a huge chore but generally necessary.

Java wants you to write production-code so it forces you to be explicit about what you want to do with every error. But since Java has to be written in an IDE anyway, you can easily let the IDE convert option 1 to 5 for you. As soon as the IDE warns about an uncaught exception, just click the warning and choose to throw it. Keep throwing it upwards at every level. At the top-level you get something horrendous like this:

Code:

} catch (TransformerFactoryConfigurationError | TransformerException | SQLException | DaxploreException | SAXException | IOException | ParserConfigurationException e1) {

It takes almost no time to write, you just keep telling the IDE to ignore the exceptions. Once you are ready to turn the code into production-ready code, you just go back in and explicitly handle all the exceptions in a reasonable way.