Jump to content

  • Log In with Google      Sign In   
  • Create Account

l0calh05t

Member Since 16 Dec 2000
Offline Last Active Today, 08:54 AM

Posts I've Made

In Topic: Coding-Style Poll

27 September 2016 - 09:12 AM

In my world, UPPER_SNAKE_CASE is ONLY used for macros. Constants are spelled "k_constantName".

 

Note that I said defines, not constants! Also constants are regular snake case to me and a loud hell no to k_ ;)


In Topic: Coding-Style Poll

27 September 2016 - 09:06 AM

I can work with most styles - my gripes with code tend to be related to how a feature is implemented not what the code looks like.

That being said, the basics:
- tabs instead of spaces if I'm working primarily in the IDE, spaces if I have to look at my code in other editors often; this should be consistent throughout the codebase.
- tabs equivalent to 4 spaces
- no snake_case - PascalCase, camelCase, and scope_camelCase are permissible
- either put opening braces on their own line or don't, as long as it's consistent
- closing braces always go on their own line
- braces should be aligned with the scope that holds them, not the scope they define
- all control flow statements must include braces (except switch cases, which are obviously delimited by other control flow statements) to prevent mistakes

Finally:

// don't do this
auto thing = foo();
if (thing) {
}

// do this instead to enforce that the variable 'thing' can only be used if it's valid
if (auto thing = foo()) {
}

 

Heh. If I'd make a set of coding rules it would be snake_case for most things, PascalCase only for concepts (template parameters) and UPPER_SNAKE_CASE for defines/macros. Because I think it's just not ok to simply ignore how the standard library looks like. (Or avoiding the standard library because you don't understand it which seems to be very popular in C++).

 

But a big +1 on if(auto thing = foo())! (Although I dislike the space before the if's opening parenthesis.

 

Another small detail that would make me happy: foo const * x instead of const foo * x. Because I'd prefer consistent right-to-left order over reading in spirals (think foo const * const x vs. const foo * const x).


In Topic: Coding-Style Poll

27 September 2016 - 09:02 AM

For braces, Allman over K&R, but I can live with either. But there are variants that are just nasty... like all those except Allman and K&R in the table on I particularly detest the so-called GNU style.

 

Similar for tabs vs spaces where I definitely prefer tabs (because you can adjust them. for example two space indents are too small for readability IMO but quite common and then you're stuck with that...) but I can live with either as long as its consistent. And as long as the tabs aren't used for alignment (instead of for indentation only)... which is plain dumb.

 

Now variable and class name prefixes... no, NO, NO, NO! And it appears im not alone with that opinion. Especially the "C" for class. It's pointless and unnecessary. Especially when considering the fact that classes and structs are the same thing (even if MSVC would like to tell you otherwise).

 

But one thing I would flat out refuse to do: block alignment, e.g.

int             foo                 =       10;
char            barf                =      'c';
SomeStupidClass anEven_StupiderName = xyzabcde;

Waste of time, you can't cleanly add new values etc. Just no.


In Topic: 13 Y/O That Is Interested In Learning How To Make Video Games

27 September 2016 - 08:06 AM

Also, when you write tests, make sure the test actually fails on incorrect results! Fail first, then fix. That is the TDD way, and for damn good reasons.


In Topic: Approximate Average Brightness Of Rendered Image

01 August 2016 - 03:24 AM

Phuh... That's a complex thing. I don't know how to access mipmaps, I'm not such experienced. I just do some simple experiments.

Within a shader you can simply use textureLod (with a sufficiently high value for the lod) to access specific mipmap levels.


PARTNERS