Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: New naming convention  (Read 86739 times)

0 Members and 1 Guest are viewing this topic.

pacifistcottage

  • Newbie
  • *
  • Posts: 13
    • View Profile
New naming convention
« Reply #60 on: January 20, 2012, 03:32:34 pm »
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

  • Newbie
  • *
  • Posts: 27
    • View Profile
New naming convention
« Reply #61 on: January 20, 2012, 03:43:15 pm »
Quote from: "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.

This is also my opinion :-)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New naming convention
« Reply #62 on: January 20, 2012, 06:09:12 pm »
Thanks for sharing your opinions.

camelCase + get/is should be my final decision.
Laurent Gomila - SFML developer

AdventWolf

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
New naming convention
« Reply #63 on: January 20, 2012, 06:40:43 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
New naming convention
« Reply #64 on: January 20, 2012, 07:38:36 pm »
Quote from: "Laurent"
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
New naming convention
« Reply #65 on: January 20, 2012, 08:33:29 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
New naming convention
« Reply #66 on: January 20, 2012, 09:10:34 pm »
Quote from: "Tex Killer"
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.

Quote from: "Tex Killer"
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?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Mikademus

  • Newbie
  • *
  • Posts: 31
    • View Profile
New naming convention
« Reply #67 on: January 20, 2012, 11:01:23 pm »
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

  • Full Member
  • ***
  • Posts: 242
    • View Profile
New naming convention
« Reply #68 on: January 21, 2012, 05:58:19 am »
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

  • Newbie
  • *
  • Posts: 6
    • View Profile
New naming convention
« Reply #69 on: January 21, 2012, 10:03:59 am »
Quote from: "Laurent"

camelCase + get/is should be my final decision.


a big +1 to this decision from my side.

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
New naming convention
« Reply #70 on: January 21, 2012, 02:27:42 pm »
Quote from: "Nexus"
Quote from: "Tex Killer"
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.
Want to play movies in your SFML application? Check out sfeMovie!

julen26

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
    • http://julen26.blogspot.com
New naming convention
« Reply #71 on: January 21, 2012, 02:34:50 pm »
Quote from: "Ceylo"
Plus, if SFML should change its naming convention, it's now or "never".


Completely agree.

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
New naming convention
« Reply #72 on: January 22, 2012, 01:00:13 am »
So this is more or less definite? Can I base the binding on it? (Naming of my class methods) on this convention?
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

BMB

  • Newbie
  • *
  • Posts: 21
    • View Profile
New naming convention
« Reply #73 on: January 22, 2012, 08:25:39 am »
Quote from: "Laurent"
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

  • Sr. Member
  • ****
  • Posts: 330
  • JSFML Developer
    • View Profile
    • JSFML Website
New naming convention
« Reply #74 on: January 22, 2012, 09:06:39 am »
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...
JSFML - The Java binding to SFML.

 

anything