Author Topic: Naming proposal  (Read 2321 times)

Offline gim

  • Zombie Food
  • *
  • Posts: 17
    • View Profile
Naming proposal
« on: March 06, 2013, 07:05:57 AM »
I think naming is a minor issue, comparing to indentation/braces stuff.

Cataclysm uses sort of C-like STL-ish naming.

Here's my proposal, it's sort of Java-like, and I've managed to convience at least few people to this naming scheme
(although initially some of them were rather sceptic, it just works IRL).

  • name of classes, structs and enums (any type basically, CamelCaps
  • name of variables, fields, objects, arguments: headlessCamelCase
    • Additionally class/struct members prefixed with "m_"
  • macros and defines: ALL_UPPER_UNDERSCORE_DELIMITED
  • name of constants and enum elements: Camel_Caps_Underscore_Delimited

There are few 'pro-s' of this naming, which boils to the thing, that differentiation of different thing is much easier:
  • differentiate between classes and functions
  • differentiate constants from macros/defines
  • distinguish locals from members on the spot (and easier completion, you usually know whether you want member or local when typing...)

example follows:
Code: [Select]

static const size_t Lightmap_X = (2 * See_X + 1);
static const size_t Lightmap_Y = (2 * See_Y + 1);


static const size_t Lightmap_Cache_X = (2 * Lightmap_Range_X + 1);
static const size_t Lightmap_Cache_Y = (2 * Lightmap_Range_Y + 1);


class LightMap
{
public:
LightMap();

void generate(Game* g, int x, int y, float naturalLight, float luminance);

LitLevel at(int dx, int dy); // Assumes 0,0 is light map center
float ambientAt(int dx, int dy); // Raw values for tilesets

bool isOutside(int dx, int dy);
bool sees(int fx, int fy, int tx, int ty, int maxRange);

private:
typedef LightMapCache LightCache[Lightmap_Cache_X][Lightmap_Cache_Y];
float m_lm[Lightmap_X][Lightmap_Y];
float m_sm[Lightmap_X][Lightmap_Y];
bool m_outsideCache[Lightmap_Cache_X][Lightmap_Cache_Y];
LightCache m_cache;

void applyLightSource(int x, int y, int cx, int cy, float luminance);
void applyLightArc(int x, int y, int angle, int cx, int cy, float luminance);

void applyLightRay(bool lit[Lightmap_X][Lightmap_Y], int sx, int sy,
int ex, int ey, int cx, int cy, float luminance);

void buildOutsideCache(Map* m, const int x, const int y, const int sx, const int sy);
void buildLightCache(Game* g, int x, int y);
};

As I've said, I don't think it's really important, but just wanted to know your opinion
« Last Edit: March 06, 2013, 07:23:28 AM by gim »
a chap go wąż, a wąż go chap

Offline zpmorgan

  • Contributor
  • Zombie Food
  • ****
  • Posts: 30
    • View Profile
Re: Naming proposal
« Reply #1 on: March 06, 2013, 09:44:22 AM »
It's probably great for a new project, but this ignores at least 1 existing convention: enums, which are everywhere, are all lower case, delimited by underscore, and prefixed with an abbreviated class name. I'd love for methods & local stuff to stay lower_case_underscore_delimited because it's easy to read & write. Also renaming literally everything might be slightly inconvenient, but whatever.

Offline Shades

  • Contributor
  • Zombie Food
  • ****
  • Posts: 61
    • View Profile
Re: Naming proposal
« Reply #2 on: March 06, 2013, 12:20:17 PM »
Personally I dislike CamelCase or pascalCase mostly because it's harder to read than underscore_spaced_variables.
However I'll stick with whatever style people choose as it doesn't make a big difference to me.

I will point out that there is a reason c++ uses underscores in the standard libraries though :)

I'm happy to prefix class members. I tend to use just an _ prefix for member variables, or follow the _ postfix style for function parameters that boost/stl uses but m_ for members works just as well.

Offline GlyphGryph

  • Administrator
  • Survivor
  • *****
  • Posts: 1494
  • Kreaaaaa
    • View Profile
Re: Naming proposal
« Reply #3 on: March 06, 2013, 12:43:32 PM »
It's a shame c++ uses such a limited charset for it's valid variable characters, it really does take away some of the best naming conventions. :P

This sounds fine to me. Personally, I'd go with underscore for variable names, but I can't even disagree with pascalCase since it is functionally identical.

The only thing I'd like to add is a request for more descriptive variable names, where possible. We aren't programming on punch card computers, people! There's no reason not to use words on modern systems.

Offline gim

  • Zombie Food
  • *
  • Posts: 17
    • View Profile
Re: Naming proposal
« Reply #4 on: March 06, 2013, 02:07:03 PM »
I just wanted to know your opinion, I don't think it actually makes much sense to change it all know.
That is, it could be done if everyone would want a change and I don't think it's the case

I will point out that there is a reason c++ uses underscores in the standard libraries though :)
Because it's old, and was done by ex-C coders :D

I'm happy to prefix class members. I tend to use just an _ prefix for member variables, or follow the _ postfix style for function parameters that boost/stl uses but m_ for members works just as well.
I was using underscore for some time, but I've switched to m_, cause you have to remember about two things, never use two underscores (reserved for c/c++ compilers), if you use one underscore it cannot be followed by upper case letter (also reserved).

The only thing I'd like to add is a request for more descriptive variable names, where possible. We aren't programming on punch card computers, people! There's no reason not to use words on modern systems.

++ to that, some of variables in code are really "what the <insert_word> is this (variable) for"
a chap go wąż, a wąż go chap

Offline Shades

  • Contributor
  • Zombie Food
  • ****
  • Posts: 61
    • View Profile
Re: Naming proposal
« Reply #5 on: March 07, 2013, 08:50:40 AM »
Because it's old, and was done by ex-C coders :D

I think you'll find the latest standard is 2011, which makes it newer than pretty much anything ;)

The only thing I'd like to add is a request for more descriptive variable names, where possible. We aren't programming on punch card computers, people! There's no reason not to use words on modern systems.

I doubt anyone will have an issue with this. At least I should hope not.

Offline Tase

  • Zombie Food
  • *
  • Posts: 99
    • View Profile
Re: Naming proposal
« Reply #6 on: March 07, 2013, 03:39:09 PM »
I'dd love to see this, sometimes I have problems differenciating types from variables if everything is lowercase, especially if the two are named practically the same. I'dd be cool with whatever you guys want for casing functions. I think casing classes/enums/structs would be cool.

Offline gim

  • Zombie Food
  • *
  • Posts: 17
    • View Profile
Re: Naming proposal
« Reply #7 on: March 07, 2013, 04:26:04 PM »
Because it's old, and was done by ex-C coders :D

I think you'll find the latest standard is 2011, which makes it newer than pretty much anything ;)


And yet, they managed to keep backward crapability...
a chap go wąż, a wąż go chap