next »

[InfiniteStateMachine]

Why would one have an end comment in simple header guards anyway unless there's a lot of other preprocessor stuff there? What confusion would one even be trying to avoid? Seems excessive in most cases.

I agree but I've worked on a couple projects where the codebase did that and it's important to continue whatever style is being used. I personally think it's a little much.

I mean ultimately, we shouldnt even have to be worrying about pragma/ifdefs.

[Average Software]

I agree but I've worked on a couple projects where the codebase did that and it's important to continue whatever style is being used.

This is a belief that I wish would go away.  Styles should always be challenged, because a lot of styles are based on misunderstandings.  If the proponents of a coding style can't defend it, it should be discarded.

That being said, when I rule the world I'm appointing a special force to seek out people that preface member variables with m_ and punch them all in the face.

[oahda]

That being said, when I rule the world I'm appointing a special force to seek out people that preface member variables with m_ and punch them all in the face.

I actually started doing that only with my current project after never having done so before.

Reason: adopting a jQuery-style naming. Getters and setters have the same name with different signatures. And obviously I want the most basic name for the exposed methods and not for the hidden members.

[ThemsAllTook]

I agree but I've worked on a couple projects where the codebase did that and it's important to continue whatever style is being used.

This is a belief that I wish would go away.  Styles should always be challenged, because a lot of styles are based on misunderstandings.  If the proponents of a coding style can't defend it, it should be discarded.

If it's getting in your way, then challenge it, sure, but the cost of changing styles in an established codebase is likely to be greater than the cost of leaving it and matching new code to what's there. Unless you're arguing for mixed old and new styles, changing a style means updating the entire codebase to match. Most stylistic choices (as the word implies) are personal preference, so you'll have an uphill battle to show the rest of the team an actual pragmatic reason for changing stuff.

If you're working by yourself, none of this applies, other than the time investment for you to update the codebase you inherited to suit your whims.

[InfiniteStateMachine]

I agree but I've worked on a couple projects where the codebase did that and it's important to continue whatever style is being used.

This is a belief that I wish would go away.  Styles should always be challenged, because a lot of styles are based on misunderstandings.  If the proponents of a coding style can't defend it, it should be discarded.

That being said, when I rule the world I'm appointing a special force to seek out people that preface member variables with m_ and punch them all in the face.

If the style was challenged and the entire project got refactored to be consistent then that would be fine but on a large private project with hundreds of people programming unless I'm very high up the totem pole I may not even have access to debate style.

I'd still prefer to have a consistently styled codebase that I don't fully agree with than 10 different style thrown about across the project.

I also have the m_ stuff. I feel like that could be a big contributor to carpal tunnel :D

If you're working by yourself, none of this applies, other than the time investment for you to update the codebase you inherited to suit your whims.

One of the many joys of working on your own projects.

[MorleyDev]

Only time I use defines is when it's needed, namely header guards and compile-time filtering out of. The old "EXTERN" define is a useful code-block though for DLLs. More of a necessary evil than a joy

Code:

#ifdef PPR_STATIC
	#define PPR_EXTERN_IMPORT
	#define PPR_EXTERN_EXPORT
	#define PPR_LOCAL
#else // !PPR_STATIC
	#ifdef _MSC_VER 
		#define PPR_EXTERN_IMPORT __declspec(dllimport)
		#define PPR_EXTERN_EXPORT __declspec(dllexport)
		#define PPR_LOCAL
	#else //!_MSC_VER
		#define PPR_EXTERN_IMPORT __attribute__ ((visibility ("default")))
		#define PPR_EXTERN_EXPORT __attribute__ ((visibility ("default")))
		#define PPR_LOCAL __attribute__ ((visibility ("hidden")))
	#endif//_MSC_VER 
#endif // PPR_STATIC

#ifdef PPR_COMPILE
	#define PPR_EXTERN PPR_EXTERN_EXPORT
