Conventions de nomage multi-plateforme
muqaddar
Administrateur
Salut,
Je voulais savoir quelle était la bonne approche pour nommer des variables ou des méthodes en vue d'un portage Web ou sur d'autres plateformes.
Je perds un temps fou quand je réécris des méthodes Objective-C en Ruby par exemple, juste pour changer les dénominations.
Par exemple:
En OC:
- (NSString *)repetitionTextForRepetitionX:(NSUInteger)col repetitionY:(NSUInteger)row
devient en ruby:
def repetition_text_for_repetition_x_and_repetition_y(col, row)
Pour gagner un peu de temps, on pourrait garder:
def repetitionTextForRepetitionXAndRepetitionY(col, row)
Bon, c'est un exemple, parmi tant d'autre, c'est dur d'être habitué à un langage et ses conventions, et de lui faire des entorses.
J'ai pas de solution magique, mais quelle perte de temps !
Un autre exemple est simplement le nom des variables, par exemple wineID et wine_id...etc
Après on peut jouer sur la syntaxe elle-même, en OC:
if ((self.shelf.repetitions_x != 1) || (self.shelf.repetitions_y != 1))
marche très bien en Ruby, mais la convention voudrait:
if self.shelf.repetitions_x != 1 or self.shelf.repetitions_y != 1
Là , c'est entre 2 plateformes, mais j'imagine si on y ajoute le Java...
On comprend mieux ceux qui veulent nous vendre des solutions multi-plateformes... 
En tout cas, on a intérêt d'être sacrément organisé pour faire du multi-plateformes.
Réponses
Chaque langage a ses conventions de nommage et de codage, et c'est bien normal, car chaque langage ayant ses spécificités, les conventions de nommage jouent de ces spécificités. Et certains langages utilisent aussi le principe de Convention-Over-Configuration donc leur convention sont fortement liées avec le langage.
Il est évident que vu les spécificités d'Objective-C " permettant entre autres d'écrire des méthodes aux noms longs avec des paramètres nommés " tu vas avoir des noms de méthodes longs. En Ruby 1.0 tu n'as pas de paramètres nommés, mais tu as plutôt la convention de passer des Hash comme paramètres à tes constructeurs. En Ruby 2.0 tu as des paramètres nommés, mais un peu comme les hash les noms des paramètres ne font pas vraiment partie intégrante du nom de la méthode contraire à l'Objective-C. Du coup c'est forcément impossible d'avoir des conventions de nommage unifiées, ça n'aurait aucun sens.
Pour reprendre ton exemple, en Ruby la convention voudrait plutôt qu'on écrive :
Ou encore
Ou en Ruby 2.0:
Bref, ça ne ressemble plus trop à la "version longue" façon Objective-C, qui elle a pour vocation d'être verbeuse et d'utiliser le CamelCase là où Ruby utilise du underline-separated.
Ce que je déteste des solutions multi-plateformes c'est justement que ça prend le plus petit dénominateur commun de tous les langages et de toutes les plateformes sur lequel ça veut pouvoir être porté, du coup tu perds beaucoup d'avantages de chaque monde (conventions de nommage inclus, ce qui a des conséquences nombreuses car ce n'est pas qu'une question de présentation/lisibilité, mais a des effets également sur le KVC en ObjC, ou sur la convention-over-configuration en Ruby (genre pour ActiveRecord et le mapping des champs de ta base, etc). Du coup ça me parait absurde de vouloir tenter d'unifier tout cela.
Mais si tu respectes les conventions de nommage de chaque plateforme je ne vois pas pourquoi tu ne t'y retrouverais pas. Le mapping de l'un à l'autre est en général cohérent, certes ce n'est pas la même logique de fonctionnement, mais dès que tu bascules d'un langage à un autre normalement tout ton cerveau bascule d'un coup.
C'est comme quand tu parles anglais et français, une fois que tu es fluent tu ne va pas essayer d'appliquer les règles de grammaire et d'orthographe française à la langue anglaise et vice-versa. Quand tu causes en anglais tes phrases se construisent directement en anglais sans se baser sur la phrase française ni essayer de faire de la traduction mot à mot ; et quand tu causes en français tu appliques les règles du français et pas celle de l'anglais.
On est bien d'accord sur le fond: chaque langage a ses spécificités et il faut les respecter au maximum.
En fait, je cherchais à être un minimum fainéant.
Quand je copie une fonction OC vers Ruby, le problème c'est surtout de convertir la syntaxe CamelCase vers UnderlineSeparator. Idem pour les variables qui s'y trouvent.
Personnellement, je préfère le UnderlineSeparator niveau lisibilité. Evidemment, je ne l'utilise pas en OC.
Bref, y'a pas de solution magique, et il faut tout réécrire.
Entre OC et Ruby, y'a des sacrés différences, rien que sur les if, else, end par exemple, et les accolades.
Il y a des convertisseurs qui font OC -> RubyMotion, mais ce n'est pas pareil.
Il faut faire un truc à la mano.
Sinon il y a la solution d'ecrire des modules en C (voire en objC) et d'en faire des modules utilisable sur chaque plateforme,