Journal mixedCase or not ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
29
déc.
2007
Bonjour mon journal,

En cette fin d'année 2007, je voudrais connaitre les goûts majoritaires en matière de nommage de classes/fonctions/variables. J'ai en effet l'impression que le mixedCase a définitivement remporté la bataille, principalement à cause des légions de developpeurs Java qui ont été nourris à ça. Personnellement, je trouve QueCEstAssezLourdAECrireEtDifficileALire et j'aime bien mettre des underscores dans mes noms de variables et de fonctions, en gardant des classes en MixedCase. Le problème c'est que la plupart des libs que j'utilise sont en mixedcase, et le melange des genres c'est pas beau ..

Alors toi lecteur, comment nommes tu tes variables et tes fonctions dans ton langage favori ?

  • # Fillette !

    Posté par  . Évalué à 2.

    Les vrais programmeurs ils utilisent pas de noms de variable, ils utilisent directement les registres ou des adresses mémoire.

  • # Chacun décide.

    Posté par  (site web personnel) . Évalué à 2.

    C'est un peu comme l'utilisation de tab ou d'espace.
    L'un n'est pas meilleur que l'autre[1] mais l'important c'est d'être consistant.

    Moi j'utilise le CamelCase car j'utilise Qt.

    [1] enfin si les tabs sont mieux c'est connu.

  • # _

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Je trouve le mixed case trop compliqué à lire et pénible à écrire. Du coup j'utilise des _. Je trouve ça beaucoup plus facile à retenir alors avec les majuscules je dois chaque fois relire pour me souvenir du nom de la fonction/variable.

    De toutes façons, le java, ça pue...

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: _

      Posté par  . Évalué à 2.

      à ce propos, savez-vous si avec les outils basés sur GTK il est possible de sélectionner automatiquement l'ensemble d'une Variables_dans_ce_style1 en double cliquant dessus ? Sur tous les outils que je connais basés sur gnome, gtk et compagnie, pour reprendre l'exemple de Variables_dans_ce_style1 , si je clique sur "style", cela sélectionne uniquement le mot style, et non pas la variable complète (sur les trucs basés sur qt, cela sélectionne tout). Du coup c'est super lourd pour travailler avec cela.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: _

      Posté par  . Évalué à 1.

      Du coup j'utilise des _. Je trouve ça beaucoup plus facile à retenir alors avec les majuscules je dois chaque fois relire pour me souvenir du nom de la fonction/variable.

      Ah, tandis qu'avec les '_', il te suffit d'en voir un pour te souvenir automatiquement de quoi il s'agit..
      Genre "loopIndex" tu comprends pas, mais "loop_index", oui ?
      Hé bé....

      • [^] # Re: _

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Ben oui. C'est juste de un mix de la mémoire visuelle/auditive. Je peux pas t'expliquer mais si tu me dit :

        TheLoopIndex , j'ai du mal à lire, à comprendre, à retenir le nom et à retenir où sont les majuscules.

        the_loop_index : là le vois tout de suite et je retiens car le "_" est un caractère qui a une signification (comme un espace).

        C'est con mais pour les longs codes complexes, chez moi ça joue beaucoup.

        (mais c'est entièrement subjectif et personnel. l'auteur du journal demandait notre avis perso après tout)

        Mes livres CC By-SA : https://ploum.net/livres.html

  • # mmh

    Posté par  . Évalué à 2.

    Ca dépend des conventions en cours dans les différents langages.

    En C il me semble que le mixedCase est quasi-proscrit, l'habitude étant plutôt aux minuscules_avec_des_underscores.
    En Python la convention recommandée (PEP 8) est CamelCase pour les noms de classe, et minuscules_avec_underscores pour les variables, fonctions et méthodes.

    Note que le mixedCase est assez pénible quand tu as des attributs qui correspondent à des colonnes dans une base de données par exemple.

    Par ailleurs avec un clavier AZERTY le mixedCase est plus pénible à taper que les minuscules_avec_underscores, car le '_' ne demande pas l'utilisation de la touche shift.

    C'est vrai que dans les langages de mangeurs de quiche (Java, PHP), le mixedCase semble s'être imposé (de façon totalement absurde en PHP où les noms de fonctions sont de toute façon case-insensitive...).

    • [^] # Re: mmh

      Posté par  (site web personnel) . Évalué à 1.

      Ça dépend de ton clavier AZERTY ... Sur le mien, le '_' est obtenu avec la touche majuscule (au dessus du '-').

  • # Re:

    Posté par  . Évalué à 1.

    Ça dépend.

    Pour une lib j'utilise souvent le MixedCase. Pour le reste, j'utilise le pas_mixed_case.

    Je préfère le pas_mixed_case. Mais c'est un détail. Un choix de nom de variable (ou famille de variables), qu'il soit MixedCase ou non, est beaucoup plus important.

    L'intérêt du MixedCase, et notamment pour des langages type C++, est que les noms sont plus courts :
    MaClasseQuiVaBien::EtUneVariableMemble
    ma_classe_qui_va_bien::et_une_variable_memble

  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # re: mixedCase or not ?

    Posté par  (site web personnel) . Évalué à 1.

    Il n'y a pas que ce problème...

    Déjà les noms de variable... je m'efforce d'utiliser la langue anglaise ce qui a tendance à donner des noms de variables qui ne veulent rien dire...

    Les espaces ou tabulation, j'ai été habitué à utiliser des espaces bien qu'il semble évident que les tabulations soient mieux :
    Chaque dev peut mettre la largeur qu'il veut dans son éditeur. Plus rapide à taper si l'éditeur n'est pas foutu d'indenter comme un grand.
    Maintenant mes codes sources se prennent régulièrement des :%s/ /\t/g histoire d'homogénéiser.

    Les accolades en C/C++/Java/PHP...
    J'ai appris en C à utiliser la forme (on regarde que les accolades) :

    void ma_fonction(int param)
    {
    int i;
    for(i = 0; i < 10; i++)
    {
    printf("%d", i);
    }
    }

    Mais ensuite j'ai dev un projet avec Gtk et j'ai suivit les recommandations du coup c'est devenu un truc du genre :
    void ma_fonction(int param)
    {
    int i;
    for(i = 0; i < 10; i++){
    printf("%d", i);
    }
    }

    Et enfin, je me suis mis au Java ce qui me donne :
    void ma_fonction(int param) {
    int i;
    for(i = 0; i < 10; i++) {
    System.out.println(i);
    }
    }

    Alors personnellement, je suis plutôt en faveur de :

    blabla
    {
    mon code;
    }

    Car si blabla est un test, on peut le commenter rapidement //blabla pour que le block s'exécute en permanence. (parfois utile pour débuguer)
    Ça donne un code plus aéré et les blocks sont mieux mis en valeur.



    Mais bon, avant chaque projet, j'en parle avec les autres pour qu'on se mette d'accord car après tout, je suis capable de m'adapter.
    À noter que lorsqu'on dev avec Eclipse en Java, on a droit à des warning concernant le nommage de nos classes et packages (concernant la casse);


    (À savoir aussi que j'ai appris à coder sur le net, en cours tout ce que j'ai appris c'est l'ADA...)

  • # underscores !

    Posté par  . Évalué à 1.

    Je trouve le CamelCase franchement illisible.

    Pourquoi pas un mélange des genres ? Au contraire ça permettrait de bien dissocier mes_fonctions de cellesDeLaLib. Le coding-style parfaitement homogène, si c'est pour s'imposer des règles qu'on ne supporte pas...

    Sinon, emacs propose le "glasses-mode" qui remplace (visuellement) les identifiants camelCase par leur équivalents en underscore (camel_Case). Par contre ça pose quelques problèmes de cohérence: est-ce qu'on travaille sur l'original ou le proxy underscoré ? ("search" fonctionne avec le terme d'origine, mais les query-replace ne marchent plus du tout...). Les autres éditeurs ont peut-être un équivalent.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.