SFML community forums

General => General discussions => Topic started by: Laurent on January 07, 2012, 07:41:09 pm

Title: New naming convention
Post by: Laurent on January 07, 2012, 07:41:09 pm
Hi

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

Here are the new conventions:
- functions and public variables use the camelCase notation
- getters have no more get/is prefix

I've also changed class members: they use the 'm_' prefix instead of 'my' -- but this one has no impact on user code.

I did it mainly because:
- I didn't like the previous conventions anymore
- it's closer to the current global trend
- it makes functions like begin(), clear(), etc. compatible with std notation
- it allows a less verbose and globally nicer syntax

I'm really sorry for users who have a big amount of code based on SFML, or people who are using the same convention as me for their own library (SFGUI, Thor, ...). Feel free to complain or insult me :D

The good thing is that after pushing this modification (monday), I'll commit the new time API and SFML 2.0 can then be officially considered finished. And I promise, SFML 2.0 will be the beginning of a stable, robust and mature API.
Title: Re: New naming convention
Post by: Nexus on January 07, 2012, 07:44:59 pm
Quote from: "Laurent"
I'm really sorry for users who have a big amount of code based on SFML, or people who are using the same convention as me for their own library (SFGUI, Thor, ...). Feel free to complain or insult me :D
I think we will have enough opportunities to do this, once we start converting everything :D
Probably, I am going to adapt my convention, since Thor is an extension and my API is often very similar to SFML's. For SFGUI and other libraries, this looks differently.

It's indeed a little bit insane, but I'm curious how this will affect coding with SFML... ;)

By the way, did you use some script/regex/... for the renaming or have you just had too much free time recently? :P
Title: New naming convention
Post by: Laurent on January 07, 2012, 08:17:32 pm
Quote
By the way, did you use some script/regex/... for the renaming or have you just had too much free time recently?

Since I spend most of my coding time thinking about design issues rather than actually writing code, I tend to like this no-brainer stuff. It took me only a few hours ;)
Title: New naming convention
Post by: Tank on January 08, 2012, 08:48:27 am
Oh noes, Java-like function names. ;) (I've never got used to them, but that's personal preference).

It will be interesting for SFGUI. I wanted to drop CamelCase some day anyway, but I did not plan to move over to doThat actually. In my own projects I'm using lower_case (like the stdlib) and that will probably also be applied to SFGUI.

But in general: Good that you did it. Now it's time for some 'sed' runs. ;)
Title: New naming convention
Post by: Laurent on January 08, 2012, 10:01:27 am
Quote
In my own projects I'm using lower_case (like the stdlib) and that will probably also be applied to SFGUI.

I've read *many* blog articles and forum threads about camelCase vs lower_case, and I found that many developers have strong arguments against lower_case. That's why I ended up with camelCase.

Quote
But in general: Good that you did it

Oh, I didn't expect such a reaction :D
Why do you think that it's good?
Title: New naming convention
Post by: Grimshaw on January 08, 2012, 11:18:31 am
I loved the change! It will be absolutely worth it to adapt to this new change.. I've always been used to this convention, but when coding my games, there was such a big mix of different conventions..

Now everything can be looking the same, which is great :)
Title: New naming convention
Post by: texus on January 08, 2012, 11:18:35 am
Quote
functions and public variables use the camelCase notation

So the class names are still the same, right?
Title: New naming convention
Post by: Laurent on January 08, 2012, 12:28:01 pm
Quote
So the class names are still the same, right?

Yep.
Title: New naming convention
Post by: Marukyu on January 08, 2012, 04:25:42 pm
Now that's going to be a lot of code to rewrite and it'll take a while for me to get used to it. ~_~
Hopefully I'll find a way to do this with regular expressions. I could never figure out how to use sed, a little help with this would be appreciated. :)
Title: New naming convention
Post by: aquanull on January 08, 2012, 04:55:22 pm
Wow, I didn't expect to have my first post here in this fashion, but:

Quote from: "Laurent"
I did it mainly because:
- I didn't like the previous conventions anymore
- it's closer to the current global trend
- it makes functions like begin(), clear(), etc. compatible with std notation
- it allows a less verbose and globally nicer syntax

Most of the reasons are lousy. In detail:

"- I didn't like the previous conventions anymore"
The only sane reason. So you consider something that you have always been against better than something you didn't like? :roll:

"- it's closer to the current global trend"
By "the current global trend" you mean the more confusing javaCase and Get-/Is- omission? But look, you hear they talking about something like "HTML5 is taking over ground and will dominate the industry and thus HTML5 IS THE FUTURE and the world is moving towards it" so it is HTML5 that is "the global trend", isn't it? If so, why not modify the lib for HTML5?
Oh, were they also talking about something like "JVM/.Net/Ajax/<INSERT_RANDOM_TECH_HYPE> IS THE FUTURE"? Never mind. :twisted:

"- it makes functions like begin(), clear(), etc. compatible with std notation"
Are they compatible with std usage? If not, why should they impersonate something just different? And again, this javaCase != the dreaded lower_case naming convention that std uses, so that's not a success. :wink:

"- it allows a less verbose and globally nicer syntax"
How could changes in the naming convention affect the syntax? You don't mean to use some grotesque C preprocessor # macro tricks for an alternative syntax, do you? :shock:

Seriously, there is a reason (might seem weak but still standing) for me to oppse the javaCase + omitted-Get-/Is- notation for functions:
Code: [Select]

class A
{
public:
    // camelCase + omitting Get-
    int publicProperty0;
    int &publicProperty1() { return m_value1; }
    int publicProperty2;
    // PascalCase and I actually like it for function naming
    int &GetPublicProperty1() { return m_value1; }
    int GetPublicPropertyCount() { return 3;}
private:
    int m_value1;
};

void foo()
{
    using namespace std;

    A someVar; // I always use camelCase for variable names

    cout << someVar.publicProperty0 << endl;
    cout << someVar.publicProperty1 << endl; // SYNTAX ERROR thanks to misleading name
    cout << someVar.publicProperty1() << endl; // OK but inconsistent syntax
    cout << someVar.publicProperty2 << endl;
    cout << someVar.GetPublicProperty1() << endl; // OK
    cout << someVar.GetPublicPropertyCount() << endl; // OK and consistent
}

class B
{
public:
    bool empty(); // Is- omitted, so guess what this does - remember STL's similar flaw?
    bool Empty() { return m_container.remove_all_elements() == SUCCESS_OK; } // you see?
    bool IsEmpty() { return m_container.count_elements() == 0; }
private:
    SomeContainer m_container;
};


As you may see, since C++ doesn't support C#-ish properies, it has to use member functions whose invoking syntax is different from C#-ish properties', and trying to mimic that imperfectly may lead to syntax (class A example) and sematic (class B example) errors.  Further more, AFAIK, many C++ coding standards require that every function name should contain a verb. So I don't think this naming convention change (except that of class internal members) is the right move.

Still, it's good to know that SFML 2.0 has finally been finished (or close to finished if you are going to change the naming convention again after reading this post). Good job! :D
Title: New naming convention
Post by: Laurent on January 08, 2012, 07:44:45 pm
Quote
"- I didn't like the previous conventions anymore"
The only sane reason. So you consider something that you have always been against better than something you didn't like?

This decision is insane, but once it's done I'll feel much better when working on SFML. So yes, in this case I'm ready to do something that I've always been against.

Quote
By "the current global trend" you mean the more confusing javaCase and Get-/Is- omission? But look, you hear they talking about something like "HTML5 is taking over ground and will dominate the industry and thus HTML5 IS THE FUTURE and the world is moving towards it" so it is HTML5 that is "the global trend", isn't it? If so, why not modify the lib for HTML5?

By "global trend" I really mean global trend: ie. what most people use. You may not like it, but it is what people prefer on a global scale.
And that was not the reason why I changed, I never do something just because other people do it . But now that it's done, it's a good argument ;)

Quote
"- it makes functions like begin(), clear(), etc. compatible with std notation"
Are they compatible with std usage?

Of course they are.

Quote
And again, this javaCase != the dreaded lower_case naming convention that std uses, so that's not a success.

Fortunately, the functions that need to be compatible with std notation only contain one word, so they look the same as if I were using lower_case notation.

Quote
"- it allows a less verbose and globally nicer syntax"
How could changes in the naming convention affect the syntax?

I just meant that code that uses SFML now looks less verbose and nicer. I don't know what you mean with your "preprocessor macros tricks".

Quote
As you may see, since C++ doesn't support C#-ish properies, it has to use member functions whose invoking syntax is different from C#-ish properties', and trying to mimic that imperfectly may lead to syntax (class A example) and sematic (class B example) errors

Yes, that's why I try to use this notation in a "perfect" way. I never mix public variables and public functions in the same class (there's only one exception in the SFML API). However I admit that omitting is/get can lead to ambiguity because in english, a verb and its corresponding noun can be identical. But that's not a big issue to me, once you know what the function does, or if you read the doc / tutorials before coding, everything should be ok.

Quote
Further more, AFAIK, many C++ coding standards require that every function name should contain a verb

Not mine, fortunately :)

Quote
Still, it's good to know that SFML 2.0 has finally been finished (or close to finished if you are going to change the naming convention again after reading this post).

Don't tempt me, it was really hard for me to take this decision ;)

Thanks for your detailed feedback.
Title: New naming convention
Post by: Laurent on January 08, 2012, 07:49:47 pm
I forgot one thing: this naming convention (except the omission of the "is" prefix) is taken from the Qt library, which is a huge library used by a huge amount of developers, and I think that it works pretty well for them so far. I'm not inventing anything.
Title: New naming convention
Post by: Groogy on January 08, 2012, 08:34:00 pm
I hope you sneezes every-time I swear at your name xD

No it's not that bad, it could be worse. You could have used snake notation or even worse... HUNGARIAN!? At least it was something sensible.

Anyway imagine something like.. Every half-hour between 18:00 to 00:00 me yelling loudly: "DAMN YOU LAURENT!" waving my hand in the air.

