Messages

1

General discussions / New naming convention

« on: January 11, 2012, 07:08:58 pm »

* 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);
}

//...

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

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

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.

2

General discussions / New naming convention

« on: January 11, 2012, 03:09:58 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.

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

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.

3

General discussions / New naming convention

« on: January 09, 2012, 05:05:28 pm »

There are a lot more here

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

4

General discussions / New naming convention

« on: January 09, 2012, 08:48:20 am »

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.

5

General discussions / New naming convention

« on: January 09, 2012, 08:04:18 am »

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.

6

General discussions / New naming convention

« on: January 08, 2012, 04:55:22 pm »

Wow, I didn't expect to have my first post here in this fashion, but:

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!