That "quick temporary hack" WILL end up in the final game...

It will be fixed in the patch is an empty promissory note

"Always document your code."

- alnite, 2013

If you don't understand why, you will sooner or later.

Code documentation is overrated and violates DRY. If your code needs documentation, it's not simplified enough. ;)

"Always document your code."

- alnite, 2013

If you don't understand why, you will sooner or later.

Code documentation is overrated and violates DRY. If your code needs documentation, it's not simplified enough. ;)

Code shouldn't need documentation in order to make what the code does understood. Code very often does need documentation of why a particular approach was taken instead of other, competing approaches.

That "quick temporary hack" WILL end up in the final game...

Even better, "no hack is temporary".

Ironically lately I've been trumping this whenever something starts annoying me (like how I rewrote a whole object from scratch just so I could have more of them without losing framerate on older systems), but then again I can get away with it because I'm the only programmer and probably my game's code isn't anywhere as big as most projects (I had to touch only a handful of files here, for instance, and only some lines).

"Always document your code."

- alnite, 2013

If you don't understand why, you will sooner or later.

Code documentation is overrated and violates DRY. If your code needs documentation, it's not simplified enough. ;)

Code shouldn't need documentation in order to make what the code does understood. Code very often does need documentation of why a particular approach was taken instead of other, competing approaches.

Keep in mind, I'm not talking about commenting code, which is a whole different thing.

If I have to read code line by line to know what it does, then I know I have failed in writing a reusable code.

"If you're going to be writing cryptographic code, and you're not sure what you're doing,

just put the keyboard away and ask someone qualified to write it for you. For all our sakes."

- Bacterius, 2013

Or, really, the more general statement - if your code is going to be used in situations where it failing could have very real consequences, don't write the code if you cannot assume said consequences. Seriously, the Dunning-Kruger effect is omnipresent in the field of programming, and not taking it into account is a recipe for disaster. See the recent utter failure of the Mega file sharing website's launch - the developer had no clue what he was doing, and the result is painfully obvious and predictable.

I'm writing cryptographic code and I'm not 100% sure what I'm doing. Should be interesting LOL

[quote name='alnite' timestamp='1358908519' post='5024569']
If I have to read code line by line to know what it does, then I know I have failed in writing a reusable code.
[/quote]

Agreed. What code does is different than how code does it

Use descriptive variable names. Seriously, this is one thing I don't understand. Probably 3/4s of my job is reading code and 1/4 writing; prioritize making code easy to read.

Use descriptive variable names. Seriously, this is one thing I don't understand. Probably 3/4s of my job is reading code and 1/4 writing; prioritize making code easy to read.

QFT.

Have previously worked on a code base where the original programmer didn't like typing so everything is named using 3 letter abbreviations strung together.

Want to calculate the distance between two points? Call the ClcDstBtw2Pts method! Need to know the value of the taxable amount on account balance? It's in the txAmtAccBal variable. And that's not a typo, the 'a' in tax was felt to be superfluous.