Just for lulz :D
Title: New naming convention
Post by: Laurent on January 08, 2012, 08:43:23 pm
Yeah, I can easily imagine that. I was expecting it :D
Title: New naming convention
Post by: Grimshaw on January 08, 2012, 09:07:07 pm
I used Qt massively too, and it worked just fine for me, this change makes all the sense.. Not that it was bad before, but there is room for improvement..

Nice work Laurent! And good job on sfml2 , on what it became so far, i was impressed when i updated it yesterday!
Title: New naming convention
Post by: Groogy on January 08, 2012, 09:40:24 pm
Though before you had the same standard as my workplace which kind of makes me sad now but I think I like this one more. Though I tend to work with more dynamic languages where methods are not constant, and I denote a constant by starting it with a capital letter. Though in C++ the functions/methods are constant which bums me out =/
Title: New naming convention
Post by: Tex Killer on January 08, 2012, 10:19:05 pm
I think this was a great decision. The difference between a class name and a class member is now clear.

The only change I would like would be the get/is put back in, as they help understanding the meaning of those functions.

Overall, you have my endorsement on this.
Title: New naming convention
Post by: Tank on January 08, 2012, 11:44:15 pm
Quote
Oh, I didn't expect such a reaction  
Why do you think that it's good?

Hehe, I knew it sounds weird, especially from me. What I actually mean is that it's good to do such decisions. The previous conventions were okay, except in some places where they were inconsistent (like sf::Vector::y and sf::Rect::Left).

Of course personally I'm rolling my eyes because I don't get the idea why I'd always write the first word in lowercase. But as I said, that's personal preference and I think we really have more serious problems than getting used to a coding style a library uses that one wants to use in his projects.

Besides of naming conventions libraries do error checking etc. differently which you have to take care of, too. So you will always have to stick to a library's rules in order to use it (right).

So +1 for the courage of doing it (such changes make the whole userbase scream because it involves annoying search&replace (except you know your tools ;)) and keeping the sources at a consistent level, even with your personal preference (which is good since you're doing 99% of the code), but -1 for choosing the lame Java style. ;)
Title: New naming convention
Post by: gsaurus on January 09, 2012, 12:23:56 am
I never thought you would change your mind after all the discussion on the forum :lol: I'm glad that you did - except for the is/get omission. I never heard about this convention before, but that's not the reason why I question it.

Quote from: "Laurent"
I admit that omitting is/get can lead to ambiguity because in english, a verb and its corresponding noun can be identical. But that's not a big issue to me, once you know what the function does, or if you read the doc / tutorials before coding, everything should be ok.

What happened to the Simple keyword? The name of a function should suggest and recall what it does as much as possible, while keeping it short so it's easy to read and fast to type.
In the particular case of getters/setters I don't see any advantage of making syntax shorter by omitting the get/is. Getters/setters tend to be so intuitive that you don't even need to read the documentation to know what it does. When reading code the get/is prefixes give you an immediate idea of what's going there, in particular it recalls you that it's just a getter, const and safe.
I think that those prefixes are simpler than omitting them, I don't see a good reason to omit them
Title: New naming convention
Post by: Contadotempo on January 09, 2012, 01:02:41 am
I understand you want an homogeneous vocabulary between C++'s std and SFML but please don't get rid of the set/gets.
It's really convenient when you're using an IDE with intellisense like in Visual Studio. You just need to write "get" and boom, you get all the get functions for the class you're working with.  
But either way, excellent work so far.  :)
Title: New naming convention
Post by: aquanull on January 09, 2012, 08:04:18 am
Quote
This decision is insane, but once it's done I'll feel much better when working on SFML. So yes, in this case I'm ready to do something that I've always been against.


Guess I'd try harder with casuistry! :wink:

Quote
By "global trend" I really mean global trend: ie. what most people use. You may not like it, but it is what people prefer on a global scale.
And that was not the reason why I changed, I never do something just because other people do it . But now that it's done, it's a good argument ;)


You should distinguish "what has been being used" from "what is likely going to be used" - the former is the current situation, and the latter is the trend. History teaches us that there has never been and will unlikely ever be a unification of choices, and logically the trend is to diverge from what we have had currently. If the current situation  is that most people have been using the javaCase, then the real trend is for them to move onto something different i.e. not javaCase. Thus you didn't really make it to catch up with the trend. :wink:

Quote
I just meant that code that uses SFML now looks less verbose and nicer. I don't know what you mean with your "preprocessor macros tricks".

The only way besides using vendor-language-extensions to "allow" a different C++ syntax is to abuse the C/C++ preprocessor, and I was referring to it. Now I see by "syntax" you meant "look", so never mind.

Quote
Yes, that's why I try to use this notation in a "perfect" way. I never mix public variables and public functions in the same class (there's only one exception in the SFML API). However I admit that omitting is/get can lead to ambiguity because in english, a verb and its corresponding noun can be identical. But that's not a big issue to me, once you know what the function does, or if you read the doc / tutorials before coding, everything should be ok.

I forgot one thing: this naming convention (except the omission of the "is" prefix) is taken from the Qt library, which is a huge library used by a huge amount of developers, and I think that it works pretty well for them so far. I'm not inventing anything.


I agree with gsaurus (which would imply that I disagree with you) on this matter. And I never liked javaCase (specifically, camelCase for function naming), no matter whther it is used widely or not, as this convention UN-emphasizes the first word (usually the verb) that is in most cases the most important sematic element in the whole function name.

As a side note: I always believe the truth why javaCase was invented is because when there were (and perhaps are still) only slow Java(TM) IDEs to use, they were limited to do cAsEsEnSiVe checks (always faster than cAsE-iNsEnSiVe checks) for not-too-slow-auto-code-completion, so by making the first several letters of class member names lower-case, the code-completion could struggle to prove their usefulness to lazy coders who didn't bother to press CapsLock or Shift key. Nowadays IDEs should be capable of making cAsE-iNsEnSiVe checks anyway, so I don't think there is such a "compelling" reason for lazy coders anymore.

Quote
Don't tempt me, it was really hard for me to take this decision ;)

I really believe that you are capable of taking harder decisions. :wink:

Quote
Thanks for your detailed feedback.

You are welcome.
Title: New naming convention
Post by: Tex Killer on January 09, 2012, 08:38:25 am
Quote from: "aquanull"
As a side note: I always believe the truth why javaCase was invented is because when there were (and perhaps are still) only slow Java(TM) IDEs to use, they were limited to do cAsEsEnSiVe checks (always faster than cAsE-iNsEnSiVe checks) for not-too-slow-auto-code-completion, so by making the first several letters of class member names lower-case, the code-completion could struggle to prove their usefulness to lazy coders who didn't bother to press CapsLock or Shift key. Nowadays IDEs should be capable of making cAsE-iNsEnSiVe checks anyway, so I don't think there is such a "compelling" reason for lazy coders anymore.

The reason I see for using this convention is to make class names different than function and variable names, making it easy to know what is happening. camelCase() is a function, camelCase is a member variable, and CamelCase is a class name.
Title: New naming convention
Post by: aquanull on January 09, 2012, 08:48:20 am
Quote from: "Tex Killer"
The reason I see for using this convention is to make class names different than function and variable names, making it easy to know what is happening. camelCase() is a function, camelCase is a member variable, and CamelCase is a class name.

I've been using camelCase for variable names and I think that could help avoid some syntax errors, but what is the reason to make function names (more) different from class names if you ensure that only function names can contain a verb? And if you just use camelCase for both variable and function names you may run into confusions as I demonstrated earlier in the thread.
Title: New naming convention
Post by: Hiura on January 09, 2012, 08:54:41 am
Just wanted to express my mind about the is/get thing. (I won't talk about camelCase in general because it's too subjective I guess – but I like it!)

This is still a personal opinion, however I might convince some of you guys that it doesn't stink as much as you can think ! :)


- "isSomething(param)" represents a query that needs some (more or less expensive) computation like isPrime(n). This kind of function is not present in SFML API.

- "something()" is not a query : it just return the property "something" of the object which is a known state and doesn't require much computation. This property can be of type Boolean, of course.

