Author Topic: New naming convention (Read 85769 times)

Laurent · « **Reply #75 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

Dravere · « **Reply #76 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.

Groogy · « **Reply #77 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.

Dravere · « **Reply #78 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?

Groogy · « **Reply #79 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.

model76 · « **Reply #80 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.

Tex Killer · « **Reply #81 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.

julen26 · « **Reply #82 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

N1ghtly · « **Reply #83 on:** January 22, 2012, 08:44:01 pm »

A poll sounds like the perfect solution to me too

Laurent · « **Reply #84 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?

Dravere · « **Reply #85 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.

Mikademus · « **Reply #86 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.

Laurent · « **Reply #87 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.

Mikademus · « **Reply #88 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).

model76 · « **Reply #89 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.