New naming convention

[Groogy]

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 =/

[Tex Killer]

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.

[Tank]

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.

[gsaurus]

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.

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

[Contadotempo]

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.  

[aquanull]

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:

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:

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.

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.

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:

Thanks for your detailed feedback.

You are welcome.

[Tex Killer]

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.

[aquanull]

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.

[Hiura]

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. As you can see the dilema has not a huge impact on the overall functions.

[BMB]

You can have a look at most (if not all) the functions concerned by this new naming convention here. As you can see the dilema has not a huge impact on the overall functions.

There are a lot more here

[Hiura]

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.

[Ceylo]

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

[aquanull]

There are a lot more here

Many nouns there are also valid verbs, such as center, loop, scale, view etc. They could be ambiguous.

[Laurent]

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:

[Nexus]

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.