- "someVerbInTheThirdPerson(param)", like "intersects(rect)", is a query like "isSomething(param)". This works with some specific verbs only, like to intersect, but not with to move. (I don't know if there is a name for such categories of verbs in English.)

Some verbs are also nouns/adjectives (like empty) which make room for ambiguity. This is the only issue I see here.

You can have a look at most (if not all) the functions concerned by this new naming convention here (http://www.sfml-dev.org/documentation/2.0/functions_0x69.php#index_i). As you can see the dilema has not a huge impact on the overall functions.
Title: New naming convention
Post by: BMB on January 09, 2012, 09:32:04 am
Quote from: "Hiura"
You can have a look at most (if not all) the functions concerned by this new naming convention here (http://www.sfml-dev.org/documentation/2.0/functions_0x69.php#index_i). As you can see the dilema has not a huge impact on the overall functions.


There are a lot more here (http://www.sfml-dev.org/documentation/2.0/functions_0x67.php#index_g)
Title: New naming convention
Post by: Hiura on January 09, 2012, 11:00:01 am
yeah, I was speaking about Is* functions.

GetSomething or something is exactly the same, one is just more verbose than the other. That's it.

Moreover, one can argue that Get* is more confusing : one might think that the function queries someone/something. But I guess this is not really an issue because everyone is used to this notation.
Title: New naming convention
Post by: Ceylo on January 09, 2012, 05:00:02 pm
Quote from: "Hiura"
- "isSomething(param)" represents a query that needs some (more or less expensive) computation like isPrime(n). This kind of function is not present in SFML API.

according to what ?

To me there is nothing related computation for the "is" prefix. It's just supposed to ask "is that true?" whatever computation needs to be done in the background.


The is, get, set prefixes help at focusing on the algorithm rather than on "how to use that library" or "is it really doing what I guess? should I check every call in the documentation?". Saying "you just have to look at the documentation the first time" isn't a good argument to me. Because you actually have to look at the documentation every time you can't remember (which is much more that once in a few years).

The best naming convention is the one that is the most explicit in the most concise way. An ambiguity or interrogation (and the time required to check the documentation) is too much priced for 2 or 3 letters.


P.S.: just my opinion though.
Title: New naming convention
Post by: aquanull on January 09, 2012, 05:05:28 pm
Quote from: "BMB"
There are a lot more here (http://www.sfml-dev.org/documentation/2.0/functions_0x67.php#index_g)

Many nouns there are also valid verbs, such as center, loop, scale, view etc. They could be ambiguous.
Title: New naming convention
Post by: Laurent on January 10, 2012, 10:20:10 am
The arguments in favor of the get/is prefixes make sense -- except that I'll never write getBegin()/getEnd() in a container ;)

And since nobody gave good arguments against them, I guess that it's really a bad decision. I still have to think about the final decision, but thanks for making it even harder than it was already :mrgreen:
Title: New naming convention
Post by: Nexus on January 10, 2012, 12:44:59 pm
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.
Title: New naming convention
Post by: Laurent on January 10, 2012, 01:43:56 pm
Quote
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.
Title: New naming convention
Post by: bastien on January 10, 2012, 03:24:02 pm
Quote from: "Laurent"
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
Title: New naming convention
Post by: Laurent on January 10, 2012, 03:46:59 pm
Quote from: "bastien"
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.
Title: New naming convention
Post by: Tex Killer on January 10, 2012, 08:38:44 pm
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.
Title: New naming convention
Post by: V0idExp on January 11, 2012, 11:23:13 am
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:
Title: New naming convention
Post by: aquanull on January 11, 2012, 03:09:58 pm
Quote from: "Laurent"
Quote
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::.

Quote
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.
Title: New naming convention
Post by: Laurent on January 11, 2012, 03:27:21 pm
Quote
* 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).

Quote
* 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.

Quote
* 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.

Quote
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 ;)
Title: New naming convention
Post by: N1ghtly on January 11, 2012, 06:41:04 pm
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...
Title: New naming convention
Post by: aquanull on January 11, 2012, 07:08:58 pm
Quote from: "Laurent"
Quote
* 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);
}

//...


Quote from: "Laurent"
Quote
* 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. 8)

Quote from: "Laurent"
Quote
* 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...

Quote from: "Laurent"
Quote
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.
Title: New naming convention
Post by: Groogy on January 11, 2012, 07:34:18 pm
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.
Title: New naming convention
Post by: Tex Killer on January 11, 2012, 08:56:20 pm
Quote from: "aquanull"
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.
Title: New naming convention
Post by: Oberon on January 11, 2012, 09:52:27 pm
Quote from: "Tex Killer"
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.

Quote from: "Laurent"
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.
Title: New naming convention
Post by: Tank on January 13, 2012, 08:35:09 am
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.
Title: New naming convention
Post by: Laurent on January 13, 2012, 09:01:35 am
Quote
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.

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

Quote
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.
Title: New naming convention
Post by: Tank on January 13, 2012, 11:49:05 am
Quote from: "Laurent"
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. ;)

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

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

Quote
Quote
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.. ;)
Title: New naming convention
Post by: Laurent on January 13, 2012, 12:22:49 pm
Quote
I doubt that's your reason. Else stick to lowercase everywhere.

That's one of the reasons.
Since it seems widely accepted that class naming must be different from function/variable naming, we still need some uppercase.

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

Hmm no, constants will be "FooBar", so it's still the same as before (that's what I said above) and they are named like classes (that's what you thought the new convention would "solve" -- and it doesn't) ;)

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

I know, and I don't take "I like/don't like" arguments in account. But there are also good arguments on both sides.
Title: New naming convention
Post by: Klaim on January 13, 2012, 03:44:33 pm
Laurent, can you point me to the articles agains this_notation online? Last time I searched I was finding lot of people saying it's more readable and forced the writer to be concise (because it big faster).
Title: New naming convention
Post by: Laurent on January 13, 2012, 04:28:31 pm
Quote
Laurent, can you point me to the articles agains this_notation online? Last time I searched I was finding lot of people saying it's more readable and forced the writer to be concise (because it big faster).

I'll try to find them back.

As far as I remember, arguments against lower_case were that while it is easier to see word boundaries inside an identifier, it is harder to see identifier bounds. An extreme example that I've seen:
Code: [Select]
the_third_number=the_first_number-the_second_number;

People often say that if you convert a text to lower_case it's more readable than camelCase. Which is true, but code is not text. What must catch the eye is identifiers, not individual words.

That's what I've read -- not my personal opinion.
Title: New naming convention
Post by: Mikademus on January 13, 2012, 11:25:23 pm
Let's be logical.

1) Consistency is the paramount item of importance. SFML today isn't consistent (f.i. the rect and vector members, which drives f.i. me to distraction).
2) Changing anything for consistency will break code.
3) If breaking code, it is better to make everything consistent while at it rather
than retain inconsistencies or break a bit more with every update.
4) SFML2 is already broken versus 1.6 and many previously installed 2.0 builds. Therefore, there is no better time to fix what needs to be done than now since clients will need to redress their code for 2.0 compatibility anyway.

That is logical. Now, let's change to subjectives, popular impressions and trends.

SFML's current PascalCase is actually a common (as in "occurring" rather than ubiquitous) argument against it, as in when questions about pros and cons of different systems are asked on fora, the code convention of SFML is a recurring drawback.

Compared to the vast majority of current and widespread middleware solutions the convention is apart and SFML code stands out as deviant against other code in a project pulling in several libraries. This goes against the principle of consistency. Just as Laurent says, the trend is definitely for Class::camelCase, void Class::camelCase() and void CamelCase() code formatting.

From a pedagogical perspective, camelCase creates clear and immediate visual distinctions between classes, members, methods and free functions.


For me, Laurent's announcement was a very welcome birthday present, and from a non-subjective perspective I think it is a the correct way forward.
Title: New naming convention
Post by: Klaim on January 14, 2012, 10:06:39 pm
Quote from: "Laurent"
Quote
Laurent, can you point me to the articles agains this_notation online? Last time I searched I was finding lot of people saying it's more readable and forced the writer to be concise (because it big faster).

I'll try to find them back.

As far as I remember, arguments against lower_case were that while it is easier to see word boundaries inside an identifier, it is harder to see identifier bounds. An extreme example that I've seen:
Code: [Select]
the_third_number=the_first_number-the_second_number;

People often say that if you convert a text to lower_case it's more readable than camelCase. Which is true, but code is not text. What must catch the eye is identifiers, not individual words.

That's what I've read -- not my personal opinion.


Yes I understand, let's be courteous about it.

That's interesting because I have another rule that I use in all languages that makes this problem not be a problem : always bound operators with spaces (even in Python) :

Code: [Select]
the_third_number = the_first_number - the_second_number;

Make things more readable in general. Another rule that I use most of the time is to always put spaces after ( or { or [ and before ) or } or ] . That way :

Code: [Select]
the_numbers[ 2 ] = the_numbers[ 0 ] - the_numbers[ 1 ];

Also, I find that knowing that the graphic size of the name will grow fast with more words, it helps getting more to the point (often not more than 2 words) :

Code: [Select]

numbers[ 2 ] = numbers[ 0 ] - numbers[ 1 ];

auto k = build_variant( numbers );
k.clear();
k.resize( 42 );



Anyway, as far as you keep a consistent code formatting policy, I'm happy :)
Title: New naming convention
Post by: mateandmetal on January 14, 2012, 10:16:27 pm
I think the "Is/Get" syntax makes SFML more easy to learn for the beginners
Title: New naming convention
Post by: Svenstaro on January 17, 2012, 04:36:56 am
I support Laurent's proposed changes for his exact reasoning. I use a lot of Qt and it would make my code feel more consistent.
Title: New naming convention
Post by: Sind on January 17, 2012, 05:35:00 pm
Just dropping by to state that I support using camelCase.
Though no, I don't actually have any proper argument as to why, other than that I prefer it <.<
Title: New naming convention
Post by: Oberon on January 17, 2012, 06:19:45 pm
Hah! :D I finally found a very practical reason for camelCase!
Code: [Select]
#include <Windows.h>
Every WinAPI function is #defined so that namespaces, scope, etc. are rendered useless. For example the really existing code
Code: [Select]

#ifdef UNICODE
#define GetTextMetrics  GetTextMetricsW
#else
#define GetTextMetrics  GetTextMetricsA
#endif // !UNICODE

will change the hypothethically code myText.GetTextMetrics() to myText.GetTextMetricsW() (or myText.GetTextMetricsA()), causing compiler or linker errors or "function not found in DLL" errors.
There are also lots of other dangerous names like LoadImage, LoadIcon, PeekMessage, ...
So if SFML's names do not clash with them, user code which does not want to mix in yet another naming style might get problems when using native WinAPI.
Microsoft uses PascalCase everywhere (except for the infamous min/max macros) so with camelCase SFML users wouldn't face this problem.
Title: New naming convention
Post by: Laurent on January 17, 2012, 06:23:25 pm
Most (if not all) SFML users won't use the Windows API directly. And SFML does its best to avoid including <windows.h> in its own public headers.
Title: New naming convention
Post by: Oberon on January 17, 2012, 06:38:45 pm
I think using native Windows API and SFML together is not that uncommon: For example, if I wanted to program a screensaver in SFML I had to use WinAPI, because for the preview I get a window handle which I have to use as the parent for my window.

To illustrate:
(http://ezcodesample.com/screensaver/scr.jpg) (random screenshot found with Google).
In this image, the program "ScreenOGL.scr" was started with eg. /p:12345, where 12345 is the handle of the parent window.

And after all, there is even the win32 example included in SFML.
Title: New naming convention
Post by: Laurent on January 17, 2012, 06:46:34 pm
How many of the SFML users are developing a Windows screensaver? ;)

There might be developers that mix Win32 and SFML, but they are a very little minority, so this argument in favor of camelCase is not really significant.

