Est-ce une bonne idée de coder en dur les valeurs dans nos applications?

Oui, mais rendez-le évident .

À faire:

• utiliser des constantes
• utiliser un descriptif nom de variable

Ne pas « t:

• avoir des nombres magiques flottant autour du code

Commentaires

• Ce qui est plus propre, diameter = 2 * radius ou diameter = RADIUS_TO_DIAMETER_FACTOR * radius? Il existe en effet des cas de coin où un nombre magique peut être une meilleure solution.
• Je ne peux ‘ être daccord avec Cette réponse suffit. Jai tendance à penser à la programmation comme à être romancier. Vous racontez votre histoire à travers le code et si les gens ne peuvent pas comprendre la logique, cela rend votre code sans valeur à mon avis. Cela ‘ s pourquoi des conventions de dénomination bien pensées sont essentiellement destinées à la lisibilité. De plus, il ny a aucune bonne raison dutiliser des nombres magiques. En utilisant des nombres magiques, vous supprimez le  » pourquoi  » de léquation et rendre plus difficile la sous tand. Par exemple:  » diamètre = 2 * rayon  » À quoi servent les deux? Ce  » diamètre = RADIUS_TO_DIAMETER_FACTOR * rayon  » a beaucoup plus de sens.
• diamètre = 2 * le rayon est directement de maths du secondaire. Si vous ne nommez pas le  » 2 « , pour quil ait une valeur de quoi que ce soit dautre, il faudrait modifier les lois de physique ou maths, ou les deux. (Dun autre côté, nommer Pi ou constante de Plancks est une bonne idée pour une lisibilité simple).
• @Joonas: Pfft. Vous voulez sûrement dire diameter = radius << 1? Je suppose que cela pourrait aussi être diameter = radius << RADIUS_TO_DIAMETER_BITS_TO_SHIFT.
• comment ‘ à propos de diameter = radius.toDiameter()

Ce que je trouve étrange à propos de cette question & R jusquà présent, personne na en fait tenté de définir clairement le « code en dur » ou, plus important encore, les alternatives.

tl; dr : Oui, est parfois une bonne idée de coder en dur les valeurs, mais il n’y a pas de règle simple quant à quand ; cela dépend complètement du contexte.

La question se résume à valeurs , ce que je considère comme des nombres magiques , mais la réponse à savoir si elles « sont une bonne idée ou non est relative à ce à quoi elles » sont réellement utilisées!

Plusieurs exemples de « codés en dur « les valeurs sont:

• Valeurs de configuration

  Je grince des dents chaque fois que je vois des déclarations comme command.Timeout = 600. Pourquoi 600? Qui a décidé cela? Est-ce que cela a expiré avant et que quelquun a soulevé le délai comme un hack au lieu de résoudre le problème de performance sous-jacent? Ou sagit-il réellement dune attente connue et documentée pour le temps de traitement?

  Ces constantes ne devraient pas être des nombres magiques ou , elles devraient être externalisées dans un fichier de configuration ou une base de données quelque part avec un nom significatif, car leur valeur optimale est déterminée en grande partie ou entièrement par lenvironnement dans lequel lapplication sexécute.

• Formules mathématiques

  Les formules ont généralement tendance à être assez statiques, de sorte que la nature des valeurs constantes à lintérieur nest pas vraiment particulièrement importante. Le volume dune pyramide est de (1/3) b * h. Est-ce que nous nous soucions doù viennent les 1 ou 3? Pas vraiment. Un intervenant précédent a souligné à juste titre que diameter = radius * 2 est probablement meilleur que diameter = radius * RADIUS_TO_DIAMETER_CONVERSION_FACTOR – mais cest une fausse dichotomie.

  Ce que vous devriez faire pour ce type de scénario est de créer une fonction . Je nai pas besoin de savoir comment vous avez trouvé la formule, mais jai encore besoin de savoir à quoi ça sert . Si, au lieu de nimporte laquelle des absurdités écrites ci-dessus, jécris volume = GetVolumeOfPyramid(base, height) alors tout devient soudain beaucoup plus clair, et il est parfaitement normal davoir des nombres magiques à lintérieur la fonction (return base * height / 3) car il « est évident quelles » font simplement partie de la formule.

  La clé ici est bien sûr davoir fonctions courtes et simples . Cela ne fonctionne pas pour les fonctions avec 10 arguments et 30 lignes de calculs. Utilisez la composition de fonctions ou les constantes dans ce cas.

