Since I've been in numerous [unproductive] arguments regarding coding style (i.e. camelCase, CamelCase, under_scores, etc.), and it kinda makes wonder whether anyone would choose an engine based on this primarily. So far, it looks like almost everyone prefers camelCase, which I don't like but I prefer under_scores, which everyone else doesn't like, and my engine is written like this:

struct ke_d3d11_renderdevice_t : public ke_renderdevice_t;

void ke_d3d11_renderdevice_t::do_whatever( int param )

{

}

Of course, I don't mind this at all:

struct KeDirect3D11RenderDevice : public KeRenderDevice;

void KeDirect3D11RenderDevice::DoWhatever( int iParam1 )

{

}

Come to think of it, I haven't seen any well known engines using the former, and it makes me wonder if that would hurt the usability of my engine, so I'm thinking about changing it this week.

What matters to me most is usability and portability, and so far, it builds fine on Windows, Mac and iOS (planning to do Linux, Android/FireTV, Blackberry, and any necessary consoles).

So, if Engine X was a world renowned engine like Unreal, Unity, Ogre, etc, but used underscores in it's API, would you likely not use it? After all the arguments I've had about underscores, I wonder what everyone else thinks.

Shogun

Yes, coding style is part of what makes me decide on what libraries I use, but it's more about the style of the interface. I tend to discard solutions that have over engineered or over-oop'ed interfaces, or those that are too c-like if it looks like putting a C++ wrapper around it would be too much work.

I also dislike working with projects that have insane lazy indenting and badly named functions etc. The less time you spend battling with and reformatting your code the better, but I am probably in the monitoirty with my opinion.

Of course performance matters too, almost as much as community support and stability and frequency of updates. Beware using dead projects!

Edit: I just thought I'd clarify that I seek projects that are similar in coding style to my own. Careful planned use of oop, not over engineered, CamelCase with leading capitals, none of this javaCamelCase crap. I guess beggars can't be choosers though which is why I am writing my games without an established engine right now, just a small framework of my own reusable code...

Subsystem_VariableName works well for me. Otherwise I don't lose too much sleep over this aspect of a coding style, unless of course it involves Hungarian notation, in which case 4 AM, cold sweats and wanting to chew my own arms off are all perfectly reasonable responses.

unless of course it involves Hungarian notation

Hungarian notation needs to die in a fire. Sorry, I mean an m_lpszFire

What's wrong with Hungarian notation? I like it. I'd much rather use it than camelCase which just feels lazy to me. I grew up on CamelCase and Hungarian notation, so it's just natural to me.

m_pD3DDevice;

m_dwReferenceCount;

m_szString;

csCriticalSection;

hThread;

It helps me understand code better just by looking at it. And browsers don't have intellisense.

EDIT: it was bothersome back in the early 2000s when devs were using 'mat' as a prefix for materials and matrices. I was always like "can't you use 'mtx' for matrices instead??"

Shogun.

If the engine / libraries use odd API or language structure, I will not use it.

Why the #### should I learn dozens of obscure scripting languages ???

Why the #### should I learn dozens of obscure scripting languages ???

Reminds me of:

http://xkcd.com/927/

It helps if a library matches your own coding style exactly, but it's not a big deal.
IIRC the Quake engines used the underscore style, and had many, many C++ CamelCase games written atop them.

unless of course it involves Hungarian notation

Hungarian notation needs to die in a fire. Sorry, I mean an m_lpszFire

What's wrong with Hungarian notation? I like it. I'd much rather use it than camelCase which just feels lazy to me. I grew up on CamelCase and Hungarian notation, so it's just natural to me.

m_pD3DDevice;
m_dwReferenceCount;
m_szString;
csCriticalSection;
hThread;

It helps me understand code better just by looking at it. And browsers don't have intellisense.

Pet hate; That's NOT Hungarian notation.

Hungarian puts the semantic type on the front -
referenceCount vs elementCount
pxWidth vs cmWidth
workerThread vs mainThread

The idea is that if you have two variables that are of compatible language types (e.g. int), but incompatible logically (e.g. One is a sanitised string and one is raw user input, or one is width in cm and one is width in pixels, etc), then those prefixes will make had code look obviously bad.


What you guys are complaining about is a complete bastardization of this idea, where someone at MS read the paper but completely missed the point, interpreting "semantic type" as "primitive/object type" and spawned that style which they now call "Systems Hungarian"... And not even MS recommends it anymore.

What's wrong with Hungarian notation?

I'd argue that systems Hungarian (as presented in your examples) doesn't encode much in the way of useful semantic information. Knowing the type of the variable doesn't tell me what it's used for, most of the time, which is what I really want to know, most of the time. Also, what do you do when a variable is of a class type? I presume you'd fall back to something resembling apps Hungarian... which is what Hungarian is supposed to have been in the first place and can actually be useful.

1. m_pD3DDevice;

2. m_dwReferenceCount;

3. m_szString;

4. csCriticalSection;

5. hThread;

1. If I remember my D3D right, this is always a pointer, so pointing out that it is one is redundant = not useful.

2. I would expect that my coding convention would have all reference counts be the same type, so knowing that it's a reference count = knowing that it's a DWORD (or size_t, or a typedef) = the dw prefix is redundant = not useful. And when are you ever going to name something that's a reference count something that doesn't have the term "ref[erence] count" in it?

3. As written, this is obviously redundant, but this does tell me how I have to interact with this variable - as a null-terminated C string, which I wouldn't be able to infer from simply labelling this as a "string." Since null-terminated strings require very different treatment from something like std::string, I'd say in this particular case the prefix DOES add useful semantic information.

4. Wouldn't the fact that the critical section is treated as one in the code (ie. by passing to *CriticalSection functions) convey this just as well as the prefix?

5. If I remember my Win32 right, one always references threads through HANDLEs, so pointing out that this is a handle is redundant - instead point out that it's a thread.

It helps me understand code better just by looking at it. And browsers don't have intellisense.

How often are you looking at code in a browser? Are you ever writing code in the browser?

And not even MS recommends it anymore.

Indeed.

The assumption (which I don't think is unreasonable) is that we're also using a language with a reasonable degree of type-safety too, so if you try to mix-n-match types in an incompatible way, the compiler will complain at you. So Hungarian (by which I mean Systems Hungarian, which is what most people think of when they see "Hungarian" discussed) is almost completely redundant in that case.

One of the worst abuses I saw was in a dialect of Visual Basic; the only data type was variant, so of course the programmer prefixed every variable with "vnt".

I can sorta-kinda see the value in "m_" and "g_" but in the former case I prefer to be more explicit and use "this->" whereas in the latter I prefer to not use them at all.

In general I don't see it conveying any useful information, or at least not information that's useful enough to be worth the tradeoff of making variable names look like line noise.

On the other hand, a naming convention that clearly distinguishes parameters from local variables, that's something useful.