And how many SFML functions collide with Windows ones? Probably none.
Title: New naming convention
Post by: Beta_Ravener on January 17, 2012, 11:30:09 pm
What about different view angle?
Ask a question, what notation you were teached? I could find just two naming conventions for C++: some_function and SomeFunction. The first is used by standard and we can find this convention also in cplusplus.com tutorials. The later is wide-spread in c++ books, but there are still some that stick with some_function. But I never saw anyone teaching camelCase notation. It seems to me as a crazy attempt to shorten some_function.

My argument would be that in my case I use openGL alot with SFML. Their notation is based on camelCode, but the first word is always gl, rendering the rest as CamelCode notation. When writing wrappers around some openGL functions, it was always convenient just to omit gl. It's still my personal preference though.

As already wrote, ambiguity will always exist by not using underlines.. either between classes and functions or functions and variables. There's no gain in changing this. QT have strong user base, but so does have SFML and many projects that decided to align with it's style. It's not a question of laziness, but of wasted time that could be spent better (as with the time I spent to write this  :) ). SFML might change it's notation, but I'll be really interested in how other projects will answer to this issue. And I'm fully aware that SFML 2.0 is only for testing and indeed some changes break the code every time, but this will be huge.

As for the gets/is/sets the advantage of uniform working with member data is too small as it can be compared with fast navigation in intellisense/discovery/(whatever..), but there is great comprehensive value in those few characters. If we'd like to go down to standard we should really think about what bastien posted about quasi classes. Indeed the std::string has .length() and not .GetLength(), but it doesn't use .length(int newLength) [as opposed to .SetLength() ]  but .resize() . I think omitting those few characters will just confuse people, and add more visits to your site  :D
Title: New naming convention
Post by: Bobomite on January 18, 2012, 01:06:19 am
I am a novice to C++ and I'm using SFML to learn and found that it's powerful enough I'm just going to focus on making 2D games for now.

Coming from a web development background, I will definitely say that the move to camelCase is something I like a lot, we use that for everything at work in JavaScript.  Personally I find it easier on the eye than the alternatives.

As to removing get/set I actually liked that I knew what the function did by name and not by what t passed.  But I don't consider that a problem either way, because to use the function I need to have a reason/know why I am using it and by default if I am passing in (say) a Vector2d I am almost certainly setting it anyway.

And I'm lucky in that cleaning all my code will probably take like 20min tops.
Title: New naming convention
Post by: mateandmetal on January 19, 2012, 04:27:05 am
Quote from: "Laurent"
...And SFML does its best to avoid including <windows.h> in its own public headers.


 8)  8)  8)
Title: New naming convention
Post by: pacifistcottage on January 20, 2012, 03:32:34 pm
Hi Laurent,

I registered this account after being a long-time lurker just to weigh in on this topic, so consider this one more vote in favor of camelCase function/method names. Just a personal preference, but it's the way I like it.

However, I would personally prefer if the "get/set/is" naming convention stayed. I really like just being able to type "get" in an IDE, and immediately being able to see all possible things you can... well... get from a class, all neatly in same place (and likewise with "set").

It's all pretty small potatoes, though. As long as the API stays awesome, I can adapt to whatever naming conventions you are most comfortable with.
Title: New naming convention
Post by: tobybear on January 20, 2012, 03:43:15 pm
Quote from: "pacifistcottage"
Hi Laurent,

I registered this account after being a long-time lurker just to weigh in on this topic, so consider this one more vote in favor of camelCase function/method names. Just a personal preference, but it's the way I like it.

However, I would personally prefer if the "get/set/is" naming convention stayed. I really like just being able to type "get" in an IDE, and immediately being able to see all possible things you can... well... get from a class, all neatly in same place (and likewise with "set").

It's all pretty small potatoes, though. As long as the API stays awesome, I can adapt to whatever naming conventions you are most comfortable with.

This is also my opinion :-)
Title: New naming convention
Post by: Laurent on January 20, 2012, 06:09:12 pm
Thanks for sharing your opinions.

camelCase + get/is should be my final decision.
Title: New naming convention
Post by: AdventWolf on January 20, 2012, 06:40:43 pm
I agree, the get/is prefix is very useful and I've never thought that it made the library look unprofessional or sub par compared to others. If anything it makes the library seem more simple to use and user friendly.
Title: New naming convention
Post by: Nexus on January 20, 2012, 07:38:36 pm
Quote from: "Laurent"
camelCase + get/is should be my final decision.
It would be a pity if you really chose this. You break every code for a naming convention which you recently didn't even consider the best one, and of which you admit yourself that it has no decisive advantages over PascalCase. Actually, the only argument for it is to go with the flow -- what is far from justifying the high price in my opinion.

I am personally not a fan of the Qt style either, but at least I could understand its choice much more, since it actually changes something.

By the way, what if you named public variables with camelCase, and left functions in PascalCase? Then you would get rid of the x/Left inconsistency.
Title: New naming convention
Post by: Tex Killer on January 20, 2012, 08:33:29 pm
Since SFML2 is not even officially released yet, I don't think "breaking code" is a valid argument.

If you are coding things on top of an unfinished release, you should know that code will be broken all the time.

What are the real arguments for the CamelCase convention? Breaking code is not one, so I want to know the others.
Title: New naming convention
Post by: Nexus on January 20, 2012, 09:10:34 pm
Quote from: "Tex Killer"
Since SFML2 is not even officially released yet, I don't think "breaking code" is a valid argument.
Many people already work with SFML 2, not at least because it was often recommended and declared "almost finished" or "more stable than SFML 1.6". The modification comes unexpected for a big number of users. Furthermore, it makes it even more difficult to port code from SFML 1.6. I find it a bit narrow-minded to ignore these facts just because the release is not official yet, even more in consideration of the tiny advantages the new naming convention would entail.

Quote from: "Tex Killer"
What are the real arguments for the CamelCase convention?
If we plan to change something, shouldn't we rather think about "real" arguments for the new state and against the old one in order to justify the modification?
Title: New naming convention
Post by: Mikademus on January 20, 2012, 11:01:23 pm
My existing library code will already be broken next time I download SFML2 trunk due to numerous breaking changes in the API, and I am resigned to and accepting of this, so
(1) I agree with Tex Killer (and myself as per above) that "not breaking existing code" is an irrelevant and misleading statement,
(2) I welcome the chance to make my SFML code consistent with my other 3rd party code and make all my library code consistent,
(3) Alpha code is in development and even should change for the better, which for--again--reasons given above camelCase is in every single comparative aspect.
Title: New naming convention
Post by: Tex Killer on January 21, 2012, 05:58:19 am
Nexus, these were already given, as stated by Mikademus.

Why would you like to maintain CamelCase convention, aside from "breaking code"? Is there something better in it than in camelCase? Something at all?
Title: New naming convention
Post by: Teemperor on January 21, 2012, 10:03:59 am
Quote from: "Laurent"

camelCase + get/is should be my final decision.


a big +1 to this decision from my side.
Title: New naming convention
Post by: Ceylo on January 21, 2012, 02:27:42 pm
Quote from: "Nexus"
Quote from: "Tex Killer"
What are the real arguments for the CamelCase convention?
If we plan to change something, shouldn't we rather think about "real" arguments for the new state and against the old one in order to justify the modification?

In my opinion, no need to use Shift for the first letter + consistency with third party libraries are good reasons.

And as stated above, even if the naming convention does not change, code will be broken. Plus, if SFML should change its naming convention, it's now or "never".

I support Laurent's "probably final" decision.
Title: New naming convention
Post by: julen26 on January 21, 2012, 02:34:50 pm
Quote from: "Ceylo"
Plus, if SFML should change its naming convention, it's now or "never".


Completely agree.
Title: New naming convention
Post by: Groogy on January 22, 2012, 01:00:13 am
So this is more or less definite? Can I base the binding on it? (Naming of my class methods) on this convention?
Title: New naming convention
Post by: BMB on January 22, 2012, 08:25:39 am
Quote from: "Laurent"
Thanks for sharing your opinions.

camelCase + get/is should be my final decision.


+1