• Domaine / règles métier

  Celui-ci est toujours la zone grise car il dépend de la valeur exacte. La plupart du temps, ce sont ces nombres magiques particuliers qui sont candidats à la transformation en constantes, car cela rend le programme plus facile à comprendre sans compliquer la logique du programme. Considérez le test if Age < 19 vs if Age < LegalDrinkingAge; vous pouvez probablement comprendre ce qui se passe sans la constante, mais cest plus facile avec le descriptif title.

  Ceux-ci peuvent également devenir des candidats à labstraction de fonction, par exemple function isLegalDrinkingAge(age) { return age >= 19 }. La seule chose est que souvent votre logique métier est beaucoup plus compliqué que cela, et il peut ne pas être logique de commencer à écrire des dizaines de fonctions avec 20 à 30 paramètres chacune. Sil ny a pas dabstraction claire basée sur des objets et / ou des fonctions, le recours aux constantes est OK.

  La mise en garde est que si vous « travaillez pour le service des impôts, cela devient vraiment, vraiment fastidieux et honnêtement inutile décrire AttachForm(FORM_CODE_FOR_SINGLE_TAXPAYER_FILING_JOINTLY_FOR_DEPRECIATION_ON_ARMPIT_HAIR). Vous nallez pas le faire t, vous « allez à AttachForm("B-46") parce que chaque développeur qui y a déjà travaillé ou y travaillera saura que » B-46 « est le code de formulaire pour un contribuable unique classer bla bla bla – les codes de formulaire font partie du domaine lui-même, ils ne changent jamais, donc ce ne sont pas vraiment des nombres magiques.

  Vous devez donc utiliser les constantes avec parcimonie dans la logique métier; fondamentalement, vous devez comprendre si ce « nombre magique » est en fait un nombre magique ou sil « sagit dun aspect bien connu du domaine. Si cest le domaine, alors vous ne le codez pas à moins quil ne soit » très bonne chance que cela change.

• Codes derreur et indicateurs détat

  Ce nest jamais acceptable de coder en dur, comme tout pauvre salaud qui a déjà été touché par le Previous action failed due to error code 46 peut vous le dire. Si votre langue le prend en charge, vous devez utiliser un type dénumération. Sinon, vous aurez généralement un fichier / module entier rempli de constantes spécifiant les valeurs valides pour un type derreur particulier.

  Ne me laissez jamais voir return 42 dans un gestionnaire derreurs, capiche? Aucune excuse.

Jai probablement omis plusieurs scénarios mais je pense que cela couvre la plupart dentre eux.

Donc, oui, cest parfois une pratique acceptable aux trucs de code dur. Ne soyez pas paresseux à ce sujet; cela devrait être une décision consciente plutôt que du vieux code bâclé.

Commentaires

• Merci pour la bonne ventilation! – la plupart des gens ‘ ne pensent pas à toutes les options que jajouterais  » Configuration de lenvironnement  » – Je pense que ceux-ci devraient être évités (pas codés en dur), car la plupart des données doivent être placées dans un fichier de configuration ou une base de données. Cela suit le principe de  » séparant les données et la logique  » qui est un pilier de MVC ou MVVM. string TestServerVar =  » foo « ; string ProdServerVal =  » bar « ;

Il y a plusieurs raisons dattribuer un identifiant à un nombre.

