Journal CamelCase ou lowercase_with_underscore

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
16
24
mar.
2017

En ce beau vendredi de mars, je remets sur la table un éternel sujet philosophique de codeur, à propos duquel chacun a ses préférences et habitudes : la manière d'orthographier les noms de variables et de fonctions. Deux grandes tendances se dégagent :

  • le CamelCase
  • le lowercase_with_underscore

Pour expliquer à ceux qui ne connaissent pas, il s'agit de choisir comment on nomme les symboles (variables, fonctions,
etc.) :

  • CamelCase : le majuscules sont utilisées pour indiquer le début des mots
  • lowercase_with_underscore : tout est en minuscule et les underscores sont séparateurs des mots

Voyons les avantages et inconvénients de chacun.

Avantage de CamelCase :

  • noms plus cours

Avantage de lowercase_with_underscore :

  • on n'a plus besoin de se souvenir si tel acronyme (ex : "PNG") est noté "Png" ou "PNG" (exemple : exportAsPng ou exportAsPNG ?). L'avantage ici est que le code est plus homogène et on retrouve plus facilement les symboles. (j'ai déjà vu des heures perdues à cause de choses comme ça)
  • le refactoring "à la main" (à l'aide de "sed" par exemple) est plus facile.

Exemple pour illustrer :

Code en CamelCase :

int doStep1() {
    /* ... */
}

int doAll() {
    doorOpen();
    doStep1();
    doorClose();
}

Le même en lowercase_with_underscore :

int do_step1() {
    /* ... */
}

int do_all() {
    door_open();
    do_step1();
    door_close();
}

Bref, il y a là un léger avantage pour lowercase_with_underscore.
Je laisse le soin aux commentateurs de fournir leurs arguments.

  • # snake case

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

    J'ai toujours entendu de snake_case plutôt que de lowercase_with_underscore.

  • # _ is for losers

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

    Avec le _ , tu tapes un caractère de plus qu'en CamlCase. Et en plus, la touche contenant le _ est sur une ligne du clavier moins accessible que les autres. Tu augmentes ton stress meta-carpien.

    Là où, c'est fun, c'est en Python où tu mélanges CamlCase et lower_case_sans_underscore, pardon, LowerCaseSansUnderscore.

    Il y a aussi la convention Windows, où toutes les fonctions ou méthodes commencent par une majuscule: une aberration quand tu viens du monde unix.

    La vraie question est quand même: vaut-il mieux écrire en LowerCaseSansUnderscore avec E_m_a_c_s ou en CamlCase avec ViImproved :qw ?

    • [^] # Re: _ is for losers

      Posté par  . Évalué à 9.

      Et en plus, la touche contenant le _ est sur une ligne du clavier moins accessible que les autres. Tu augmentes ton stress meta-carpien.

      C'est moins le cas en Bépo (Alt droit+espace ; il m'arrive même de taper les deux touches en une seule frappe suivant le clavier et l'habitude).

      • [^] # Re: _ is for losers

        Posté par  . Évalué à 1.

        Taper les deux touches en une seule frappe ? J’ai pas tout compris.

        • [^] # Re: _ is for losers

          Posté par  . Évalué à 1.

          Une frappe à deux doigts, majeur et annulaire, pour être précis.

    • [^] # Re: _ is for winners

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

      Avec le _ , tu tapes un caractère de plus qu'en CamlCase

      Oui mais les Majuscules du CamlCase nécessitent d'appuyer sur une touche supplémentaire , ce qui a pour conséquence de grandement fatiguer les auriculaires, chose qui peut être dramatique quand on a envie de se gratter les oreilles.
      Donc le lower_case_avec_underscore est à préférer c'est une question de santé publique. :-D

      kentoc'h mervel eget bezan saotred

      • [^] # Re: _ is for winners

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

        En clavier américain le _ nécessite aussi d'appuyer sur shift. Et le clavier américain est quand même nettement plus pratique quand on programme. Donc je maintiens, _ c'est pour les losers.

        • [^] # Re: _ is for winners

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

          En clavier américain le _ nécessite aussi d'appuyer sur shift

          [div class="mauvaise_foi"]
          Mouai enfin ce que j'en conclu, c'est que le clavier Américain c'est pour les losers.
          [/div]

          kentoc'h mervel eget bezan saotred

    • [^] # Re: _ is for losers

      Posté par  . Évalué à 10.

      Tu remappes ton clavier en inversant le "ù" et le "_" et tu améliores ta productivité de 28,2% tout en réduisant ton stress méta carpien de 79% d'après le Bricolo Institute of Technological Ergonomy.

      Bonus : Sous emacs, on passe en mode "snake case" en tapant Esc-x snake-case-mode

    • [^] # Re: _ is for losers

      Posté par  . Évalué à 4.

      Il y a aussi la convention Windows, où toutes les fonctions ou méthodes commencent par une majuscule: une aberration quand tu viens du monde unix.

      Ça n'est pas particulièrement réservé à Windows. Sous Unix aussi on peut trouver CamelCase (avec première lettre majuscule) pour les fonctions et camelCase (minuscule) pour les variables. Je ne sais plus où j'ai vu ça … il y a bien longtemps. Xt ou Motif peut-être ?
      Et personnellement je trouve cette convention plutôt lisible.

    • [^] # Re: _ is for losers

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 27 mars 2017 à 08:38.

      Avec le _ , tu tapes un caractère de plus qu'en CamlCase. Et en plus, la touche contenant le _ est sur une ligne du clavier moins accessible que les autres. Tu augmentes ton stress meta-carpien.

      Argument totalement subjectif. Mauvais layout, changer layout.

      git is great because linus did it, mercurial is better because he didn't

  • # Que le début

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 24 mars 2017 à 22:02.

    c'est :
    int do_all()
    {
    open_door();
    do_step1();
    close_door();
    }

    parce que bon, le verbe parfois au début, parfois à la fin, ce n'est pas cohérent. mais du coup les 2 fonctions ne sont pas ensemble dans la liste des fonctions, on les perds, donc ne vaut-il pas mieux mettre le nom avant dans tous les cas plutôt?

    voila, de quoi t'amuser encore plus.

  • # Lisp rocks

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

    Le mieux c'est d'utiliser un vrai langage, comme lisp, qui autorise les symboles avec les espaces:

    (defun 'do all')
    ('open the door')
    ('do the first step')
    ('close the door'))

    • [^] # Re: Lisp rocks

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

      Perl6 met tout le monde d'accord avec

      sub do-all() {
      open-door();
      do-step1();
      close-door();
      }
      Et ouais, pendant que les autres s'endorment, il y en a un qui avance ;-)

      https://docs.perl6.org/language/functions

      • [^] # Re: Lisp rocks

        Posté par  . Évalué à 2.

        Les tirets c'est la convention utilisée par Lisp (les espaces dans les symboles n'étant évidemment pas l'approche privilégiée).

        Est-ce que ton message signifie que si on fait du Perl il faudra encore attendre je ne sais combien de temps pour pouvoir utiliser cette convention ? Ça avance, qu'y disaient… pour les autres c'est juste déjà là :)

      • [^] # Re: Lisp rocks

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

        D'ailleurs c'est très agréable (surtout pour les noms de variables) et c'est pertubant quand on revient à du non Perl 6

    • [^] # Re: Lisp rocks

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

      Grave erreur, la touche * ne fonctionnera plus sous Vim pour retrouver tes fonctions facilement dans ton code ? Kesako * ? * c'est lance immédiatement une recherche vers le bas sur le mot qui est sous le curseur. Et par mot, on entend un groupe de lettre dans _[a-Z][0-9], ce qui marche dans pas mal de langage (python, C, java, …).

      Donc, perdant pour Lisp, comme pour Perl6.

    • [^] # Re: Lisp rocks

      Posté par  . Évalué à 3.

      En parlant d'espace, l'espace insécable fonctionne pas mal aussi dans certains langages :)

  • # snake_case

    Posté par  . Évalué à 10.

    Le CamelCase me fatigue plus les yeux et me donne vite l'impression d'être saoul. Je dois probablement être un peu dyslexique.

    Suis-je seul dans ce cas ?

    • [^] # Re: snake_case

      Posté par  . Évalué à 10.

      JeSuisToutAFaitDAccordCEstPasNaturelDeLireCommeÇa.

      Les_underscore_permetent_une_séparation_des_mots_qui_facilite_la_lecture.

  • # camelCase

    Posté par  . Évalué à 4. Dernière modification le 25 mars 2017 à 06:57.

    on n'a plus besoin de se souvenir si tel acronyme (ex : "PNG") est noté "Png" ou "PNG" (exemple : exportAsPng ou exportAsPNG ?).

    À mon avis on a surtout intérêt à conserver les acronymes en majuscule, en serpent comme en chameau…

    Par ailleurs, c’est "camelCase" généralement, la première lettre est en minuscule. "camel" signifie indifféremment "chameau" ou "dromadaire" dans le langage courant ;)

    • [^] # Re: camelCase

      Posté par  . Évalué à 7.

      c’est "camelCase" généralement, la première lettre est en minuscule

      Oui. Avec la première lettre en majuscule, c’est plutôt PascalCase. Et pour les mettre d’accord, rien de tel que programmer en Go : une majuscule indique que le symbole est public, une minuscule qu’il est privé.

      "camel" signifie indifféremment "chameau" ou "dromadaire" dans le langage courant ;)

      C’est forcément « dromadaire » dans ce cas, puisque le mot camelCase n’a qu’une bosse.

      • [^] # Re: camelCase

        Posté par  . Évalué à 0.

        C’est forcément « dromadaire » dans ce cas, puisque le mot camelCase n’a qu’une bosse.

        J’allais arguer que l’on peut avoirTroisMots, mais effectivement, je pense que si on arrive pas à se limiter à deux mots pour le nom d’une fonction on prend une mauvaise direction… :)

        • [^] # Re: camelCase

          Posté par  . Évalué à 4.

          Bof… Pourquoi ? Un nom comme getElementsByClassName ou addEventListener, c’est mal ?
          J’en fais régulièrement des semblables, moi aussi.

          • [^] # Re: camelCase

            Posté par  . Évalué à 3.

            Oui tu as raison… ma remarque n’est pas pertinente.

    • [^] # Re: camelCase

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

      Le problème, c'est ConvertPNGToJPEG ou on a tendance à ne pas voir que le T ne fait pas partie de l'acronyme. ConvertPngToJpeg n'a pas ce problème.

      (Vu aussi, mais j'aime pas du tout cette solution: ConvertPNGtoJPEG)

      • [^] # Re: camelCase

        Posté par  . Évalué à 4.

        ConvertPNG2JPEG :)

      • [^] # Re: camelCase

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

        ConvertPortableNetworkGraphicsToJointPhotographicExpertsGroupPicture aussi appelée ConvertInternationalOrganizationForStandardization15948To10918Dash1UitDashTRecommendationTDot81 ?

        • [^] # Re: camelCase

          Posté par  . Évalué à 6.

          Y a du mieux, mais je trouve qu'il manque que l'on parle d'image, et du coup c'est assez peu lisible et rend les regex compliquée pour rechercher.
          Pourquoi pas un
          ConvertFromInputGraphicFileFormatAsPortableNetworkGraphicsToOutputGrapchicFileFormatAsJointPhotographicExpertsGroupPicture
          Du coup, les regex en devienne plus simple et tu peux trouver rapidement les fonction qui font des convertion vers un format de fichier, qui traite les types image, etc :)
          Le FromInput et ToOutput évitent de plus les comflit avec des From ou To qui peuvent être fréquent dans cette nomenclature précise

          • [^] # Re: camelCase

            Posté par  (Mastodon) . Évalué à 5. Dernière modification le 28 mars 2017 à 13:39.

            ConvertFromInputGraphicFileFormatAsPortableNetworkGraphicsTo
            OutputGra pch icFileFormatAsJointPhotographicExpertsGroupPicture

            C'est un coup à rater ta regexp ça !

  • # Mixed_Case_With_Underscores

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

    En Ada, le style recommandé est un mix des deux : CamelCase et underscores entre chaque mot.
    Les noms sont forcément plus longs, mais c'est dans la philosophie du langage (rendre le code plus « littéral »).

    procedure Do_All is