camelCase for no other reason then personal preference (I don't feel any of the above mentioned reasons is really very strong, but I just like it)

get/set/is for making code very clear
Title: New naming convention
Post by: pdinklag on January 22, 2012, 09:06:39 am
I, coming from the Java corner, can only support the camelBack (called camelCase here, heh) convention as well as getX/isX getters and setX setters.

It's hard to argue with anything other than personal preference, so I will not try and go there...
Title: New naming convention
Post by: Laurent on January 22, 2012, 10:59:06 am
Quote
So this is more or less definite? Can I base the binding on it? (Naming of my class methods) on this convention?

You should wait until it's actually done. Anything can happen :D
Title: New naming convention
Post by: Dravere on January 22, 2012, 04:07:58 pm
Naming conventions are always completly personal preference. And to be honest what you choose normaly doesn't really matter much. I worked with several different naming conventions over time. The one main thing for me is rather consistency.

When you work in C++ you will work with the C++ stdlib and Boost. Now you know which naming convention you have to use. Always go with the naming convention for public members of the standard library of your language.

I use camelCase in java.
I use PascalCase in C#.
I use camel_case in C++.

Even if I don't really like camel_case, I'm undecided about PascalCase and I like camelCase. It doesn't matter what my personal preference is. I can read all three without problems. But it is really annoying if you have no consistency in source code.

If you decide against the naming convention of the c++ stdlib, you will never ever have consistency in any program written with SFML.
Title: New naming convention
Post by: Groogy on January 22, 2012, 04:25:16 pm
Quote from: "Dravere"
If you decide against the naming convention of the c++ stdlib, you will never ever have consistency in any program written with SFML.


Well not really, I rarely use the standard library. So for me I have a lot of consistency. And with the new convention we will be pretty close as most of the functions in the standard library is only one word long. Sure there will be a few exceptions but overall it will look pretty decent. Except that the std classes will be lower-case.
Title: New naming convention
Post by: Dravere on January 22, 2012, 05:07:45 pm
@Groovy,
There is no half consistency. Like you said, there will be for example no consistency in the naming of classes.

And you only rarely use the standard library? std::vector? std::string? iostreams? std::unique_ptr? std::shared_ptr? And what about boost? What are you using instead?
Title: New naming convention
Post by: Groogy on January 22, 2012, 05:47:52 pm
Quote from: "Dravere"
And you only rarely use the standard library? std::vector? std::string? iostreams? std::unique_ptr? std::shared_ptr? And what about boost? What are you using instead?


std::string and stream is about the only thing I use actually. I never use the smart pointer classes. And my got my own data structure classes. And even then when it comes to string and stream. I never even use them as I have most of my strings hashed. You could see them as being an external interface. Whenever something is going out or in from the application it goes trough those classes. Otherwise I don't use it.

NOTE: And no this is not a stupid "Do it yourself" idea I have. It's just that I actually needed to remake those for my project so that they used my automatic debug system, etc. etc. So I did it out of necessity and comfort. Plus some missing functionality is added in my own custom ones.
Title: New naming convention
Post by: model76 on January 22, 2012, 06:18:15 pm
I support Laurent's decision to use camelCase for the following reasons:

I would suggest using lower_case for the reason Dravere did, was it not for the fact that lower_case is the least ergonomic style there is. All those underscores makes it really uncomfortable to type.

PascalCase is also nicely readable, as well as (objectively) good looking, but not as ergonomic as camelCase, although much better than lower_case.

I would also suggest that you change the convention for member variables from m_value to mValue. Not that it will have any effect on the user code, though.

I can understand the people who wants to keep the current style. It isn't always comfortable when things change, and you have to change with them. Especially if that means having to do a lot of work unexpectedly.
However, as others have said, I feel that this is the best time there will ever come to rip the band-aid and get it over with. There may well never be another chance.

As for get/set/is, well, I really think they are needed to make the library easy to use. Documentation is good, but clear code is better. I think these little words will save a lot of people from having to refer back to the documentation too frequently. Also, get/set/is ties in very nicely with the code completion functionality of various IDEs.
Title: New naming convention
Post by: Tex Killer on January 22, 2012, 07:16:31 pm
I never use the standard library at all... But anyway, it is pretty clear that the huge majority of users prefer changing to camelCase.
Title: New naming convention
Post by: julen26 on January 22, 2012, 07:29:43 pm
Quote from: "Tex Killer"
I never use the standard library at all... But anyway, it is pretty clear that the huge majority of users prefer changing to camelCase.


What about a poll?
Anyway it's up to you, Laurent :)
Title: New naming convention
Post by: N1ghtly on January 22, 2012, 08:44:01 pm
A poll sounds like the perfect solution to me too :)
Title: New naming convention
Post by: Laurent on January 22, 2012, 10:40:59 pm
There are already 85 messages full of useful feedback. So unless you really don't want to see SFML 2 released soon, what would the poll add that we don't already know? ;)
Title: New naming convention
Post by: Dravere on January 22, 2012, 11:14:54 pm
Quote from: "Laurent"
So unless you really don't want to see SFML 2 released soon, ...

I don't want SFML 2 to be released soon. "soon" often means not in the next two years :lol:

Probably they want to know which naming convention you will choose and try to influence you with a poll. So you choose the majority and not the wisest. ;)
Title: New naming convention
Post by: Mikademus on January 23, 2012, 12:46:48 am
Quote from: "Dravere"
@Groovy,
There is no half consistency. Like you said, there will be for example no consistency in the naming of classes.

And you only rarely use the standard library? std::vector? std::string? iostreams? std::unique_ptr? std::shared_ptr? And what about boost? What are you using instead?


Though arguing from good intentions, I would claim you are mistaken. Looking at computer languages the language itself often has a radically different "style" than user-defined symbols and code. I've actually said this here already:

Quote from: "Mikademus"
Yes, the trend in the industry over the last decade has been a move to lower-case comelCase for methods (Class::myMethod()), upper-case CamelCase for free functions (MyFunction()), all-lowercase without underscores for namespaces, and abbreviations treated as normal words (RenderRttStuff(), Class::rtsAndRttAreAcronyms()).

This is actually tremendously positive for code readability.

The boost and STL code conventions are only used there, but that too can be argued to serve the purpose of showing what is "language" and what is userland calls.


C++ is a language which per design has as much of the language as possible moved to the standard library rather than be integral to the compiler. However, the standard library is part of the same Standard that defines the rest of the C++ language and is not userland code.

So the STL and also Boost are both "language" (yes, even Boost, though it is an external library, is considered the unofficial extension of STL and part of the language) rather than userland (client-side) code. As such it is natural that Boost will stick close to the "language's style". Further, the STL and Boost objects are suggesting the form and usage of integral types--see int and string--which is indicated by the lower-case names and that they are considered final, unlike client objects, which are Upper-cased and usually extendible.

It is normal that unique styles and conventions evolve around the language symbols, and claiming that userland code must or should stay as close to the "language style" as possible is unacceptably restrictive and potentially damaging. It can be argued that userland code in fact should strive to be distinctive compared to integral types and symbols (C, C++, STL and Boost types). As for styles, we have we have a plenitude of those, the most pedagogical and ergonomic being camelCase.

In sum: It is a move for consistency, pedagogics and ergonomics to move SFML to camelCase. Using camelCase is not being inconsistent with the language itself.
Title: New naming convention
Post by: Laurent on January 23, 2012, 08:25:36 am
Quote
Probably they want to know which naming convention you will choose

They already know that.

Quote
and try to influence you with a poll

I prefer if they try to influence me with messages ;)

Quote
So you choose the majority and not the wisest

I already see what the majority wants from these 85 messages. It's pretty obvious that the majority wants camelCase, and that get/is prefixes shouldn't be removed. That's why I'm going to choose this solution.
So what else do people want? I don't have the feeling that the majority is against this choice.
Title: New naming convention
Post by: Mikademus on January 23, 2012, 11:56:12 am
Quote from: "Laurent"
So what else do people want?


Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).
Title: New naming convention
Post by: model76 on January 23, 2012, 12:23:51 pm
Quote from: "Mikademus"
Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).
Haha - maybe you should make a British binding!

In all seriousness, it doesn't matter what dialect you use, as long as you are consistent. None of them are more standard or proper than the others. For programming, my personal preference happens to be American English, because it happens to be shorter, and more widespread than other dialects.

Quote from: "Laurent"
I already see what the majority wants from these 85 messages. It's pretty obvious that the majority wants camelCase, and that get/is prefixes shouldn't be removed. That's why I'm going to choose this solution.
Hopefully that is not the only reason? Even though a lot of people (including myself) seem to be getting their wish in this matter, I think you should only do it if you feel it is the best option for SFML, in the long run.

Quote from: "Laurent"
So what else do people want?
Well, what are the options?
Maybe you should commit the changes, update the documentation, and wait a little while? Or you could even think about a beta release, which would look like the real release, except it would have the beta tag attached to it, along with a warning that things might still change. I really think it is important to get this one right.
Title: New naming convention
Post by: Laurent on January 23, 2012, 12:48:32 pm
Quote
Hopefully that is not the only reason? Even though a lot of people (including myself) seem to be getting their wish in this matter, I think you should only do it if you feel it is the best option for SFML, in the long run.

Of course, camelCase is also my personal choice.

Quote
Maybe you should commit the changes, update the documentation, and wait a little while? Or you could even think about a beta release, which would look like the real release, except it would have the beta tag attached to it, along with a warning that things might still change. I really think it is important to get this one right.

I don't think people need a release to know which naming convention they prefer. They can write a sample code themselves if they really need to see it in action.
And I don't want to commit this modification until I'm 100% sure that it's the final one. Imagine people who start to convert all their code, and suddenly I go back to the original naming convention... ;)
Title: New naming convention
Post by: Dravere on January 23, 2012, 01:37:52 pm
@Mikademus,
Name me a language where threading is part of the language. Where date and time is part of the language. Where I/O is part of the language. Containers are part of the language. You can use C++ without using the standard library. The standard library (btw. isn't the same as STL) isn't a part of the language! It is a library like Boost too. I have no knowledge of a language that has all the functionality of Boost implemented in the language itself. Your argument simply makes no sense at all.

And apart from that: Why is it important that I know that a given class is coming from the standard library or boost? Why do I need that knowledge while reading some code? And don't I already have it through the use of std:: or boost:: ?

Quote from: "Mikademus"
It is normal that unique styles and conventions evolve around the language symbols, and claiming that userland code must or should stay as close to the "language style" as possible is unacceptably restrictive and potentially damaging.

Name some example. I don't see this in lua, python, c#, java, etc.
There is only one place where this is happening: C++. Because the people don't like camel_case.

Quote from: "Mikademus"
..., the most pedagogical and ergonomic being camelCase.

Is there any evidence except from your personal preference? Why is C# using PascalCase and the majority of the libraries in C# are using PascalCase? If camelCase would be that much better, they would have switched or at least the userbase would have switched.

Why are the boost people using camel_case? To be consistent with the standard library. And boost isn't part of the language!

Quote from: "Mikademus"
In sum: It is a move for consistency, pedagogics and ergonomics to move SFML to camelCase. Using camelCase is not being inconsistent with the language itself.

It has nothing to do with consistency, pedagogics or ergonomics. There is no evidence for this. It is only personal preference.


But it seems Laurent made his choice already. Lucky me I haven't changed to use SFML 2.0 yet :)


Quote from: "Laurent"
Imagine people who start to convert all their code, and suddenly I go back to the original naming convention...

Well it is an unstable API :lol:
Title: New naming convention
Post by: BMB on January 23, 2012, 01:51:48 pm
Quote from: "Laurent"

Quote
Maybe you should commit the changes, update the documentation, and wait a little while? Or you could even think about a beta release, which would look like the real release, except it would have the beta tag attached to it, along with a warning that things might still change. I really think it is important to get this one right.

I don't think people need a release to know which naming convention they prefer. They can write a sample code themselves if they really need to see it in action.
And I don't want to commit this modification until I'm 100% sure that it's the final one. Imagine people who start to convert all their code, and suddenly I go back to the original naming convention... ;)

Myself, I have not tested any changes committed since this discussion started, since I feel it is silly to check out and use a new version, just to have my code break. I am waiting for this naming change to be committed before I do another pull and use the latest source. I assume I am not alone in this. This seems to me to be a good reson to do a commit, even if you are only 95% sure.
Title: New naming convention
Post by: tobybear on January 23, 2012, 02:00:25 pm
Quote from: "BMB"
Quote from: "Laurent"

Quote
Maybe you should commit the changes, update the documentation, and wait a little while? Or you could even think about a beta release, which would look like the real release, except it would have the beta tag attached to it, along with a warning that things might still change. I really think it is important to get this one right.

I don't think people need a release to know which naming convention they prefer. They can write a sample code themselves if they really need to see it in action.
And I don't want to commit this modification until I'm 100% sure that it's the final one. Imagine people who start to convert all their code, and suddenly I go back to the original naming convention... ;)

Myself, I have not tested any changes committed since this discussion started, since I feel it is silly to check out and use a new version, just to have my code break. I am waiting for this naming change to be committed before I do another pull and use the latest source. I assume I am not alone in this. This seems to me to be a good reson to do a commit, even if you are only 95% sure.

Yeah, right. Go, Laurent, go! We want SFML2! :-)
Title: New naming convention
Post by: Laurent on January 23, 2012, 02:03:05 pm
I'm currently busy updating the C and .Net bindings (there's still using the old graphics API), and then I'll be able to push the new naming convention.
Title: New naming convention
Post by: Silvah on January 23, 2012, 02:51:01 pm
Quote from: "Mikademus"
Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).
Well, if I can wish: proper and standard (i.e. American) spelling; f.i. color (correct) as opposed to colour (incorrect).  :twisted:
Title: New naming convention
Post by: OniLinkPlus on January 23, 2012, 04:21:39 pm
Quote from: "Silvah"
Quote from: "Mikademus"
Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).
Well, if I can wish: proper and standard (i.e. American) spelling; f.i. color (correct) as opposed to colour (incorrect).  :twisted:
Well, let's not start a debate here, but do you know why it's called English? Because it came from England/Britain. In other words, Britain's spelling is correct, as it is their language.
Title: New naming convention
Post by: pdinklag on January 23, 2012, 04:39:32 pm
Quote from: "Mikademus"
Quote from: "Laurent"
So what else do people want?


Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).

