New naming convention

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

[tobybear]

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 :-)

[Laurent]

Thanks for sharing your opinions.

camelCase + get/is should be my final decision.

[AdventWolf]

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.

[Nexus]

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.

[Tex Killer]

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.

[Nexus]

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.

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?

[Mikademus]

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.

[Tex Killer]

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?

[Teemperor]

camelCase + get/is should be my final decision.

a big +1 to this decision from my side.

[Ceylo]

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.

[julen26]

Plus, if SFML should change its naming convention, it's now or "never".

Completely agree.

[Groogy]

So this is more or less definite? Can I base the binding on it? (Naming of my class methods) on this convention?

[BMB]

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

[pdinklag]

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