[Refusé] Suggestions minimes sur quelques identificateurs

[L01man]

Voici quelques propositions de simplification, de généralisation ou de raccourcissement des noms de fonctions.

Window
setVerticalSyncEnabled => setVerticalSync
Du moment que le type est bool, y'a-t-il besoin du Enabled ? Pour setSmooth par exemple, il n'y est pas.
isOpen => isOpened ou opened

Image
flipHorizontally => FlipX
flipVertically => FlipY
Les sf::Vector, par exemple, sont toujours en x et y, aussi bien pour GetPosition() que pour GetSize(), et on n'a pas de w et de h. De même
Sprite possédait des méthodes  FlipX() et FlipY(), qui semblent d'ailleurs avoir disparu.
getPixelsPtr => getPixels
Le type de retour n'est-il pas assez explicite ?

Rect
left => x
top => y
J'ai bien aimé le changement de right et bottom en width et height, et pourquoi s'arrêter là ? D'ailleurs, x et y sont plus courts à écrire .

Keyboard
isKeyPressed => isPressed voire pressed
Comme il s'agit de la classe Keyboard, et que cette fonction est la seule, on peut comprendre qu'il s'agit de touches, d'autant plus qu'on s'apprête à mettre un paramètre de type Key. Quant au "is", le retour de type bool et la fin en "ed" indiquent qu'on veut obtenir un état.
On pourrait même renommer Keyboard en Key, ou pas.
Mouse
isButtonPressed => pressed
Joystick
isButtonPressed => pressed
getButtonCount => buttons ou getButtonSize
Pour faire court ou se rapprocher du size de std::vector.
Avec tout ces pressed partagés entre Keyboard, Mouse, et Joystick, on pourrait s'en souvenir facilement.

D'ailleurs, Keyboard, Mouse et Koystick ne devraient-ils pas être regroupés sous Event ? Mais ça serait un peu long...

Clock
getElapsedTime => getElapsed ou elapsed
Puisque le type de retour est Time.
Time
asSeconds => s
asMilliseconds => ms
asMicroseconds => us
Comme les unités officielles.

D'autre part, est-ce que appeler Time() ne revient pas à utiliser Zero ?

Enfin, pourquoi ne pas enlever les marques d'accesseurs et mutateurs "get" et "set" ? Par exemple, jQuery le fait. $('tag').attr('truc') récupère l'attribut truc de la balise tag et $('tag').attr('truc', 'foo') donne la valeur foo à truc de la balise tag. Généralement, quand il n'y a pas de paramètre, c'est un accesseur, et c'est certain quand la fonction est constante. Le choix est dur : réduire la plupart des noms de fonctions de trois lettres ou risquer de semer le doute dans l'esprit des utilisateurs débutants de SFML ?
De la même façon, on peut garder ou enlever les "is".

Sinon, j'ai remarqué que dans le changelog, les nouvelles fonctions ne sont pas indiquées en camelCase.

[Laurent]

setVerticalSyncEnabled => setVerticalSync
Du moment que le type est bool, y'a-t-il besoin du Enabled ? Pour setSmooth par exemple, il n'y est pas.

Smooth est un adjectif, donc la texture est ou n'est pas smooth. Par contre, la fenêtre n'est pas synchronisation verticale, par contre elle peut l'activer ou non.

isOpen => isOpened ou opened