With all due respect to British English, from what I've seen in many years, the standard language in programming is U.S. English. I don't want to bring up a debate about how the Americans butchered the English language, but it's a fact that a simple modification like "color" to "colour" makes it a lot easier to type and read (especially for those whose native language is not English).

Quote from: "Dravere"
Name me a language where threading is part of the language.

Java.

Quote from: "Dravere"
Why is C# using PascalCase and the majority of the libraries in C# are using PascalCase? If camelCase would be that much better, they would have switched or at least the userbase would have switched.

Let me turn that around: why does the Java naming convention explicitly endorse camelCase and every Java library follows it? If it was that bad, they would have switched...

You can argue about this topic all day. It's probably the best thing to go with the majority (and I'm not saying this because I'm part of it - I honestly couldn't care less since I am writing a Java binding that uses camelCase anyway).

Quote from: "Dravere"
And boost isn't part of the language!

Is boost not an official part of C++11? Or, at least, officially endorsed?
Title: New naming convention
Post by: Nexus on January 23, 2012, 05:00:19 pm
Seems like I have to abandon the field, the other advocates of PascalCase already did that long ago :D

I wouldn't care about the API break so much, if only I saw a real advantage in the modification, as it would be the case for the Qt convention. Now it looks to me that the whole modification is quite arbitrary and based only on personal preference. As a library developer you can do that, of course, but... I hope you never change your preference again ;)
Title: New naming convention
Post by: Nexus on January 23, 2012, 05:08:06 pm
Quote from: "pdinklag"
Quote from: "Dravere"
Name me a language where threading is part of the language.
Java.
It's not completely part of the language, you also need the standard library for the Thread class. In fact, in Java you need the standard library far more often (if not always) than in C++, because as a result of the Object base class, everything is extremely coupled.

Quote from: "pdinklag"
Is boost not an official part of C++11? Or, at least, officially endorsed?
No, some parts of Boost are taken into the standard library, but Boost remains an external library.
Title: New naming convention
Post by: Ceylo on January 23, 2012, 05:13:55 pm
Quote from: "Nexus"
I wouldn't care about the API break so much, if only I saw a real advantage in the modification, as it would be the case for the Qt convention.

Well.. advantages have been given in the previous posts, don't they seem valid to you?
Title: New naming convention
Post by: pdinklag on January 23, 2012, 05:29:11 pm
Quote from: "Nexus"
Quote from: "pdinklag"
Quote from: "Dravere"
Name me a language where threading is part of the language.
Java.
It's not completely part of the language, you also need the standard library for the Thread class. In fact, in Java you need the standard library far more often (if not always) than in C++, because as a result of the Object base class, everything is extremely coupled.

Well, for instance, "synchronized" is a Java keyword, it's part of the language specification, and it's solely related to threading. The Java "standard library" essentially is Java. If you take away this library, you are dealing with nothing but the JVM itself. After all, even the "primitive types" (int, float, etc.) are actually just boxed versions of classes in the "java.lang" package, which also contains "Object" itself.

Quote from: "Nexus"
Quote from: "pdinklag"
Is boost not an official part of C++11? Or, at least, officially endorsed?
No, some parts of Boost are taken into the standard library, but Boost remains an external library.

OK, good to know. :)
I can't keep track of all those C++0x / C++11 developments. I'm not even sure whether anyone really cares...
Title: New naming convention
Post by: Mikademus on January 23, 2012, 06:14:14 pm
Quote from: "Silvah"
Quote from: "Mikademus"
Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).
Well, if I can wish: proper and standard (i.e. American) spelling; f.i. color (correct) as opposed to colour (incorrect).  :twisted:


There is no such thing as "American English" (it is a colloquialism--or vulgarism depending on your degree of lenience--albeit a ubiquitous one), but there is an US American dialect of English. Admittedly, there is no official "Standard English", but the expression is universally (well, worldwide, at least) accepted as referring to the modern British usage, which just because of that isn't called a "dialect", or at least the "root dialect" of its derivatives.

Unfortunately, you already have your wish, since SFML is using US spelling atm (why I have no idea since Laurent is French, and they learn British spelling in schools, iirc), so it was rather a dull request.

That said, if you want to I will happily concede to the expression "Abominable English" for the US bastardisation of the source language.

Enough banter; have fun flaming this post, any Yanks that feel indignation or slighted.
Title: New naming convention
Post by: model76 on January 23, 2012, 07:07:56 pm
Quote from: "Mikademus"
That said, if you want to I will happily concede to the expression "Abominable English" for the US bastardisation of the source language.
What exactly are you trying to achieve with these insults?
Is there a good reason for this behavior, or if not, will you please stop?
Title: New naming convention
Post by: Nexus on January 23, 2012, 07:20:55 pm
Quote from: "Ceylo"
Well.. advantages have been given in the previous posts, don't they seem valid to you?
More widespread use... It may make more people happy, which I understand (however keep in mind that opinions in this thread needn't be representative for the whole SFML community). But I consider the fact that I don't have to press shift rather irrelevant, since I read code more often than I write it, and I use auto-completion tools.

Anyway, I think that's been discussed enough now ;)
Title: New naming convention
Post by: JayArby on January 23, 2012, 08:29:10 pm
Quote
That said, if you want to I will happily concede to the expression "Abominable English" for the US bastardisation of the source language.


You're just jealous of American English. ;)
Title: New naming convention
Post by: minirop on January 23, 2012, 08:33:08 pm
JayArby > a quote I love :
Quote
there is no such thing as 'American English'. There is English and there are mistakes.

anyway, I'm used to "Color" because everybody use it. (except Ogre3D for what I know)
Title: New naming convention
Post by: Groogy on January 23, 2012, 09:06:58 pm
Well for programming I use the "US Dialect" of English but when writing/talking I tend to use the normal British English. Though I don't know I'm not native to the language so might be that I actually mix them both without even knowing it.
Title: New naming convention
Post by: JayArby on January 23, 2012, 11:26:36 pm
Quote from: "minirop"
JayArby > a quote I love :
Quote
there is no such thing as 'American English'. There is English and there are mistakes.

anyway, I'm used to "Color" because everybody use it. (except Ogre3D for what I know)


Yeah, I was using the qualifier 'American' to designate the version of English without the mistakes.

Okay, I'm just trolling now.  :lol: I actually don't care at all whether anyone prefers one dialect over the other.
Title: New naming convention
Post by: Dravere on January 24, 2012, 11:36:50 am
Quote from: "pdinklag"
Quote from: "Dravere"
Why is C# using PascalCase and the majority of the libraries in C# are using PascalCase? If camelCase would be that much better, they would have switched or at least the userbase would have switched.

Let me turn that around: why does the Java naming convention explicitly endorse camelCase and every Java library follows it? If it was that bad, they would have switched...

You missed my point there. I said the people are using the naming convention of the standard library. In C# the standard library is using PascalCase. In Java the standard library is using camelCase.

In most languages the people are using the naming convention of the corresponding standard library. C++ is the big exception.
Title: New naming convention
Post by: Silvah on January 24, 2012, 04:19:03 pm
Quote from: "OniLink10"
Well, let's not start a debate here, but do you know why it's called English? Because it came from England/Britain.
It's called English, because the people among whom it emerged were called Angles, after the region they came from, namely Angeln, which lies in Schleswig-Holstein, northern Germany. It's hardly England, you know ;)
Title: New naming convention
Post by: Spidyy on January 24, 2012, 08:30:48 pm
Quote from: "Silvah"
Quote from: "OniLink10"
Well, let's not start a debate here, but do you know why it's called English? Because it came from England/Britain.
It's called English, because the people among whom it emerged were called Angles, after the region they came from, namely Angeln, which lies in Schleswig-Holstein, northern Germany. It's hardly England, you know ;)