• Si le nombre peut changer, il doit avoir un identifiant. Il est beaucoup plus facile de trouver NUMBER_OF_PLANETS que de rechercher chaque instance de 9 et de déterminer si elle doit être remplacée par 8. (Notez que visible par lutilisateur les chaînes devront peut-être changer si le logiciel doit être utilisé dans une langue différente, et cest « une chose difficile à prévoir à lavance.)
• Si le nombre est difficile à taper de quelque manière que ce soit. Pour des constantes comme pi, il vaut mieux donner une définition de précision maximale que de la retaper à plusieurs endroits, peut-être de manière inexacte.
• Si le numéro apparaît à différents endroits. Vous ne devriez pas avoir à regarder deux utilisations de 45 dans des fonctions adjacentes et à vous demander si elles signifient la même chose.
• Si la signification nest pas immédiatement reconnaissable. Il est prudent de supposer que tout le monde sait ce que 3.14159265 … est. Il nest pas sûr de supposer que tout le monde reconnaîtra la constante gravitationnelle, voire pi / 2. (« Tout le monde » ici dépend de la nature du logiciel. On peut sattendre à ce que les programmeurs de systèmes connaissent la représentation octale des bits dautorisation Unix ou similaires. Dans les logiciels darchitecture navale / marine, vérifier le numéro Froude dune coque proposée et la vitesse à voir sil « s 1.1 ou supérieur pourrait être parfaitement explicite pour quiconque devrait y travailler.)
• Si le contexte nest pas reconnaissable . Tout le monde sait quil y a 60 minutes dans une heure, mais multiplier ou diviser par 60 peut ne pas être clair sil ny a pas dindication immédiate que la quantité est une valeur de temps ou une valeur de taux .

Cela nous donne des critères pour les littéraux codés en dur. Ils devraient être immuables, pas difficiles à taper, se produire dans un seul endroit ou contexte seulement, et avec une signification reconnaissable. Cela ne sert à rien en définissant 0 comme ARRAY_BEGINNING, par exemple, ou 1 comme ARRAY_INCREMENT.

En complément dautres réponses. Utilisez des constantes pour les chaînes lorsque cela est possible. Bien sûr, vous ne voulez pas avoir

const string server_var="server_var"; 

mais vous devriez avoir

const string MySelectQuery="select * from mytable;"; 

(en supposant que vous ayez en fait une requête où vous voulez obtenir tous les résultats dune table spécifique, toujours)

À part cela, utilisez des constantes pour tout nombre autre que 0 (généralement). Si vous avez besoin un masque de bits dautorisation de 255, ne pas utiliser

const int 8th_bit=255; //or some other obscure naming scheme that equates to 255. 

utiliser à la place

const int AllowGlobalRead=255; 

Bien sûr, avec les constantes, sachez quand utiliser les énumérateurs. Le cas ci-dessus conviendrait probablement bien dans un cas.

Commentaires

• typedef enum {state_0 = 0, state_1 = 1, state_2 = 2, .. .} … Ne riez pas ‘, je ‘ lai vu faire. Frappez cette personne autour de la tête avec un poisson mouillé!
• @ rapidement bien sûr que vous ‘ voudriez quelque chose de plus comme typedef enum {init_state=0, parse_state=1, evaluation_state=2, ... }
• THIS_NAMING_CONVENTION_IS_RECOMMENDED_FOR_CONSTANTS
• Pour les chaînes, vous ne voulez ‘ que des constantes. Vous souhaitez placer toutes les chaînes visibles par lutilisateur dans une sorte de fichier de ressources (les détails dépendront de votre plate-forme) afin de pouvoir passer facilement à une autre langue.
• Vous pouvez également conserver une logique métier chaînes (comme les requêtes SQL) dans un fichier de ressources avec une sorte de cryptage ou dobscurcissement. Cela empêchera les utilisateurs  » curieux  » de rétroconfectionner votre logique (ou schéma de base de données).

Cela dépend de ce que vous considérez comme un codage en dur. Si vous essayez déviter toutes les choses codées en dur, vous vous retrouvez dans le territoire du codage logiciel et créez un système que seul le créateur peut gérer (et cest le ultime hardcode)

Beaucoup de choses sont codées en dur dans nimporte quel cadre raisonnable et elles fonctionnent. cest à dire quil ny a aucune raison technique pour laquelle je ne devrais pas être capable de changer le point dentrée dune application C # (static void Main ), mais un codage en dur qui ne crée aucun problème pour aucun utilisateur (sauf la question SO occasionnelle)

