Naming proposal

Game Talk The Lab
1

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).

[ul][li] name of classes, structs and enums (any type basically, [tt]CamelCaps[/tt] [/li]
[li] name of variables, fields, objects, arguments: [tt]headlessCamelCase[/tt]
[list]
[li] Additionally class/struct members prefixed with [tt]“m_”[/tt] [/li]
[/list]
[/li]
[li] macros and defines: [tt]ALL_UPPER_UNDERSCORE_DELIMITED[/tt] [/li]
[li] name of constants and enum elements: [tt]Camel_Caps_Underscore_Delimited[/tt] [/li][/ul]

There are few ‘pro-s’ of this naming, which boils to the thing, that differentiation of different thing is much easier:

[ul][li]differentiate between classes and functions[/li]
[li]differentiate constants from macros/defines[/li]
[li]distinguish locals from members on the spot (and easier completion, you usually know whether you want member or local when typing…)[/li][/ul]

example follows:


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

2

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.

3

Personally I dislike [tt]CamelCase[/tt] or [tt]pascalCase[/tt] mostly because it’s harder to read than [tt]underscore_spaced_variables[/tt].
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 :slight_smile:

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

4

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. :stuck_out_tongue:

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.

5

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

Because it’s old, and was done by ex-C coders :smiley:

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).

++ to that, some of variables in code are really “what the <insert_word> is this (variable) for”

6

I think you’ll find the latest standard is 2011, which makes it newer than pretty much anything :wink:

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

7

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.

8

I think you’ll find the latest standard is 2011, which makes it newer than pretty much anything ;)[/quote]

And yet, they managed to keep backward crapability…