* Did learn something interresting today. *
Title: New naming convention
Post by: OniLinkPlus on January 24, 2012, 09:26:28 pm
Quote from: "Silvah"
Quote from: "OniLink10"
Well, let's not start a debate here, but do you know why it's called English? Because it came from England/Britain.
It's called English, because the people among whom it emerged were called Angles, after the region they came from, namely Angeln, which lies in Schleswig-Holstein, northern Germany. It's hardly England, you know ;)
Today I learned!
Title: New naming convention
Post by: Nexus on January 25, 2012, 12:26:43 pm
By the way, how are the STL compatibility functions going to be named? begin() and end() are strictly speaking inconsistent, as they're missing "get" :P

The real problem however is, those standard iteration loops mostly use the iterator or const_iterator member type, at least in C++98 without type inference. So only providing begin() and end() isn't enough.
Code: [Select]
for (Container::iterator itr = c.begin(); itr != c.end(); ++itr)
But if sf::String and sf::VertexArray use iterator and const_iterator instead of Iterator and ConstIterator, you will have multiple naming conventions in your public API again ;)
Title: New naming convention
Post by: Oberon on January 25, 2012, 01:52:39 pm
SFML has to provide iterator and const_iterator, otherwise the containers will not be usable in BOOST_FOREACH or the C++11 range based for loops ("foreach loops").
I propose to follow the Qt way here and provide both, one of them as typedef.
Title: New naming convention
Post by: Laurent on January 25, 2012, 03:11:22 pm
Quote
SFML has to provide iterator and const_iterator, otherwise the containers will not be usable in BOOST_FOREACH or the C++11 range based for loops ("foreach loops")

As far as I know, both can rely on non-member begin/end functions too.

I think that begin() and end() won't be renamed, people are used to these functions and it would be really strange to give them different names. As far as I know, all other libraries that use "get" for getters do the same.

I don't know what to do with iterator types. Qt defines both but I personally always use Iterator/ConstIterator because it's consistent with other Qt types.
Title: New naming convention
Post by: BMB on January 25, 2012, 10:39:32 pm
I hate to sound impatient or annoying, but since it seems that you have decided and already have the changes done by you, can we expect them to be  committed soon?
Title: New naming convention
Post by: Laurent on January 25, 2012, 10:57:08 pm
Nop, I'm first finishing to update the bindings (to the new graphics API), which takes much time.

And the changes are done but I need to restore the get/is prefixes, which will also take quite a lot of time.
Title: New naming convention
Post by: Tank on January 27, 2012, 11:23:06 am
Quote
And the changes are done but I need to restore the get/is prefixes, which will also take quite a lot of time.

I thought you use Git? Hopefully you're not of the sort of people committing changes only each 7 days. ;)
Title: New naming convention
Post by: Laurent on January 27, 2012, 12:08:07 pm
Quote
I thought you use Git? Hopefully you're not of the sort of people committing changes only each 7 days.

I switched from "PascalCase with get" to "camelCase without get", in a single commit. So now I need to add "get" prefixes.
Title: New naming convention
Post by: Tank on January 27, 2012, 10:59:06 pm
Then you learned your lesson I guess. ;)
Title: New naming convention
Post by: deadalnix on January 29, 2012, 04:51:27 pm
Ho God :D

I hate you and love you at the same time. The convention is way better but . . . So much broken code.
Title: New naming convention
Post by: capz on February 07, 2012, 04:15:02 am
Sweet! sfml is switching to the exact naming convention that I already use :) this is going to make my life with sfml even nicer ^^. Happy to see the "get" bits were added back in, seems confusing without.
Title: New naming convention
Post by: Laurent on March 11, 2012, 07:17:01 pm
It's pushed.

Reminder: the public member variables and functions, as well as free functions, are now lowerCase. That's all.
Title: New naming convention
Post by: texus on March 11, 2012, 07:38:32 pm
I get the following error while compiling:
Quote
/home/.../SFML2/src/SFML/Graphics/GLCheck.cpp:28:37: fatal error: SFML/Graphics/glCheck.hpp: No such file or directory
compilation terminated.

The file is called GLCheck.hpp, not glCheck.hpp.

In the audio folder I have the same problem with ALCheck.hpp.
Title: New naming convention
Post by: Laurent on March 11, 2012, 08:14:30 pm
Oops. I was pretty confident there was no filename error since I compiled on Linux, but after your message I realized that my Linux system uses a NTFS file system (shared folder used by a virtual machine).

It's fixed now -- well, it should, since I haven't tested :D
Title: New naming convention
Post by: texus on March 11, 2012, 08:33:24 pm
It's working now.
Thanks
Title: New naming convention
Post by: Mjonir on March 11, 2012, 08:42:04 pm
I've just compiled it on Windows and changed my project accordingly, it works perfectly.

I was just surprised by the change "sf::Seconds" -> "sf::seconds", it doesn't seem to match the usual convention for all SFML classes?
Title: New naming convention
Post by: Laurent on March 11, 2012, 08:51:43 pm
Quote
I was just surprised by the change "sf::Seconds" -> "sf::seconds", it doesn't seem to match the usual convention for all SFML classes?

It's not a class, it's a function.
Title: New naming convention
Post by: Mjonir on March 11, 2012, 08:54:44 pm
Quote from: "Laurent"
It's not a class, it's a function.


Ooh, alright, I skimmed over the code and did not notice that. Well the new convention makes that fact much more clear, it's a really good thing :)
Title: New naming convention
Post by: frosty on March 11, 2012, 10:41:56 pm
Quote from: "Laurent"
It's pushed.


Woohoo! Thanks Laurent.  :D
Title: New naming convention
Post by: texus on March 12, 2012, 04:12:52 pm
I am getting errors in Rect.inl on lines 67, 68 and 69.
Top, Width and Height should be top, width and height.

Not so important, but I am also getting warnings inside Rect.inl on line 40.
The left, top, width and height declarations are shadowing the members of Rect.
The parameters should get a different name.

Edit: I also have warnings in Font.hpp on line 222 for the same reason.
Title: New naming convention
Post by: Laurent on March 12, 2012, 06:02:33 pm
Quote
I am getting errors in Rect.inl on lines 67, 68 and 69.
Top, Width and Height should be top, width and height.

It's fixed, thanks.

Quote
Not so important, but I am also getting warnings inside Rect.inl on line 40.
The left, top, width and height declarations are shadowing the members of Rect.
The parameters should get a different name.

I use this everywhere without any problem.
I compile with:
- VC++, warnings level 4
- CLang, -Wall
- gcc, -Wall
... and never got a warning for this. What compiler/settings do you use?
Title: New naming convention
Post by: texus on March 12, 2012, 06:06:32 pm
The option that causes the warning is -Wshadow with gcc.[/quote]
Title: New naming convention
Post by: Laurent on March 12, 2012, 06:17:59 pm
And why isn't it in -Wall (which I assumed gathered all the possible warnings)?
Title: New naming convention
Post by: Laurent on March 12, 2012, 06:20:17 pm
I've updated the online documentation :)
Title: New naming convention
Post by: texus on March 12, 2012, 06:25:56 pm
Quote
And why isn't it in -Wall (which I assumed gathered all the possible warnings)?
I don't know, I guess -Wall just doesn't work like it should.

I just tested it again: no warnings with -Wall, but warnings with only -Wshadow.
I usually have almost all those checkboxes checked, so that I am sure to get all warnings.
Title: New naming convention
Post by: Nexus on March 12, 2012, 06:45:54 pm
Quote from: "Laurent"
It's pushed.
So it has come to this. (http://www.xkcd.com/1022/) :D
Title: New naming convention
Post by: eXpl0it3r on March 12, 2012, 07:30:16 pm
Quote from: "Nexus"
So it has come to this. (http://www.xkcd.com/1022/) :D


Haha

Just noticed it in the new documentary.
Not sure if I should like it...  :D

Btw Laurent: You might want to update your first post, incase people stumple up on it and get confused why the getters are still in there. ;-)
Title: New naming convention
Post by: coolhome on March 12, 2012, 07:56:24 pm
And so it begins...

Massive port of everything I've done! Laurent you never cease to break my code but when you do, it's usually worth it in the long run. :lol: For that I must say thanks for providing a very neat library!
Title: New naming convention
Post by: Mjonir on March 12, 2012, 08:43:29 pm
Quote from: "Laurent"
And why isn't it in -Wall (which I assumed gathered all the possible warnings)?


Unfortunately that's not how it works. "-Wall" only activates an actually vey specific set of warnings: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

As you can see there is also "-Wextra" which activates a bunch of others, and a few "extra extra" options that are in neither :/


Lots of these warnings could be useful, but I get SO many warnings from the libraries I use that it's simply not possible to keep them on. If anyone knows a solution to only display warnings for you own project, I'd be grateful! :P
Title: New naming convention
Post by: robvleugel on March 12, 2012, 10:12:42 pm
Downloading the newest snapshot right now...
I hope a "find - replace all" will do
I hope this new version also fixes all those heap corruption bugs I'm getting in my game lately
Title: New naming convention
Post by: Svenstaro on March 13, 2012, 04:18:18 am
Quote from: "Mjonir"
Quote from: "Laurent"
And why isn't it in -Wall (which I assumed gathered all the possible warnings)?


Unfortunately that's not how it works. "-Wall" only activates an actually vey specific set of warnings: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

As you can see there is also "-Wextra" which activates a bunch of others, and a few "extra extra" options that are in neither :/


Lots of these warnings could be useful, but I get SO many warnings from the libraries I use that it's simply not possible to keep them on. If anyone knows a solution to only display warnings for you own project, I'd be grateful! :P

Use -isystem instead of -i for includes. CMake even has an option for that when specifying include dirs.
Title: New naming convention
Post by: eigenbom on March 13, 2012, 10:07:29 am
So ... many ... compilation ... errors ... 28kLOC to sift through and update ...  >:(

Edit: I do like the new naming convention better though. :)
Title: New naming convention
Post by: Laurent on March 13, 2012, 10:52:07 am
Quote
So ... many ... compilation ... errors ... 28kLOC to sift through and update ... >

But from now on you won't have to change anything until SFML 3, isn't it great? :P
Title: New naming convention
Post by: eigenbom on March 13, 2012, 11:05:42 am
Quote from: "Laurent"
Quote
So ... many ... compilation ... errors ... 28kLOC to sift through and update ... >

But from now on you won't have to change anything until SFML 3, isn't it great? :P


Hehe, yeh that is great news. :)
Title: New naming convention
Post by: Nexus on March 13, 2012, 06:04:06 pm
Quote from: "Laurent"
But from now on you won't have to change anything until SFML 3, isn't it great? :P
In other words: Everything that doesn't please you now is carved in stone until then :P

