New naming convention

[Laurent]

I hope you don't come to the conclusion that java-style getPosition() etc. are the best solution. This would break every SFML code ever written for almost nothing (mainly personal preference), but with the drawbacks mentioned by aquanull.

The mentioned drawbacks were all about the omission of the get/is prefix. PascalCase vc camelCase is almost entirely a matter of personal taste.

[bastien]

The arguments in favor of the get/is prefixes make sense -- except that I'll never write getBegin()/getEnd() in a container

Have you read this article? http://www.idinews.com/quasiClass.pdf

[Laurent]

Have you read this article? http://www.idinews.com/quasiClass.pdf

That's a different problem (which you can discuss in a new thread if you really feel like SFML is using too many accessors), here we're only talking about naming conventions.

[Tex Killer]

I think get/is should be used wherever there is a value access, no mather what computation lies behind, provided that the method can be called multiple times to get the same results (not changing anything, only getting a value).

In cases that things get changed because of the function, I think get/is is not appropriate.

[V0idExp]

I'm also a Qt user, and love its naming convention and consistency. As a new SFML user I found a little strange the FuncIsCapital() convention, and now absolutely love the change.

As of my experience, the main advantages of this naming convention are:

• There's a clear difference between member functions (methods), functions in general and classes, enums.
• funcName() is shorter than func_name()
• funcName() is readable as func_name() but not so horrible

[aquanull]

I hope you don't come to the conclusion that java-style getPosition() etc. are the best solution. This would break every SFML code ever written for almost nothing (mainly personal preference), but with the drawbacks mentioned by aquanull.

The mentioned drawbacks were all about the omission of the get/is prefix. PascalCase vc camelCase is almost entirely a matter of personal taste.

I and others mentioned drawbacks about camelCase too:
* It breaks ALL existing code. This could have been justified better if only SFML 2.0-dev hadn't been being recommended over SFDML 1.x in the past years.
* It unEmphasizes the first sematical element of the function name. (Read carefully!)
* Some people really hate javaStyle.

Advantages it has though:
* Slightly less typing (- one Shift stroke) than PascalCase.
* Some people really love javaStyle.

Some might think that camelCase could help to distinguish classes from functions, but that in return could lead to confusion of variables and functions which could be more annoying as operator. and operator-> are used more frequently than operator::.

I'm also a Qt user, and love its naming convention and consistency. As a new SFML user I found a little strange the FuncIsCapital() convention, and now absolutely love the change.

As a non-Qt user, I found Qt's naming convention very strange/alien. However I realized that Qt was originally meant to attract java coders when I saw how faithfully its iterators work in Java's fashion. I've worked with quite a few other big C++ libraries that use various naming conventions, but apparently none of them follow the Qt's way in function naming.

[Laurent]

* It breaks ALL existing code. This could have been justified better if only SFML 2.0-dev hadn't been being recommended over SFDML 1.x in the past years.

This is not an argument against the camelCase notation, it's an argument against breaking the current convention. Although it is very important, let's keep it for later, as it will most likely be the final question to ask before doing something (or nothing at all).

* It unEmphasizes the first sematical element of the function name. (Read carefully!)

I think it does emphasizes the first word, since it's the only one that begins with a lower case.
To me there's more emphasize in verbSomeOtherNouns than in VerbSomeOtherNouns.

* Some people really hate javaStyle.

No matter what I do, some people will still hate it. It's definitely not an argument in favor of one notation or another.

I've worked with quite a few other big C++ libraries that use various naming conventions, but apparently none of them follow the Qt's way in function naming.

We are now talking about camelCase only, not about the "get" prefix. Please stay focused

[N1ghtly]

I love javaCase, I use it everywhere and now it's also in sync with Qt.
I'd still like to soo is/set/get functions though...

[aquanull]

* It breaks ALL existing code. This could have been justified better if only SFML 2.0-dev hadn't been being recommended over SFDML 1.x in the past years.

This is not an argument against the camelCase notation, it's an argument against breaking the current convention. Although it is very important, let's keep it for later, as it will most likely be the final question to ask before doing something (or nothing at all).

Guess I was skipping too much after the browser swallowed my post twice. The reasoning of the quotation of mine was very simple in logic:
Since the current notation != camelCase, switching to camelCase -> breaking the current convention.

Code: [Select]

// If that's not clear enough, then in a code example:
void foo(Notation newNotation) {
    if (newNotation != currentNotation) ChangeNotationAndBreakAllCode(newNotaion);
}

//...

* Some people really hate javaStyle.

No matter what I do, some people will still hate it. It's definitely not an argument in favor of one notation or another.

Oh, I failed to figure out that you consider personal preference irrelevant to this matter. Nonetheless, I think it's a great step forward - That would mean that whether you didn't like the previous conventions anymore shouldn't have been taken into account. Feel free to correct me if I am wrong on this.

* It unEmphasizes the first sematical element of the function name. (Read carefully!)