Non justement, opened est le participe passé (I've opened the door), open est l'adjectif (the door is open). Ca a été corrigé récemment.

flipHorizontally => FlipX
flipVertically => FlipY

Les noms actuels sont bien plus explicites. Avec FlipX, on ne sait pas si on retourne les X (horizontalement), ou si on retourne autour de X (verticalement).

getPixelsPtr => getPixels
Le type de retour n'est-il pas assez explicite ?

Je préfère expliciter le fait que l'appelant n'obtient qu'un pointeur vers les pixels internes de l'image, et non une copie propre des pixels. Ca évite qu'il se demande s'il doit appeler delete ou non une fois qu'il a fini.

left => x
top => y
J'ai bien aimé le changement de right et bottom en width et height, et pourquoi s'arrêter là ? D'ailleurs, x et y sont plus courts à écrire

Tu penses vraiment que c'est clair, que (x, y) est le coin haut-gauche ? Beaucoup de systèmes ont un axe Y qui pointe vers le haut, et dans ce cas y est le bas du rectangle. Là au moins il n'y a pas d'ambigüité possible.

isKeyPressed => isPressed voire pressed
Comme il s'agit de la classe Keyboard, et que cette fonction est la seule, on peut comprendre qu'il s'agit de touches, d'autant plus qu'on s'apprête à mettre un paramètre de type Key. Quant au "is", le retour de type bool et la fin en "ed" indiquent qu'on veut obtenir un état.
On pourrait même renommer Keyboard en Key, ou pas.

Le préfixe "is" a déjà été longuement débattu, et il y a des arguments assez bons en sa faveur, donc inutile de revenir dessus
Ensuite, en ce qui concerne isPressed, j'ai rien de spécial contre, mais j'ai rien non plus pour à vrai dire.
Par contre renommer Keyboard en Key, non, car la classe représente réellement le périphérique et tout ce qui peut lui être associé (comme Mouse et Joystick). Si j'ajoute d'autres fonctions je vais être bloqué avec sf::Key comme nom.

Mouse
isButtonPressed => pressed
Joystick
isButtonPressed => pressed

Comme là on peut avoir des axes et des boutons, mieux vaut garder les noms explicites. Ok un axe ne peut pas être "pressed", mais mieux vaut toujours rester explicite. Quelques caractères en plus peuvent faciliter la vie des gens, alors que les enlever... ça ne va pas révolutionner leur code.

getButtonCount => buttons ou getButtonSize
Pour faire court ou se rapprocher du size de std::vector.

La "taille" des boutons ? Non... le "nombre" de boutons

Avec tout ces pressed partagés entre Keyboard, Mouse, et Joystick, on pourrait s'en souvenir facilement.

Bah, avec le nom de ce que tu veux tester, c'est facile à retenir aussi. "est-ce que ce bouton est appuyé ?" -> isButtonPressed. Le code reste assez naturel à lire en langage courant, ce qui est plutôt une bonne chose en programmation.

D'ailleurs, Keyboard, Mouse et Koystick ne devraient-ils pas être regroupés sous Event ? Mais ça serait un peu long...

Non justement, ça n'a rien à voir avec les évènements.

Clock
getElapsedTime => getElapsed ou elapsed
Puisque le type de retour est Time.

Justement, on renvoie un Time donc get...Time me semble plus qu'approprié. "get elapsed" est incomplet, get elapsed quoi ?
Et en ce qui concerne les préfixes "get", tout comme les "is" ça a longuement été débattu (sur le forum anglais), je ne reviendrai pas dessus.

Time
asSeconds => s
asMilliseconds => ms
asMicroseconds => us
Comme les unités officielles.

Euh... non.

D'autre part, est-ce que appeler Time() ne revient pas à utiliser Zero ?

Si, Mais Time::Zero est très explicite alors que Time() on ne peut pas savoir ce que ça donne sans lire la doc.

Enfin, pourquoi ne pas enlever les marques d'accesseurs et mutateurs "get" et "set" ? Par exemple, jQuery le fait. $('tag').attr('truc') récupère l'attribut truc de la balise tag et $('tag').attr('truc', 'foo') donne la valeur foo à truc de la balise tag. Généralement, quand il n'y a pas de paramètre, c'est un accesseur, et c'est certain quand la fonction est constante. Le choix est dur : réduire la plupart des noms de fonctions de trois lettres ou risquer de semer le doute dans l'esprit des utilisateurs débutants de SFML ?
De la même façon, on peut garder ou enlever les "is".

Cf ce que je t'ai dit, il y a une grosse discussion à ce sujet sur le forum anglais (General discussions > Naming convention).

Sinon, j'ai remarqué que dans le changelog, les nouvelles fonctions ne sont pas indiquées en camelCase.

Oui, je l'ai écrit au fur et à mesure. Et puis il faut bien en choisir une : avant c'était CamelCase (j'ai l'impression que tu n'as pas remarqué ce point), maintenant c'est camelCase.

Désolé, je ne retiens aucune de tes suggestions. On n'est pas du tout dans la même optique : toi tu voudrais du minimalisme (pourquoi faire ?) alors que moi je privilégie les noms explicites et qui s'auto-documentent.

[L01man]

Smooth est un adjectif, donc la texture est ou n'est pas smooth. Par contre, la fenêtre n'est pas synchronisation verticale, par contre elle peut l'activer ou non.

Je le lis plutôt comme : "utiliser la sync. ver.". Ou sinon : useVerticalSync, enableVerticalSync. Garder un "set" ici avec le "enable" reviendrait à vouloir écrire "getIsOpened" ou "getOpenEnabled" à la place de "isOpened".

Ah, je viens d'apprendre un peu d'anglais ^^.

Avec FlipX, on ne sait pas si on retourne [...] autour de X (verticalement).

Et avec FlipHorizontally, on pourrait aussi penser tourner autour de X ? N'est-on pas habitués aux machinX et machinY ? Sinon : symetryX et symetryY.

Tu penses vraiment que c'est clair, que (x, y) est le coin haut-gauche ?

Oui, l'axe est aussi inversé pour les Sprite et tout le reste ! Et dans les Drawable, les noms sont x et y. D'ailleurs, serait-ce une bonne idée de faire un Rect { sf::Vector2f Position, Size } ? Avec la SDL, tout ce qui se dessine est affiché dans une Surface, un Rectangle, quoi. Dans ce cas-là, appeler GetRect() renverrait GetPosition() et GetSize(). Ca permettrait de faire des calculs de collision plus généralisés sur des sf::Text et autres.

mais j'ai rien non plus pour à vrai dire.

C'est plus court et ça peut être généralisé à Mouse et Joystick. On peut inférer "touche" ou "bouton" puisqu'en effet on ne peut appuyer sur autre chose : "est-ce que le bouton {x} est appuyé ?" => "Est-ce que {X} est appuyé" ? Disons que dans la langue "pressed" est une méthode spécifique aux boutons ^^. Et d'une certaine façon une touche est un bouton. Contrairement à ces deux-là, un clavier ne peut qu'avoir des touches, et il ne peut pas y avoir d'ambiguïté avec des axes ou des molettes.

(j'ai l'impression que tu n'as pas remarqué ce point)

Si, c'est d'ailleurs pour ça que j'ai écrit cette phrase ^^. J'avais lu sur le forum que tout serait en camelCase dans la 2.0, et je l'ai aussi vu dans la nouvelle Doc', mais dans le changelog même les fonctions ajoutées sont écrites en CamelCase. D'ailleurs, j'ai voulu faire une regex pour remplacer "\.([A-Z])" par "\.upperase(\¡)" mais il n'y a aucune fonction pour ça , et je dois dire qu'ici les "Get", les "Set" et les "Is" étaient bien plus pratiques à remplacer .

(pourquoi faire ?)

Pour tenter de raccourcir les noms, à vrai dire. J'essaie quand-même de "généraliser" les noms pour qu'ils restent explicites : quand on a utilisé un biduleX ou un isPressed on saura les utiliser ailleurs, sans changement comme "Horizontally" ou "Button/Key".

moi je privilégie les noms explicites et qui s'auto-documentent

Oui, c'est le plus important. J'essaie de voir si un compromis n'est pas possible.

Désolé, je ne retiens aucune de tes suggestions.

Oh ! c'est pas grave. Ca m'y a fait un peu plus réfléchir et ça va sûrement m'aider à utiliser de meilleurs noms.

Deux autres suggestions :
RenderWindow, RenderTexture
display -> draw
Comme pour les Drawable. C'est peut-être une mauvaise idée mais je suggère quand-même, on sait jamais.

[Laurent]

Ou sinon : useVerticalSync, enableVerticalSync. Garder un "set" ici avec le "enable" reviendrait à vouloir écrire "getIsOpened" ou "getOpenEnabled" à la place de "isOpened".

Avant c'était nommé comme ça, et on m'a fait remarquer que préfixer tous les setters par "set" avait certains avantages non-négligeables.

Et avec FlipHorizontally, on pourrait aussi penser tourner autour de X ?

Non, pour moi c'est extrêmement clair.

N'est-on pas habitués aux machinX et machinY ? Sinon : symetryX et symetryY.

On est habitué aux X et aux Y, ça ne les rend pas pour autant plus clair dans ce cas là. "symmetry" n'y changerait rien (il faudrait au moins ajouter "around" pour que ce soit clair).

Oui, l'axe est aussi inversé pour les Sprite et tout le reste !

Ca ne rend pas pour autant la chose plus évidente

Et dans les Drawable, les noms sont x et y.

Et on peut changer leur position locale via setOrigin, donc ça pourrait très bien devenir le coin bas-gauche.

Avec la SDL, tout ce qui se dessine est affiché dans une Surface, un Rectangle, quoi. Dans ce cas-là, appeler GetRect() renverrait GetPosition() et GetSize(). Ca permettrait de faire des calculs de collision plus généralisés sur des sf::Text et autres.

SFML est un peu moins limité, tout n'est pas affiché dans un rectangle. Ensuite il existe déjà des fonctions pour récupérer les rectangle englobant (local et global) des drawables.

C'est plus court et ça peut être généralisé à Mouse et Joystick. On peut inférer "touche" ou "bouton" puisqu'en effet on ne peut appuyer sur autre chose : "est-ce que le bouton {x} est appuyé ?" => "Est-ce que {X} est appuyé" ? Disons que dans la langue "pressed" est une méthode spécifique aux boutons ^^. Et d'une certaine façon une touche est un bouton. Contrairement à ces deux-là, un clavier ne peut qu'avoir des touches, et il ne peut pas y avoir d'ambiguïté avec des axes ou des molettes.

Mouais. Je préfère plus de verbosité, raccourcir pour raccourcir pour moi ça n'a aucun intérêt.

Pour tenter de raccourcir les noms, à vrai dire.

Raccourcir = retirer de l'information. Aucune justification valable, donc

Oui, c'est le plus important. J'essaie de voir si un compromis n'est pas possible.

Mais pourquoi ? Les noms actuels sont-ils dérangeant ? Et je n'ai pas non plus l'impression qu'ils comportent du superflu.

RenderWindow, RenderTexture
display -> draw
Comme pour les Drawable. C'est peut-être une mauvaise idée mais je suggère quand-même, on sait jamais.

Ah ben non, pour le coup ce serait vachement ambigü. "display" ne me satisfait pas à 100% je l'avoue, mais là ce serait pire

En tout cas, je tiens à te remercier pour cet examen approfondi de l'API et ces suggestions détaillées, même si elles ont buté sur mon mur si difficile à franchir

[Hiura]

isKeyPressed => isPressed

Ensuite, en ce qui concerne isPressed, j'ai rien de spécial contre, mais j'ai rien non plus pour à vrai dire.

Un argument contre : ceux qui veulent utiliser "using namespace sf::Keyboard" ne vont pas aimer.

D'ailleurs, j'ai voulu faire une regex pour remplacer "\.([A-Z])" par "\.upperase(\¡)" mais il n'y a aucune fonction pour ça

Y a toujours des solutions : p.ex. dans vim :s/my\(\a\)\([a-zA-Z0-9]*\)/m_\l\1\2/ pour "mySomeVar" -> "m_someVar".

[Laurent]

Un argument contre : ceux qui veulent utiliser "using namespace sf::Keyboard" ne vont pas aimer.

Aucune chance : c'est une classe
Et de toute façon, même si c'était un namespace, personne de sain mentalement ne voudrait faire ça.

[L01man]

Et on peut changer leur position locale via setOrigin, donc ça pourrait très bien devenir le coin bas-gauche.

Ah, j'ai compris.

Je capitule. Merci à toi de m'avoir expliqué ces choix .
@Hiura : oui, il y a toujours la solution de la regex quand on pas du tout d'accord ^^.

[Hiura]

Aucune chance : c'est une classe

oouuup!