#else // !PPR_COMPILE
	#define PPR_EXTERN PPR_EXTERN_IMPORT
#endif // PPR_COMPILE

As for naming schemes, always felt a naming scheme should exist to compliment the available tools. In C# and Java, easiest to just do what Resharper and IntelliJ tell you to do. And they're good enough to allow and encourage you to default to var for variables (I'm a big believer in there being inherent value in type deduction in a static language, and thing for local variables var should be the default declaration).

In javascript, you're naming scheme is to get how IDEs have little or poor autocomplete so your tools can't accurately tell you enough information about your variables and functions.

In C++, autocomplete with CLion or Visual Studio is pretty decent. So you can use auto and don't need to do things like putting "C" in-front of classes, "I" in-front of interfaces (personally I prefer ClassImpl for classes over IClass for interfaces).

However, it's still not perfect, so sometimes a bit of annotation could be justified. m_, for example, allows you to see all member variables by typing "m_" and hitting CTRL+SPACE. If CTRL+SPACE without that prefix is too slow, or doesn't order things to put member variables high up in your IDE, this makes sense.

[InfiniteStateMachine]

Only time I use defines is when it's needed, namely header guards and compile-time filtering out of. The old "EXTERN" define is a useful code-block though for DLLs.

Code:

#ifdef PPR_STATIC
	#define PPR_EXTERN_IMPORT
	#define PPR_EXTERN_EXPORT
	#define PPR_LOCAL
#else // !PPR_STATIC
	#ifdef _MSC_VER 
		#define PPR_EXTERN_IMPORT __declspec(dllimport)
		#define PPR_EXTERN_EXPORT __declspec(dllexport)
		#define PPR_LOCAL
	#else //!_MSC_VER
		#define PPR_EXTERN_IMPORT __attribute__ ((visibility ("default")))
		#define PPR_EXTERN_EXPORT __attribute__ ((visibility ("default")))
		#define PPR_LOCAL __attribute__ ((visibility ("hidden")))
	#endif//_MSC_VER 
#endif // PPR_STATIC

#ifdef PPR_COMPILE
	#define PPR_EXTERN PPR_EXTERN_EXPORT
#else // !PPR_COMPILE
	#define PPR_EXTERN PPR_EXTERN_IMPORT
#endif // PPR_COMPILE

As for naming schemes, always felt a naming scheme should exist to compliment the available tools. In C# and Java, easiest to just do what Resharper and IntelliJ tell you to do. And they're good enough to allow and encourage you to default to var for variables (I'm a big believer in there being inherent value in type deduction in a static language, and thing for local variables var should be the default declaration).

In javascript, you're naming scheme is to get how IDEs have little or poor autocomplete so your tools can't accurately tell you enough information about your variables and functions.

In C++, autocomplete with CLion or Visual Studio is pretty decent. So you can use auto and don't need to do things like putting "C" in-front of classes, "I" in-front of interfaces (personally I prefer ClassImpl for classes over IClass for interfaces).

However, it's still not perfect, so sometimes a bit of annotation could be justified. m_, for example, allows you to see all member variables by typing "m_" and hitting CTRL+SPACE. If CTRL+SPACE without that prefix is too slow, or doesn't order things to put member variables high up in your IDE, this makes sense.

on resharper, I wanted to ask you about that but not derail this thread

http://forums.tigsource.com/index.php?topic=47404.0

[Boreal]

That being said, when I rule the world I'm appointing a special force to seek out people that preface member variables with m_ and punch them all in the face.

Don't hate.  It helps me avoid name collision - this->foo for public members, m_foo for private/protected members, and foo for local variables and function arguments.  I even name my PIMPL fields m so that it feels similar to normal member variable access.

[RandyGaul]

That being said, when I rule the world I'm appointing a special force to seek out people that preface member variables with m_ and punch them all in the face.

Don't hate.  It helps me avoid name collision - this->foo for public members, m_foo for private/protected members, and foo for local variables and function arguments.  I even name my PIMPL fields m so that it feels similar to normal member variable access.