begin
   Open_Door;
   Do_Step_1;
   Close_Door;
end Do_All;

    Un bon éditeur de code permettra de formater automatiquement du code tapé au kilomètre initialement en minuscules avec underscores vers du Mixed_Case_With_Underscores.

    Un des avantages des underscores est de permettre d'écrire plusieurs noms ou acronymes de suite en respectant leur casse originelle et tout en restant lisible (OpenGL_VBO plutôt que OpenGLVBO ou OpenglVbo).

  • # pas facile

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

    Personnellement j'étais adepte des underscores pour les nombreuses raisons sus-citées et puis un jour j'ai du utiliser une grosse lib qui est entièrement en camelCase et le mélange des deux styles m'a tellement fait grincer des dents que finalement je suis passé au camelCase (mais pas à 100%, en guise de marque de soutien aux underscores, j'ai gardé les noms de variables en underscores). Et convertir toute une base de code de underscore en camelCase c'est pas mal de boulot quand on part de quelque chose d'un peu gros!

    En plus ça n'a pas entièrement résolu le problème esthétique puisqu'en c++ , la lib standard est 100% underscores (les std::unique_ptr etc)..

    Et j'ajouterais que le dilemme de l'homogenéité ne s'arrête pas à camelcase vs underscores, il y a aussi le choix du langage. On est a peu près tous d'accord pour coder en anglais, mais lequel, l'anglais des américains (les fonctions s'appellent 'initializeMachin' et 'getColorOfTruc' ), ou l'anglais des anglais (les fonctions s'appellement alors 'initialiseMachin' et 'getColourOfTruc'). Là aussi mieux vaut choisir parce que le mélange des deux est vraiment pas terrible.

    • [^] # Re: pas facile

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

      Proposition du committee for bikeshedding and regexpping the world:

      [Cc] = [Gg]et_?[cC]olou?r\(_?[pP]lease\)?()

      Mais c'est chiant à taper, même sur un bepo. Et je ne vous parle pas du sed.

    • [^] # Re: pas facile

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

      La liberté de choisir son style de nommage dans certains langages (C/C++ notamment) m'a pas mal perturbé pour les mêmes raisons : comment avoir un style homogène quand les dépendances ont des styles différents ? Du coup, j'ai passé beaucoup de temps à me chercher mon style sans jamais être satisfait (en plus du fait que ça m'a coûté du temps pour aucune production)…

      Au final, je suis content quand le langage que j'utilise propose de lui-même une convention (même si je la trouve moche), car elle sera très largement suivie par tous ses utilisateurs et garantira une certaine homogénéité et donc une meilleure lisibilité du code. (Et ça fait des questions en moins à se poser.)

      • [^] # Re: pas facile

        Posté par  . Évalué à 4.

        Effectivement le plus gros problème c'est la non-homogénéité. Personnellement sur un projet que je ne débute pas je m'en fiche de la convention (je m'adapte facilement), mais je déteste quand chacun a fait sa petite sauce.

        Et quand c'est moi qui débute un projet, camelCase. Je cherche la concision et je trouve que dans ce cas c'est le meilleur choix.

        Il y a d'ailleurs un gros framework avec cette convention, c'est Qt. Et c'est un vrai bonheur.

    • [^] # Re: pas facile

      Posté par  . Évalué à 2.

      On est a peu près tous d'accord pour coder en anglais

      A condition de savoir le manier, sinon c'est illisible.

      
// Show when GPS are nt tunrd off
public bool GPS_return_carto(int switch)

      Wut ?

      " Chéri, si tu sais pas parler anglais, essaie le français… Normalement, tu devrais mieux le maîtriser (j'espère)… "

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Les deux

    Posté par  . Évalué à 6. Dernière modification le 25 mars 2017 à 10:36.

    Un mélange des deux pour s'y retrouver plus facilement dans le code.

    Par exemple, dans le fichier truc.h (les fonctions seront définies dans truc.c):

    int truc_new(...);
int truc_open(...);
int truc_exportCsv(...);
int truc_convertToFloat(...);

    L'avantage étant qu'en lisant le nom de la fonction on sait directement où trouver sa déclaration et sa définition.
    Le fichier contenant le point d'entrée du programme porte le nom du programme.
    Les fonctions définies dedans sont statiques et ne sont pas préfixées.

    Les callbacks portent un suffixe "_cb".

    Les vrais naviguent en -42

    • [^] # Re: Les deux

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

      Cette notation est aussi liée à une limitation du C, avoir un préfixe truc_ permet d'éviter le name-clash entre différents fichiers / bibliothèques et d'avoir ainsi des fonctions différentes.

  • # pendant qu'on y est

    Posté par  . Évalué à 3. Dernière modification le 25 mars 2017 à 14:43.

    Puisque le sujet est sur le tapis, utilisez-vous des styles différents ou des préfixes/suffixes pour :
    - les variables globales
    - les variables locales
    - le préprocesseur / les variables globales en début de script
    - les pointeurs / les descripteurs de fichiers
    ?

    • [^] # Re: pendant qu'on y est

      Posté par  . Évalué à 2.

      Oui justement je me posais la question pour les variables globales.
      Pour l'instant je les écris en minuscules, mais je fais des programmes assez courts.
      Pour les plus long ce serait bien de les distinguer.
      J'espérais un avis éclairé de Linus Torvalds dans son papier un poil intégriste sur le Linux kernel coding style, mais même pas :

      Global variables (to be used only if you really need them) need to have descriptive
      names, as do global functions. If you have a function that counts the number of active
      users, you should call that count_active_users() or similar, you should not call
      it cntusr().

      Pour le reste il donne des conseils sur la façon de nommer les variables, mais rien sur la façon de les écrire.

    • [^] # Re: pendant qu'on y est

      Posté par  . Évalué à 2.

      • Constantes : MAJUSCULES​
      • Variables globales : minuscule
      • Le reste : pas de préfixe/suffixe/autre spécificités

      Je suis tombé une fois sur un programme utilisant la Notation Hongroise, je suis un peu mort à l'intérieur… Ça semble utile au premier abord, mais finalement ça complexifie tellement la lecture que ça en est contre productif…

    • [^] # Re: pendant qu'on y est

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

      Chez moi, c'est:
      - g pour les globales,
      - f pour les "fields" (champs) dans un objet,
      - k pour les constantes (oui, le style a été défini par un développeur allemand)
      - majuscules pour les macros du préprocesseur
      - rien pour les variables locales (tout en minuscules)
      - * pour les pointeurs ;)

      Suivi du nom en PascalCase, pour ne pas avoir deux minuscules au début du nom.

      Les noms de types commencent par une majuscule, ce qui permet de les distinguer tout de suite des variables.

      Cela dit l'important est bien sur de choisir un style dans un projet, et de s'y tenir. Et de suivre les recommandations du langage utilisé quand il y en a (PEP8 pour Python je crois?)

  • # Comme les dieux l'ont voulu

    Posté par  . Évalué à 2.

    On ne devrait même pas se poser la question et juste utiliser la convention "standard" utilisée par les concepteurs du langage:
    - lowercase_with_underscores pour C
    - camelCase pour Java
    etc…

    Pourquoi utiliser autre chose et perturber le lecteur qui est habitué à une façon de faire ?

    • [^] # Re: Comme les dieux l'ont voulu

      Posté par  . Évalué à 7.

      OK pour Java, mais pour le C, je me demande d’où tu sors que le « lowercase with underscores » serait la convention « standard »…

      Si on regarde la liste des fonctions de la bibliothèque C standard, la convention, s’il y en a une, serait plutôt quelque chose du genre « lowercase, mots raccourcis au maximum, sans underscore, et utilisation intensive de préfixe et de suffixe ». Quelques exemples :

      • setlocale
      • atoi (et fonctions assimilées : atol, atoll, atof, strtod, strtol, strtoul)
      • csqrt (pour complex square root)
      • casinh (pour complex arc sine hyperbolic)
      • isalnum (pour is alpha-numeric character, et assimilés comme iscntrl pour is control character)
      • tolower
      • setjmp/longjmp (important, l’abbréviation de jump en jmp, il n’y a pas de petites économies)
      • strcpy, strncpy, strlcpy
      • mktime
      • etc.

      Avec tout le respect que j’ai pour les concepteurs du C, je ne pense pas que ce soit un exemple à suivre…

      • [^] # Re: Comme les dieux l'ont voulu

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

        Si je me souviens bien, il fût un temps où, lors de l'édition de liens d'un programme C, seuls les 6 premiers caractères d'un symbole étaient pris en compte, et la casse était ignorée. D'où, sans doute, la concision des identifiants de la bibliothèque standard…

        Pour nous émanciper des géants du numérique : Zelbinium !

        • [^] # Re: Comme les dieux l'ont voulu

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

          En fait il y a toujours une limite à la longueur prise en compte pour les symboles. Actuellement, elle est… définie par l'implémentation!
          Pour GCC et LD, elle est fort heureusement à bien plus de 6 caractères.

          • [^] # Re: Comme les dieux l'ont voulu

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

            Comme quoi une connaissance fine des standards C permet de temps à autre de briller en société! ;)

          • [^] # Re: Comme les dieux l'ont voulu

            Posté par  . Évalué à 4.

            Pour être plus précis, elle a toujours été définie par l'implémentation. Mais la norme indique un nombre minimums de caractères à supporter :

            The implementation shall be able to translate and execute at least one program that contains at least one instance of every one of the following limits:
            …
            * 63 significant initial characters in an internal identifier or a macro name (each universal character name or extended source character is considered a single character)
            …

            (extrait de C99)

            Ce qui veut dire qu'un compilo peut parfaitement respecter cette norme en ne considérant que les 63 premiers caractères des identifiants internes. Un identifiant d'une taille supérieure, même si il fonctionnerait sur votre implémentation, serait donc potentiellement non portable. Donc il y a un bien une limite pratique de 63 caractères pour les identifiants internes, 31 pour les externes. C11 ne change pas ce point, mais C89 avait bien une limite à 6 caractères (en pratique toujours, mais rien n'interdisait aux compilos de la repousser à ma connaissance).

            • [^] # Re: Comme les dieux l'ont voulu

              Posté par  (site web personnel) . Évalué à -1. Dernière modification le 27 mars 2017 à 22:08.

              Pour les normes C d'il y a 30 ans, passons, historique, limitations d'alors, tout ça.

              Mais pour des normes modernes comme C11, pourquoi ne pas déléguer le raccourcissement des identifiants au compilo (de toute façon au final dans le binaire c'est qu'une adresse, donc à taille prédictible ?) mais autoriser une taille arbitraire (ou en tout cas bien au dessus de 64 caractères…) dans le code source ? Surtout quand il faut gérer un namespace en préfixant les noms de fonction à défaut de l'avoir dans le langage…

              Je comprends bien la nécessité que le code final soit minimal car pouvant cibler du matériel hyper limité (mais cf. ma première parenthèse), mais pour la lisibilité et le confort du code source ? C'est C*11* bordaÿl, et des concurrents sur le marché du code natif (mais bien en avance sur la sécurité et autres problèmes du C) à la Go arrivaient.

              • [^] # Re: Comme les dieux l'ont voulu

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

                Parce que la norme C se veut la plus simple possible, afin qu'on puisse créer des compilos conformes à elle, mais adaptés aux besoins de chacun ?

                • [^] # Re: Comme les dieux l'ont voulu

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

                  Ah oui c'est simple de mettre partout bof démerdez-vous dans le compilo. Enfin, simple pour les auteurs de la pseudo-norme, quoi.

                  C'est vrai que "bah ché pas regardez comment ça compile" c'est vachement plus simple que "la limite de nom de symbole dans le source est 65535 (par exemple) caractères, pas plus, mais pas moins".

                  On doit pas avoir la même notion de simplicité.

                  Ici on aime bien se marrer en se frappant les côtes sur "Java write once run anywhere hahaha les cons une fois j'ai vu un bug, t'imagines l'arnaque" mais apparemment C c'est "write once, compile maybe once", sympa.

                • [^] # Re: Comme les dieux l'ont voulu

                  Posté par  . Évalué à 4.

                  C'est un peu la réponse toute faite qui est sortie à chaque fois qu'on voit des choses pas décrites dans les normes C et C++. Par contre je n'ai jamais vu de cas réel d'utilisation. J'ai l'impression que c'est surtout lié à l'historique, que ce sont des langages qui sont sortie à une époque où créer une norme exhaustive n'était pas vraiment possible (si on avait la prétention d'aller sur tout les matériels et sur tout les OS).

                  C'est aussi l'impression que ça me donne quand je vois après coup que finalement, chaque version des standards réduit ces zones troubles (exemple en C++) et que ça n'a pas l'air de particulièrement émouvoir les concepteurs de compilateurs.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Comme les dieux l'ont voulu

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

                    Je dirai que l'embarqué est une raison ?
                    Ca facilite l'écriture de compilateurs, et ça permet de prendre des décisions arbitraires pour permettre des optimisations spécifiques aux utilisateurs. Par exemple, un compilo pourrait préférer que "null" soit 42 et pas 0, parce que ça permet d'avoir une valeur par défaut utile pour l'usage prévu du langage C, et une meilleure valeur par défaut, c'est moins de code, et moins de code, c'est moins de bug et d'analyse statique.

                    Bref, autant ça me paraissait bizarre voire gênant auparavant, autant aujourd'hui je trouve que ça a son utilité. Oui, je trouve que c'est OK pour C (qui pue), mais non, je ne voudrais pas de ce comportement pour Java (qui pue aussi), car leurs usages sont différents.

                    • [^] # Re: Comme les dieux l'ont voulu

                      Posté par  . Évalué à 3.

                      C'est trop théorique pour me convaincre. Avoir des comportements si étranges et plus générateur de bug qu'autre chose. Chercher de la micro optimisation de taille de code alors qu'elle ne te coûte rien et qu'elle n'impacte pas le volume de code exécuté, c'est pas une bonne idée à mon avis.

                      L'exemple que je donne en C++ me parle un peu plus. Une machine utilisant une pile plutôt que des registres (je ne connais que des machines virtuelles qui font ça) peut vouloir changer l'ordre.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Comme les dieux l'ont voulu

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

                        Les versions successives des standards peuvent réduire les zones "troubles" parce qu'il y a une convergence qui se fait petit à petit sur les architectures matérielles. Il faut voir que le C avant 1989, ça devait marcher sur un 286 (avec de l'adressage en segment:offset), sur des microcontrôleurs genre PIC16 (architecture 12 bits), et sans doute sur plein d'autres trucs obscurs (machines à pile, microcontrôleurs avec un seul ou deux registres, architecture mémoire avec des banques, représentation des nombres signés autrement que par le complément a 2, exceptions matérielles en cas d'overflow ou de division par 0 ou pas, …)

                        Tous ces trucs pas définis ou définis par l'implémentation viennent de là. Il en reste encore aujourd'hui, par exemple un microcontrôleur assez populaire qui se programme en C est le MSP430: pointeurs sur 20 bits, mais registres sur 16, et du coup c'est une des architectures ou size_t ne fait pas la même taille que void*.

                        Le C, comme le C++, sont avant tout des langages conçus pour la programmation système. C'est à dire des trucs bien bas niveau, directement aux prises avec le matériel. Ils ont aussi trouvé un marché dans tous les machins où la performance est critique.

                        Pour le reste, il est effectivement beaucoup plus malin de prendre un langage qui garantit un environnement d'exécution identique, quel que soit le CPU en dessous. C'est le cas de Java, par exemple, qui a repris en gros la syntaxe du C (avec des objets) mais spécifié systématiquement tous les comportements. Et aujourd'hui il y a plusieurs autres choix dans ce domaine. Mais ça n'empêche qu'on a toujours besoin d'un langage qui puisse s'adapter au matériel et aux outils utilisés, pour tout ce qui est bas niveau. Et non, tout faire en assembleur n'est pas une option raisonnable :)

                        • [^] # Re: Comme les dieux l'ont voulu

                          Posté par  . Évalué à 3.

                          Ça se rapproche de ce que j'écrivais 2 messages plus haut, on est d'accord :)

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Comme les dieux l'ont voulu

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

                          Ça permet aussi d'écrire des petits compilateurs et rapidement. Car le langage de base est très rudimentaire et laisse beaucoup de charge sur le développeur de l'application.

                          Pour les concepteurs de cartes électroniques c'est un facteur important. Cela explique aussi pourquoi le C est très utilisé en embarqué et est probablement le langage le plus porté en nombre d'architectures matérielles.

              • [^] # Re: Comme les dieux l'ont voulu

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

                C'est pour pouvoir cibler des OS hyper limités. En l'occurrence, ça viendrait plus du format des fichiers objets intermédiaires (les .o utilisés par le linker), que des binaires générés. Et aussi des cas ou il y a de l'édition de liens dynamique (.so, .dll, tout ça). Pour les identifiants externes limités à 31 caractères, en tout cas. Pour les internes, je sais pas, je suppose que c'est juste qu'un développeur de compilateurs moisis est dans le commité de normalisation et n'avait pas envie de changer son #define pour la longueur des identifiants?

      • [^] # Re: Comme les dieux l'ont voulu

        Posté par  . Évalué à 3.

        Décider d’une convention standard différente de celle de la libc pour un programme qui utilise la libc ça permet justement de distinguer les symboles de son propre programme des symboles de la libc ?

        Après je ne sais pas, je ne fais pas de C. Peut-être que tous les programmeurs C connaissent toutes ces fonctions par cœur…

  • # On s'en fiche

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

    L'important c'est d'avoir des conventions, que ça soit au niveau du langage ou juste du projet, et que tout le monde les respectes.

    Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

  • # Dépend du langage

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

    Je préfère le snake_case. je le trouve plus homogène surtout dans ce genre de cas :

    • create_http_request
    • createHttpRequest
    • createHTTPRequest ? lequel choisir en CamelCase ?

    Cependant, certains langages viennent avec des recommandations, comme python, rust, java, javascript. Alors dans ces cas là il faut suivre la convention même si elle plait pas :

    • camelCase pour C#, Java, Swift, JavaScript
    • snake_case pour ruby, python, rust

    git is great because linus did it, mercurial is better because he didn't

  • # Ca doit se définir dans les coding guidelines

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

    Pour ma part, en bon normand que je ne suis pas, j'ai envie de répondre "ptet ben qu'oui, ptet ben qu'non".
    En fait, la problématique, c'est d'être consistant au sein d'un projet.
    On n'arrivera jamais à départager les partisans de l'un ou de l'autre, parce qu'il n'y a pas d'argument définitif qui fait pencher la balance.
    Donc il faut juste faire un choix et s'y tenir dans les coding guidelines d'un projet. De même pour savoir si on et do_fonction ou fonction_do, si on indente avec 2 ou 4 espaces ou des tabulations, si ou on met du singulier, du pluriel dans les noms des tables de la base de données, si on utilise le mot "add", "new", "create" pour l'action d'ajouter une donnée et "modify", "mod", "update" pour la modifier.
    Doit-on écrire : ModName, name_update, NameModify, moi je m'en moque, chacun aura des arguments ad-libitum. Donc il faut juste choisir, et s'y tenir.

    • [^] # Re: Ca doit se définir dans les coding guidelines

      Posté par  . Évalué à 2.

      Merci Paul, enfin !

      En parcourant le fil, je n'ai pu que constater que globalement, les réponses sont attendues par rapport sujet. Ca serait un peu pareil en lançant en l'air "alors, slip ou caleçon ?", il y en aurait pour axer sur le confort, d'autres la tenue, … sans compter ceux qui diraient "les deux" ou "moi je préfère les slips kangourou de papy" (c'est pour les fans de Perl).

      En matière de convention d'écriture, il faut commencer par appliquer les conventions du langage ! Et si c'est insuffisant, compléter et essayer de s'y conformer (il existe d'ailleurs des outils pour nous aider : les IDE, mais aussi clang-format, pep8 pour Python, …).

    • [^] # Re: Ca doit se définir dans les coding guidelines

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

      être consistant au sein d'un projet

      Cohérent, uniforme, homogène… Pas "consistant".

  • # A mort CamelCase

    Posté par  . Évalué à 2.

    Quand tu vois du code avec 2 fonctions treatBCCH et treatBcch :-( :-(
    Une notation qui ne fonctionne pas bien avec des acronymes est une notation de m..

    Je ne sais pas pourquoi elle est si populaire.

Suivre le flux des commentaires

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