(Sorry, couldn't resist, don't take it too seriously :D)
Title: New naming convention
Post by: Laurent on March 13, 2012, 06:22:11 pm
Quote
In other words: Everything that doesn't please you now is carved in stone until then

In other other words: SFML 3 will be released much sooner than you expect :lol:
Title: New naming convention
Post by: Yours3lf on March 13, 2012, 08:17:57 pm
Hi Laurent,

I've just checked out the new SFML snapshot with the new naming, and I just thought about posting about it when I saw this thread.

I've experienced other renamings in the past (in connection with SFML) so this didn't catch me off guard, and I don't want to tell you which convention to use, but you should definitely decide it now.

Personally I prefer the lower_case writing of everything, I don't even use Class names, I only like to use UPPER CASE for #define stuff, except header guards. For example:

Code: [Select]
#ifndef header_h
#define header_h

#define ZERO 0

const int global_variable = 1;

namespace a_name_space
{
  class a_class_name
  {
    private:
       int this_is_a_long_variable;
    protected:
    public:
      a_class_name() : this_is_a_long_variable( 1 )
      {
        do_some_stuff();
      }
  };
}

#endif


and since I use KDevelop I can use its handy reformat source functionality, which lets me set up a personalized code look.

Also it has a nice auto-completion feature, so no matter what convention you use I'm perfectly comfortable with it :)

Another thing is function names, those should be made permanent as well.
For example the recent ShowCursor vs. setMouseCursorVisible
and sf::Timer::Reset vs Restart vs restart

I'm really looking forward to the stable SFML 2.0 :)
Title: New naming convention
Post by: BMB on March 13, 2012, 08:34:47 pm
Quote from: "Laurent"

In other other words: SFML 3 will be released much sooner than you expect :lol:

One release at a time, please. We would be happy to see SFML 2 (no pressure). SFML 3 should wait until at least a week later.
Title: New naming convention
Post by: Laurent on March 13, 2012, 08:54:22 pm
Quote
you should definitely decide it now

Hum? It's decided, and it's changed now. So what do you mean?
Title: New naming convention
Post by: robvleugel on March 13, 2012, 09:12:54 pm
Quote from: "Laurent"
Quote
you should definitely decide it now

Hum? It's decided, and it's changed now. So what do you mean?


You didn't wait for his approval?
Btw I like the new convention, but to be honest I started to get used to the old one and I changed my convention to the same one mainly because of SFML. I realy have to get used to it again.

Oh and I noticed the sf::Mouse:: and sf::Mouse::Left didn't change, whats the reason behind this?
Title: New naming convention
Post by: Tank on March 13, 2012, 09:58:42 pm
Constants are still CamelCase. That's something I mentioned earlier what I dislike with the new convention.
Title: New naming convention
Post by: Laurent on March 13, 2012, 10:29:50 pm
Quote
Oh and I noticed the sf::Mouse:: and sf::Mouse::Left didn't change, whats the reason behind this?

Classes and constants are still UpperCamelCase.

Quote
Constants are still CamelCase. That's something I mentioned earlier what I dislike with the new convention.

I'm used to UpperCamelCase for constants and I like it. And I won't change that :P
Title: New naming convention
Post by: BMB on March 14, 2012, 09:48:30 am
Can we consider the current git checkout a "final" SFML 2? At least as far as the API? Are there only bug fixes left for SFML 2 final release?
Title: New naming convention
Post by: Laurent on March 14, 2012, 09:55:07 am
The current version is supposed to be the final one, yes. I won't even fix bugs, this can be done in SFML 2.1.

So, unless someone comes now and reports a huge flaw in the API, what you see now is the final SFML 2.0.

I'll make a release candidate soon, by the way.
Title: New naming convention
Post by: Bigz on March 14, 2012, 10:17:19 am
Quote
[...] what you see now is the final SFML 2.0


So I think it's time for celebration !!!

And a huge thank you for all the work you did ![/quote]
Title: New naming convention
Post by: bastien on March 14, 2012, 01:26:48 pm
Do you still plan to rework error handling? If so, when will you do it?
Title: New naming convention
Post by: Laurent on March 14, 2012, 01:40:18 pm
Quote
Do you still plan to rework error handling?

Not in SFML 2. In SFML 3, maybe.
Title: New naming convention
Post by: Tank on March 14, 2012, 02:14:25 pm
So nothing will be done for -Wshadow...?
Title: New naming convention
Post by: Laurent on March 14, 2012, 02:23:28 pm
Quote
So nothing will be done for -Wshadow...?

It will be fixed ;)
Title: New naming convention
Post by: Tank on March 14, 2012, 02:24:30 pm
Yuppie :)
Title: New naming convention
Post by: nietaki on March 14, 2012, 07:09:35 pm
Quote from: "Laurent"
I'll make a release candidate soon, by the way.

That's great news! :mrgreen:  :mrgreen:
Title: New naming convention
Post by: Zephilinox on March 15, 2012, 02:54:09 am
Quote from: "Laurent"
I'll make a release candidate soon, by the way.


awesome, now I can cross compile my projects.
Title: New naming convention
Post by: Laurent on March 17, 2012, 05:00:54 pm
I compiled with
Code: [Select]
-Wall -Wextra -Wshadow -pendantic -Wno-long-long
with
Code: [Select]
clang
gcc
mingw32-gcc

 and fixed all that was found.

The remaining warnings are all in stb_image.h and stb_image_write.h. I'll see what I can do about them.
Title: New naming convention
Post by: Cornstalks on March 17, 2012, 09:11:03 pm
Quote from: "Laurent"
I compiled with
Code: [Select]
-Wall -Wextra -Wshadow -pendantic -Wno-long-long
with
Code: [Select]
clang
gcc
mingw32-gcc

 and fixed all that was found.

Just out of curiosity, which versions did you use?  Specifically, will SFML 2 be targeting C++03 or C++11?  I see issue 129 is about adding conditional C++11 support, but I can't tell if that means adding support conditionally (i.e. it doesn't exist yet) or removing it (i.e. it does exist now).  I was getting issues when compiling with -pedantic on g++4.2 because long long isn't a C++03 type, so I just removed -pedantic.  I see Config.hpp still has long long so I'm assuming C++11...
Title: New naming convention
Post by: Laurent on March 17, 2012, 09:30:12 pm
Quote
I was getting issues when compiling with -pedantic on g++4.2 because long long isn't a C++03 type, so I just removed -pedantic. I see Config.hpp still has long long so I'm assuming C++11...

Code: [Select]
-Wno-long-long
;)

SFML is currently C++03, and will have conditional support for C++11.
Title: New naming convention
Post by: Cornstalks on March 17, 2012, 10:41:50 pm
Quote from: "Laurent"
Quote
I was getting issues when compiling with -pedantic on g++4.2 because long long isn't a C++03 type, so I just removed -pedantic. I see Config.hpp still has long long so I'm assuming C++11...

Code: [Select]
-Wno-long-long
;)

SFML is currently C++03, and will have conditional support for C++11.

*facepalm*  Thanks, overlooked that one.  And thanks for the info.  And SFML.
Title: New naming convention
Post by: VPellen on March 21, 2012, 01:15:58 am
Downloaded the latest source today, and my compiler spat out about a few dozen no-such-member errors.

A pain in the ass to rename, but this is a good thing, right?
Title: Re: New naming convention
Post by: Haze on March 25, 2012, 01:06:03 pm
Laurent, have you made up your mind about high-level getter/setter methods for sf::Transformable, such as getX, setX, getY, setY, getSize ?
IMHO, those methods would be really convenient, user code is sometimes too complex for really simple position manipulation.


Title: Re: New naming convention
Post by: Laurent on March 25, 2012, 01:55:58 pm
getX and getY are not necessary (getPosition().x is as easy to write).
getSize cannot be in sf::Transformable, the local size is not known there.
setX and setY could be useful, but if I do it for every function of every class that takes a sf::Vector2, the public API will explode.
Title: Re: New naming convention
Post by: Nexus on March 25, 2012, 02:57:48 pm
Haze, this concerns not only position, but also scale (x, y), origin (x, y) and color (r, g, b, a). Maybe even rect (left, top, width, height) in other places.

I suggest to write global function templates on user side, this way you can cover large parts of the library with very few code.
Title: Re: New naming convention
Post by: Haze on March 25, 2012, 04:23:43 pm
That's the solution I'm currently using.
I was just assuming this may be part of the API, and I was pointing at position because I think this attribute is more used than the other ones you listed.
It would also avoid a couple of function calls, but I don't want to sound captious :)
Title: Re: New naming convention
Post by: Yours3lf on March 25, 2012, 09:13:38 pm
Quote
you should definitely decide it now
Hum? It's decided, and it's changed now. So what do you mean?

I only meant that a naming convention should be chosen and sticked to, so that if now everybody updates to the new convention it will be consistent later on (and compatible with apps written with older versions of SMFL). But if you decided then it's cool :)
Title: Re: New naming convention
Post by: julen26 on April 18, 2012, 12:49:56 am
I just wanted to say that I hate the new naming convention and will probably switch to a different library because of this

it looks like ass and makes no sense
You had your time to judge before releasing the new naming convention. The new naming doesn't affect when coding, only changes some characters. Which are your arguments for making that decision?

Anyway I think that it's your post wich doesn't make sense.