La règle dor que jutilise est que tout ce qui peut et va changer, sans affecter létat de lensemble du système, devrait être confugurable.

Donc, à mon humble avis, il est « idiot de ne pas coder en dur des choses qui ne changent jamais (pi, constante gravitationnelle, une constante dans une formule mathématique – pensez au volume dune sphère).

De plus, il est « idiot de ne pas coder en dur des choses ou des processus qui auront un impact sur votre système qui nécessitera une programmation dans tous les cas, i .e. il est inutile de permettre à lutilisateur dajouter des champs dynamiques à un formulaire, si un champ ajouté nécessiterait que le développeur de maintenance entre et écrive un script qui fera fonctionner cette chose. De plus, il est stupide (et je l’ai vu à plusieurs reprises dans les environnements d’entreprise) de créer un outil de configuration, donc rien n’est codé en dur, mais seuls les développeurs du service informatique peuvent l’utiliser, et ce n’est qu’un peu plus facile pour lutiliser que pour le faire dans Visual Studio.

Donc, en fin de compte, si une chose doit être codée en dur est une fonction de deux variables:

• la valeur changera
• comment une modification de la valeur affectera le système

Est-ce une bonne idée de coder en dur les valeurs dans nos applications?

Je code en dur les valeurs uniquement si les valeurs sont spécifiés dans la spécification (sur une version finale de la spécification), par exemple La réponse HTTP OK sera toujours 200 (sauf si elle change dans le RFC), donc, vous verrez (dans certains de mes codes) des constantes comme:

public static final int HTTP_OK = 200; 

Sinon, je stocke les constantes dans le fichier de propriétés.

La raison pour laquelle jai spécifié des spécifications, est que la modification des constantes dans les spécifications nécessite une gestion du changement, dans laquelle, le les parties prenantes examineront le changement et approuveront / désapprouveront. Cela ne se produit jamais du jour au lendemain et prend des mois / années pour une approbation. Noubliez pas que de nombreux développeurs utilisent des spécifications (par exemple HTTP), donc changer cela signifie casser des millions de systèmes.

• si la valeur peut changer, et peut en effet changer, alors codez-la autant que possible tant que leffort impliqué ne dépasse pas le rendement attendu
• certaines valeurs ne peuvent être codé en douceur; suivez les directives de Jonathan dans ces (rares) cas

Jai remarqué que chaque fois que vous pouvez extraire des données de votre code, cela améliore ce qui reste. Vous commencez à remarquer de nouvelles refactorisations et à améliorer des sections entières de votre code.

Cest juste une bonne idée de travailler à lextraction de constantes, ne le considérez pas comme une règle stupide, pensez-y comme une opportunité de coder mieux.

Le plus grand avantage serait la façon dont vous pourriez trouver des constantes similaires étant la seule différence dans les groupes de code – les résumer dans des tableaux ma aidé à réduire certains fichiers de 90% de leur taille et à corriger assez quelques copies & collez les bogues en attendant.

Je « nai pas encore vu un seul avantage à ne pas extraire de données.

Jai récemment codé une fonction MySQL pour calculer correctement la distance entre deux paires lat / longue. Vous ne pouvez pas « t juste faire pythagorus; les lignes de longitude se rapprochent au fur et à mesure que la latitude augmente vers les pôles, donc il y a une sorte de déclencheur poilu impliqué.

Jai fini par le faire, même si le fait est que les lignes lat / lng sont beaucoup plus rapprochées, disons, sur la lune. Et ma fonction sous-estimerait considérablement les distances entre les points de Jupiter. Je me suis dit que les chances que le site Web que je construis ait accès à un emplacement extraterrestre sont plutôt minces.

Commentaires

• Oui, probablement, mais quoi à propos de google.com/moon

Et bien cela dépend si votre langage est compilé. Sil nest pas compilé, ce nest pas un gros problème, il vous suffit déditer le code source, même si ce sera un peu délicat pour un non programmeur.

