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.
# Ca doit se définir dans les coding guidelines
Posté par Paul POULAIN (site web personnel, Mastodon) . En réponse au journal CamelCase ou lowercase_with_underscore. É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.