Hi, so I just watched this: http://www.youtube.com/watch?v=65j5dB2KSZg
And it says in version 3.0 onwards the naming conventions won’t use hungarian notation… But I wonder why.
I also wonder if you have been using the proper hungarian notation (apps rather than system). A rant/quite useful explanation of how and when and why it’s good to use “apps” hungarian notation is here: http://www.joelonsoftware.com/articles/Wrong.html
Why we use hungarian notation in old versions? Because I wrote programs on WinCE5~6 / WM6~6.5 for many years. So cocos2d-x old versions looks like Microsoft coding style.
In 3.0, Ricardo is leading the development, he don’t like hungarian notation, I agree that we should refer to google c*+ coding style.
Now this is our c*+ coding style https://github.com/cocos2d/cocos-docs/blob/master/manual/framework/native/best_practice/cpp_coding_style/en.md. It looks more clean. A extra benefit is that, cocos2d-html5 will have easier time to sync cocos2d-x features.
Zhe Wang wrote:
In 3.0, Ricardo is leading the development, he don’t like hungarian notation
Well, I guess that’s that then.
I think you guys should use whatever convention you find useful, so cheers for getting organized 
But in the topic of hungarian notation: I’m checking out that coding conventions guide you linked and I can’t help but to notice that where it discourages hungarian notation it says and I quote “Do not use Hungarian notation (for example, naming an integer iNum)”, this is what we call “systems hungarian notation” or simply “bad hungarian notation”. “apps hungarian notation” on the other hand is pretty useful. The article I linked on my first post makes that point very clearly and I highly reccomend that anyone who likes to program to have a look at it.
Frankly, this is one of the issues with the v3.0 migration path. I understand personal preference — as developers we all have our own likes and dislikes.
i will definitely be sticking with v2.2 because that API is stable and the migration path to v3.0 is ugly for a number of reasons — this naming change is part of that.
Just my opinion. Too late to change, but something to think about when you’re upgrading an API that people depend on.