Si vous programmez avec un langage compilé, ce nest clairement pas une bonne idée, car si les variables changent, vous devez recompiler, ce qui est une grosse perte de temps si vous voulez ajuster cette variable.

Vous navez pas besoin de créer un curseur ou une interface pour modifier dynamiquement sa variable, mais le moins que vous puissiez faire est un fichier texte.

Par exemple, avec mon projet ogre, jutilise toujours la classe ConfigFile pour charger une variable que jai écrite dans un fichier de configuration.

Deux occasions où les constantes sont (à mon avis du moins) OK:

1. Constantes qui ne concernent rien dautre; vous pouvez changer ces constantes quand vous le souhaitez sans avoir à changer quoi que ce soit dautre. Exemple: la largeur par défaut dune colonne de grille.

2. Constantes absolument immuables, précises et évidentes, comme « nombre de jours par semaine ». days = weeks * 7 Le remplacement de 7 par une constante DAYS_PER_WEEK ne fournit pratiquement aucune valeur.

Je suis entièrement daccord avec Jonathan mais comme toutes les règles il y a des exceptions …

« Numéro magique dans la spécification: Numéro magique dans le code »

Décrit essentiellement que tous les nombres magiques qui restent dans la spécification après des tentatives raisonnables pour obtenir un contexte descriptif pour eux devraient être reflétés comme tels dans le code. Si des nombres magiques restent dans le code, tous les efforts doivent être faits pour les isoler et les rendre clairement liés à leur point dorigine.

Jai effectué quelques contrats dinterfaçage où il est nécessaire de remplir les messages avec des valeurs mappées à partir de la base de données. Dans la plupart des cas, le mappage est assez simple et correspondrait aux lignes directrices générales de Jonathan, mais jai rencontré des cas où la structure du message cible était tout simplement horrible.Plus de 80% des valeurs qui devaient être transmises dans la structure étaient des constantes imposées par la spécification du système distant. ceci, associé au fait que la structure du message était gargantuesque, a fait que BEAUCOUP de ces constantes devaient être peuplées. Dans la plupart des cas, ils nont pas fourni de sens ou de raison, ils ont simplement dit « mettre M ici » ou « mettre 4.10.53.10100.889450.4452 ici ». Je nai pas tenté non plus de mettre un commentaire à côté de tous, cela aurait rendu le code résultant illisible. Je me suis cependant assuré que les sections de code où ces valeurs magiques apparaissent sont correctement isolées et que leurs conteneurs (classes, packages) sont nommés de manière appropriée pour pointer directement vers la spécification qui les applique.

Cela dit, quand vous pensez à il … il sagit à peu près de le rendre évident …

Si vous « codez en dur la valeur de la constante gravitationnelle de la terre », personne ne sen souciera. Si vous codez en dur ladresse IP de votre serveur proxy, vous avez des problèmes.

Commentaires

• Vous pourriez avoir besoin de plus de précision pour Earth ‘ s constante gravitationnelle, donc la coder en dur plusieurs fois pourrait entraîner des problèmes.
• Peter Noone? De Herman ‘ ermites ?
• Laccélération gravitationnelle sur la Terre est à peu près 9,81 m / s ^ 2 pour la plupart des latitudes et altitudes (bien sûr, si vous ‘ à la recherche de pétrole sous terre, ou tirant des ICBM au-dessus du pôle Nord, sachant que la variation de gravité est très importante pour beaucoup plus de décimales), laccélération gravitationnelle sur dautres planètes étant un nombre différent, mais pour autant que je sache, la constante gravitationnelle est constante autour de lunivers. Il y a beaucoup de physique qui devrait changer si g était variable.

Surtout non, mais je pense que cela vaut la peine de noter que vous wi Jai le plus de problèmes lorsque vous commencez à dupliquer la valeur codée en dur. Si vous ne le dupliquez pas (par exemple, ne lutilisez quune seule fois dans limplémentation dune classe), ne pas utiliser de constante peut être correct.