Totally agree with Boreal. Also it's really nice for intellisense; can type m_ to see what is available in the scope. Also, while reading code someone else wrote anything prefixed with m_ will have it's scope immediately known. It's really hard to read others' code when many identifiers must be looked up over and over again just to learn what scope applies to what.

[Sik]

Ever since constexpr came about I haven't really found any need for macros, since templates already cover code generation.  The only time I use #define anymore is for exporting symbols, since on Windows you need __declspec(dllexport), but nothing on other platforms.

Huh, I thought this could be automated (maybe it's just MinGW?).

This is a belief that I wish would go away.  Styles should always be challenged, because a lot of styles are based on misunderstandings.  If the proponents of a coding style can't defend it, it should be discarded.

Then you would constantly get programmers into a religious war as everybody thinks their style is the supreme one and everybody should immediately switch to theirs and will go to war for something as stupid as the size of indentations (and whether you use tabs, spaces or mixed) or where braces should go or how many comments you're supposed to add and where, etc. (and oh god hope you don't find that programmer that occasionally deviates from the strict rules of his chosen style, he's satan personified).

So huh yeah, that's why projects just settle on a style and force all developers to use it.

[InfiniteStateMachine]

That being said, when I rule the world I'm appointing a special force to seek out people that preface member variables with m_ and punch them all in the face.

Don't hate.  It helps me avoid name collision - this->foo for public members, m_foo for private/protected members, and foo for local variables and function arguments.  I even name my PIMPL fields m so that it feels similar to normal member variable access.

I believe he was referring to the exteraneuous underscore

[Boreal]

I believe he was referring to the exteraneuous underscore

Fair enough.  I don't treat it as part of the identifier yourself - but it preserves continuity in these cases:

Code:

void foo(int bar, int baz, int qux) {
    this->bar = bar;
    m_baz = baz;
    m->qux = qux;
}

[Layl]

I prefer just using _foo instead of m_foo or mFoo. Though lately I've been rust where you usually work with fields only through a "self" reference.

[surt]

Underscore prefixed identifiers are reserved in the standard.

[Sik]

More specifically, the operating system or the compiler may use them for their own purposes (e.g. toolchain-specific extensions to the standard).

[oahda]

If this were Java we could probably prefix variables with an invisible Unicode character.

I tried making variables with names written with Arabic letters in Java once. It worked.

[Schrompf]

Works in Visual Studio, too. The whole unicode range is a valid symbol. GCC, on the other hand, complains like the old bitter woman it actually is.

[Boreal]

Works in Visual Studio, too. The whole unicode range is a valid symbol. GCC, on the other hand, complains like the old bitter woman it actually is.

AFAIK GCC allows Unicode characters in identifiers but you have to explicitly enable it with -fextended-identifiers, and you have to write out the code points by hand.  Clang is UTF-8 by default and MSVC automatically detects it.

Code:

// MSVC and Clang
int bär = 100;
// GCC
int b\u00E4r = 100;

I personally don't see much point in using non-ASCII identifiers anyways.  String literals may already be encoded in UTF-8 as per the standard, and C++1z proposes that character literals may also be UTF-8 (although you'll need to use int instead of char).

[oahda]

String literals may already be encoded in UTF-8 as per the standard, and C++1z proposes that character literals may also be UTF-8 (although you'll need to use int instead of char).

Oooh, I didn't know that. Finally.

[Sik]

The problem with using Unicode in identifiers is that it's extremely easy to encode something in a screwed up way, or when something has multiple possible encodings then people using different text editors end up using different ways to write the same thing, etc. Also there's the issue of how those identifiers get stored in the different binary formats (since most object formats restrict the valid characters).

On the other hand, I know GCC allows $ in identifiers, at least in GNU mode (e.g. for C99 you'd use -std=gnu99 instead of -std=c99). Apparently $ is commonly accepted as a valid identifier character in most object formats.