I think it does emphasizes the first word, since it's the only one that begins with a lower case.
To me there's more emphasize in verbSomeOtherNouns than in VerbSomeOtherNouns.

If that is personal preference again...

I've worked with quite a few other big C++ libraries that use various naming conventions, but apparently none of them follow the Qt's way in function naming.

We are now talking about camelCase only, not about the "get" prefix. Please stay focused

Yes, I am talking about the very camelCase function notation which is abused in Qt which explains why some C++ users could be in favour of camelCase which seems "alien" among existing C++ projects - because of their experience in using Qt which is designed to look and feel "alien". :wink:

EDIT: Honestly, I admit that found this debate getting more and more like sophistry. But I think it's very clear now that there is no compelling reason to change the whole API at the evident cost of breaking (almost) all existing code.

[Groogy]

Yes personal prefrences are irrelevant because there will always be someone that don't like it. This convention wouldn't be my choice but you don't see me complaining? In fact I've been forced to change convention every time I have a new job. So I don't care and just align.

Though if love and hate is put aside and we focus on the fact that Laurent have logical reasons behind the change. Then in my eyes go right ahead. Always favor function above form.

And breaking current existing code doesn't matter because this is an unfinished API and that mean if you worked with SFML2 then you should expect it to break every day. If complaining about this then you are either lazy or not worked in a industry product where refactoring is common work.

[Tex Killer]

Guess I was skipping too much after the browser swallowed my post twice. The reasoning of the quotation of mine was very simple in logic:
Since the current notation != camelCase, switching to camelCase -> breaking the current convention.

aquanull, imagine this:
Lets supose we are using some shitty convention that must be changed. All existing code will be broken, no mather which convention we choose to change for. This is no argument against camelCase, as any other convention would result in the same thing.

This will only count when deciding if the convention should or should not be changed, and Laurent said that this decision will be made later. But seriously, it is not very hard to change every first letter to lower case. Even the compiler would be pointing you to the right places to do that.

[Oberon]

But seriously, it is not very hard to change every first letter to lower case. Even the compiler would be pointing you to the right places to do that.

For small or medium size projects that might be true, but in large projects, where it can become a real pain, to fix everything. This could be automated with regular expressions and similar tools, but never 100% perfect: for example if a class which belongs to another library also has a member function Update() it will also be "fixed". That would lead to linker errors if the implementation is in a .lib/.a and linker errors usually dont't show a line number.

Personally, I like javaCase more than PascalCase, but I would still prefer to not break the API for no reason.

Although I've always been against it, and still thinks that it's an insane decision, I did it.

You sayed that it's "insane". You should ask yourself then why you do "insane" things, if you know they are insane.

[Tank]

Well it's time to show your IDE's power I guess (I'm really excited! So many people always saying "I use MSVC because it has teh toolz" ).

One thing that has to be clear is that changing a convention should indeed come from good reasons. If it's only personal preference, I wouldn't do it, because it means unnecessary work for all users just because you like the new thing more. I'm facing the same "problem" in SFGUI – to stay in touch with SFML I would have to change everything to javaWeirdStyle, but as my personal likings don't match it, I can either stay with the current one or choose my personally preferenced convention.

Some naming conventions in SFML have always been weird, like the previously mentioned sf::Vector::y against sf::Rect::Top (lower-/uppercase). Personally I also don't like the idea to name constants (e.g. of enums) and classes equally. That's one thing the new convention would solve, which is good.

I think one problem is that this topic wasn't discussed before being decided. Changing something "over night" () that affects EVERY SINGLE USER without discussing it can lead to heavier discussions thereafter. However sometimes hard cuts need to be made, and I'm fine with the new convention (the change, not what convention has been chosen), but if that's for very good reasons, I don't know.

[Laurent]

Some naming conventions in SFML have always been weird, like the previously mentioned sf::Vector::y against sf::Rect::Top (lower-/uppercase)

Yes, and this should be solved if I finally decide to keep the old naming conventions. But I really hate writing vec.X.
cameCase may look weird, I'm the first one to agree on that, but it's nice to be able to type one-word identifiers without hitting the shift key.

Personally I also don't like the idea to name constants (e.g. of enums) and classes equally. That's one thing the new convention would solve, which is good.

What do you mean? The new convention doesn't change how constants are named.

I think one problem is that this topic wasn't discussed before being decided

That was on purpose. Look: there are so many contradictory opinions that I'm now blocked.

[Tank]

but it's nice to be able to type one-word identifiers without hitting the shift key.

I doubt that's your reason. Else stick to lowercase everywhere.

What do you mean? The new convention doesn't change how constants are named.

So constants will be "fooBar", too? Eek..

I think one problem is that this topic wasn't discussed before being decided

That was on purpose. Look: there are so many contradictory opinions that I'm now blocked.

I wouldn't care of comments like "I don't like it, it's ugly!!!", just have good reasons to switch and everything's fine. After switching and another month everybody won't care anymore..