Naming conventions - functions

[gsaurus]

Is there any specific reason for functions in SFML to start with uppercase?
I think that starting with lowercase is a more widely used convention.

http://geosoft.no/development/cppstyle.html

[Laurent]

The C++ world, unfortunately, has no clear naming convention. Standard library and boost use lower case + underscore, many other libraries use lower case for first word then upper case, etc.

At the time I started to program, I used Microsoft stuff a lot (Win32, DirectX) which uses the naming convention that you can see in SFML. That's the reason. Now I use a totally different convention, both at work and in my new personal projects -- but I can't change the naming convention of SFML.

The most important thing is to remain consistent, it doesn't really matter if I use lower or upper case, etc.

[gsaurus]

Well, SFML2 is a new library, with a new API. But I understand that it would be too much to change the convention used since sfml 1.x... unless the community vote to change it (still unlikely I guess?). Projects using sfml1.x would need refactoring anyway.

The problem isn't SFML but projects using it. For example one extending from sf::Drawable, implementing functions from some other interface will end up with a class with some functions starting with uppercase and others with lower. Even worse if we want to deploy a project as a lib, we mess conventions or we are forced to follow SFML convention.

I know, the conventions problem has no solution but I think we should promote whatever convention we like more in order to ease the problem (converging to some convention). The one starting with lowercase and no underscores seems to be more accepted, and is coherent with Java in case of the Java binding (I don't know about conventions in other languages)

[Laurent]

I understand, and that's (partly) why I remove unnecessary inheritance in SFML 2 (sf::Thread, sf::Drawable soon).

If anyone else wants to share his opinion about the naming convention... the discussion is open

[panithadrum]

First I liked the uppercase a lot, but then I started learning Qt and I really loved the lowercase. Anyway, it's too much work to change it and it doesn't really affect anything than code-reading perfection.

[Nexus]

I don't think changing the SFML naming convention is a good idea. It is a huge amount of work, breaks tons of existing code for little or no gain. Saying that there are also other API changes is no real argument because 1. these are negligible compared to a global modification at every function, and 2. there is already much code depending on recent revisions of SFML 2.

Concerning the mix of identifiers: This is an ever-present problem too. For example, I have to provide lowercase swap functions in my library to support ADL, although every other function starts with uppercase letters. Some identifiers need to be adapted in every case, changing SFML's convention just shifts the issue. As you say, you can't solve it anyway, there will always be different conventions and users that don't like the new conventions.

[gsaurus]

Come on, refactoring projects already using SFML2 is just find/replace , not as hard as when the API changes that we really have to change code, sometimes whole structures.

The problem can converge to a solution if everyone start adopting the same convention. keeping old conventions just because of historic and existing projects is not evolving. we are just spreading a convention different from what seems to be the current trend.

[Laurent]

Is that really the "current trend"? Why not adopting the standard library / boost convention (after all, that's what people do in all other languages)?

[gsaurus]

You got a point there I think. I never used boost, and fortunately I never had to extend std classes other than exceptions I don't know to what extent people like the std/boost convention or not, people didn't really choose it I guess  :roll:

I understand, and that's (partly) why I remove unnecessary inheritance in SFML 2 (sf::Thread, sf::Drawable soon).

Interesting. I understand the use of functors for the Thread, but how will you break the drawable inheritance?
I was precisely with a problem with this inheritance because I wanted to extend the whole hierarchy, but there is no family inheritance/polymorphism in C++ (and diamond inheritance isn't possible because the original Drawable family wasn't thought for that obviously).

This is strange, inheritance is so comfortable to use, but then there are language limitations that makes us to go with a work around.. :?

[Disch]

I've always preferred capitalized function and class names.

The Java-esque approach where you lowercase the first letter but capitalize all the later ones (getWhateverValue) always seemed out of whack and weird to me.  The lowercase just looks/feels out of place.  I never understood how that became commonly accepted.

lowercase with underscores (get_whatever_value) is even worse because underscores are harder to type.

SFML more or less follows the same trend of already existing APIs in the same field.

- DirectX shares the same style as WinAPI (practically identical to SFML)

- OpenGL does the same thing, but prefixes functions with "gl" (glGetWhatever), similar to how SFML is if you include the namespace qualifier (sf::GetWhatever)

- SDL also does the same thing, but prefixes with "SDL_"  (SDL_GetWhatever)


Changing styles now would be going further from existing conventions, IMO.  Personally I like it the way it is.


EDIT:

As far as boost and std are concerned, it makes sense for boost to mimic std's style because it acts as an extention of std.  Personally I'm not crazy about that style but it does make sense in that context.

I don't put SFML in the same category as boost though.  Sure it's a 3rd party library, but that's as far as the similarities go.  Boost and std are targetting generic infrastructure issues, whereas SFML's target(s) is/are very specific.

[Laurent]

I understand the use of functors for the Thread, but how will you break the drawable inheritance?

In fact I'm breaking the whole graphics API, not just sf::Drawable inheritance

This is strange, inheritance is so comfortable to use, but then there are language limitations that makes us to go with a work around..

I think inheritance is good for frameworks, but it should be avoided in low-level libraries that aim at providing small building blocks. SFML should only provide tools on which you can build you own code, not force a particular design.

[NoIdea]

When I started SFML, I found that having capitals for the first letter of every word very clear and elegant. However, I now almost always use SFML/OPENGL/STL/Boost and I always get confused when my compiler refuses myvector.Clear() or GlBegin() or sleep(1) or ...

I would prefer it if SFML followed the boost/STL convention since we always use at least the STL (and the STL convention won't change).

[gsaurus]

Laurant, can you predict +/- how long will it take to release a first version of the new graphics API?
And sorry for the off topic

[Laurent]

Nop, sorry.

[Tyrreus]

Hello every one!

This is my first post and I'm started (unfortunately) from this topic. I'm preparing to start a new project, exactly first application with GUI from ground up and I'm looking for nice and simple library - as SFML. At first look it looks great, wonderful and so on, but this convention makes me creepy ;/. I have read replies and I want to add something:

In case when anybody has already done application i.e. based on 1.6 version, it's as I said done and I believe working so new convention won't touch him directly, but in case when someone want to start a new work with new (2.0) version of library will be happy than new convention will be consistent with every other libraries as standard, boost etc.

I wonder how many people will want to use this library and how many give up because of the convention.

So is there any decision about the convention in the new version?

Best regards
Tyrreus