Les noms de variables affectent-ils les performances des sites Web?


10

Les noms de variables affectent-ils les performances du site Web? Je sais que ce sera un nombre très faible, mais peut-on encore donner les raisons de ne pas choisir un nom de variable long en termes de performances?


2
Veuillez clarifier votre question - où est cette variable et dans quelle langue est-elle écrite?
Luke Graham

16
Vous ne devriez jamais, JAMAIS choisir des noms de variables courts et illogiques si votre raisonnement est une performance (discutable). Le code source est là pour que d'autres personnes le lisent, pas pour satisfaire les ordinateurs et leurs gains de performances microscopiques.
Michael JV

j'utilise PHP ..
Avinash

2
... Et vous possédez xpertdeveloper.com?
Jim G.

3
Salut Avinash pouvez-vous expliquer dans votre question votre justification pour penser que cela pourrait être le cas?

Réponses:


17

quelqu'un peut-il fournir les raisons de ne pas choisir un nom de variable long en termes de performances?

Michael a couvert la réponse (c'est-à-dire non) mais les noms de variables affectent les performances du programmeur . Si vous amenez un nouveau développeur ou quelqu'un qui ne connaît pas le code, alors avoir des noms de variables longs et / ou déroutants peut être distrayant et ralentir le processus de compréhension.

En général, vous souhaitez utiliser des noms de variables descriptifs courts, car ils sont plus faciles à lire. Imaginez si vous devez ignorer votre code pendant 10 ans, puis tout comprendre à nouveau. Préférez-vous lire "getInput" ou "getInputFromUserWhoInputsStringOrElseInformReaderOfError"? (exagération bien sûr: P)

Il y a des moments, cependant, où avoir un nom légèrement plus long peut être bénéfique. Par exemple, getBirthdayInput () serait beaucoup plus descriptif que getInput (). Vous voulez simplifier jusqu'à un certain point, mais une simplification excessive peut également être problématique.


6
pour lire des noms longs, c'est mieux, si vous trouvez "getInputFromUserWhoInputsStringOrElseInformReaderOfError", vous n'avez pas besoin de lire la documentation de cette fonction, si vous trouvez "getInput" dont vous avez besoin. Et après 10 ans, la documentation sera erronée, incomplète ou manquante. getInputFromUserWhoInputsStringOrElseInformReaderOfError est certainement trop long, mais comprendre ce que c'est long est mieux (et je me fiche que les femmes disent que la taille n'a pas d'importance).
Dainius

Je ne suis pas d'accord dans ce cas. Je pense que juste en lisant du code, il serait assez facile de comprendre ce que fait getInput (), surtout s'il imprime "entrée invalide" ou quelque chose juste après. Il y a certainement des moments où un nom plus long peut être meilleur - je vais le modifier!
BlackJack

bien sûr, cela dépend du contexte, mais d'après mon expérience, un nom plus long est meilleur (mais pas tant que getInputFromUserWhoInputsStringOrElseInformReaderOfError). Et le contexte est très important car file.read () est plus rapide que file.readAllFileAsByteArray (). Mais comme je l'ai dit, le nom plus long à mon humble avis fournit plus d'informations.
Dainius

1
Si la documentation est incorrecte, incomplète ou manquante, la base de code est de toute façon condamnée.
Christopher Mahan

2
Cela répond à une question qui n'a pas été posée.

16

Non, ce ne sera pas le cas. De manière générale, lors de la compilation du code, les noms des variables sont remplacés par l'adresse mémoire à laquelle ils se réfèrent. Les ordinateurs ne savent rien des noms de variables; ils veulent seulement savoir où les valeurs sont stockées.

Les variables sont des symboles, rien de plus. Ils remplacent les valeurs hexadécimales par des noms afin que les programmeurs aient plus de facilité à comprendre ce qu'ils font. Il n'y aura donc pas d'amélioration des performances en choisissant des noms de variables plus courts.

Cela dit, vous pouvez obtenir de minuscules améliorations (et je parle microscopiques) dans les temps de compilation et la première interprétation JIT, mais c'est uniquement parce que l'analyseur prend quelques cycles de processeur de moins pour lire le nom de la variable. Il s'agit d'un coût unique et statistiquement insignifiant lorsque l'on se préoccupe des performances.


11
Bien que votre réponse soit correcte pour la programmation d'applications, le PO fait référence à des sites Web, et il est donc possible qu'il utilise un langage interprété. Dans un tel cas, le code devrait être lu à partir du fichier, puis interprété. Dans ce cas, un nom de variable plus long prendra plus de temps à charger et à analyser. Cependant, le gain de performances sera insignifiant et massivement compensé par les tracas supplémentaires pour le programmeur de lire et de comprendre le code.
Gavin Coates

1
@Gavin Il est également valable pour les langues interprétées - "JIT first interpretation". La plupart des langages interprétés se compilent désormais au fur et à mesure de leur exécution plutôt que de l'exécution ligne par ligne, AFAIK.
Michael K

1
Michael - pour compiler, le fichier doit d'abord être lu en mémoire. Ce processus prendra plus de temps en fonction de la longueur du fichier. Noms de variables plus longs = fichiers plus longs.
Gavin Coates

La question est étiquetée comme PHP. PHP n'a pas encore JIT - ce sera une nouvelle fonctionnalité de la version 8.0 prévue pour la fin de cette année. Il compile en octet de code avant exécution, et le bytecode est généralement mis en cache sur les serveurs Web pour être utilisé dans plusieurs requêtes.
bdsl

8

À moins que vous n'utilisiez un cache de code op (également connu sous le nom d '"accélérateurs PHP"), il y a en effet un impact. Mais cet impact est si faible qu'il peut être négligé. Si vous utilisez le cache de code op, il n'y a aucun impact.


1
et si vous vous souciez tellement des performances que vous envisagez de raccourcir les noms de variables pour gagner quelques cycles, ne pas utiliser le cache de code op serait criminel ... et le passage à un langage compilé comme C serait recommandé.
SF.

Mais évidemment, cet impact est cumulatif, donc plus l'application est importante, plus l'impact est important, non?
n00dles

Le Zend Opcache est livré avec PHP depuis plusieurs années maintenant, donc tout le monde devrait l'utiliser. Je pense qu'il est généralement activé par défaut.
bdsl

3

Bien que Michael soit correct pour la programmation d'applications, votre question fait référence au développement Web avec PHP, qui est un langage interprété. Dans un tel cas, le code devrait être lu à partir du fichier, puis interprété. Dans ce cas, un nom de variable plus long prendra plus de temps à charger et à analyser.

Cependant, les performances ne seront pas significatives et seront probablement de l'ordre de quelques fractions de millisecondes pour un script entier. Vous pouvez toujours l'essayer avec un exemple de script et utiliser une méthode de synchronisation telle que celle détaillée sur http://www.developerfusion.com/code/2058/determine-execution-time-in-php/ mais cela ne sera probablement pas commencer le chronométrage jusqu'à ce que le fichier ait été lu. De plus, le temps d'exécution entre les tentatives variera beaucoup plus que la différence entre les longueurs de noms variables, vous devrez donc effectuer un nombre significatif de tentatives et prendre la moyenne de chacune avant de pouvoir obtenir une moyenne à distance significative.

Comme le souligne BlackJack, les noms plus longs peuvent être beaucoup plus difficiles à comprendre et prendre beaucoup d'efforts supplémentaires pour taper (et sont beaucoup plus enclins aux fautes de frappe). Bien qu'il puisse y avoir un petit gain de performances, cela ne justifie pas les tracas supplémentaires créés pour le programmeur. Par conséquent, les noms de variables courts, concis et faciles à comprendre sont préférés.

Donc, en bref, ne vous inquiétez pas du nom de longueur variable, mais concentrez-vous plutôt sur l'écriture d'un code propre et significatif.


1

Peut - être :

Le code du serveur est généralement compilé et la longueur du nom de variable ne l'affectera pas pour les raisons mentionnées. Cependant, si le nom de la variable est utilisé pour construire le balisage, diverses opérations de chaîne. Étant donné que la réponse HTTP (contenant le balisage / json retourné / données retournées) est plus grande, cela prendra un peu plus de temps, bien que la différence soit négligeable. Si JavaScript n'est pas minifié, ce sera un fichier plus volumineux, ce qui prendra plus de temps pour se rendre chez le client.

Outre la réduction de la taille des fichiers JavaScript, tout effort d'optimisation d'une application Web / d'un site Web sera mieux dépensé sur d'autres aspects.


1

Oui, ce sera le cas, mais pas dans le sens auquel vous pensez.

Avec de mauvais noms de variables, les développeurs seront facilement confondus avec le code source. Ce sera difficile à lire et difficile à comprendre.

Au final, le code source sera difficile à maintenir et il sera presque impossible de le faire évoluer. Cela entraînera inévitablement des coûts de maintenance plus élevés, des coûts de développement plus élevés, plus de bogues et de moins bonnes performances .

Le nom de la variable n'aura absolument aucune influence au moment de l'exécution et totalement négligeable au moment de la compilation. Mais les mauvais noms entraîneront inévitablement de mauvaises performances car personne ne comprend le code et il se retrouve dans une pile de piratage les uns sur les autres, ce qui aggrave à chaque fois les choses.

Lisez-les pour connaître le bon nom de variable: http://tottinge.blogsome.com/meaningfulnames

Notez que si vous ressentez le besoin d'un nom de variable très long, cela signifie que votre code est mal architecturé. Un nom de variable est toujours exprimé dans un contexte: espace de noms, nom de classe, nom de fichier, dossier, nom de fonction, etc. Ainsi, si le nom doit être long pour être explicite, cela signifie que la chose que vous essayez de nommer DOESN ' T APPARTIENT ICI . Dans ce cas, pensez à mettre ce code à l'endroit approprié, ou créez cet endroit s'il n'existe pas encore.


0

La réponse est évidemment oui, en ce qui concerne le php.

Les réponses qui disent que cela ne fera pas de différence ne sont pas nécessairement correctes. Par exemple, j'ai un petit script php, juste quelques lignes, mais il doit boucler environ 1 950 000 fois avant de terminer son travail, donc même si une seule exécution du script peut ne pas être remarquée, ces fractions de seconde s'additionnent considérablement lorsque boucle plusieurs fois.


1
Mais tu as tort. Tout interprète php décent analysera le code une seule fois. Les gars qui écrivent des interprètes php ne sont pas stupides.
gnasher729

@ gnasher729 Vous faites des suppositions sur le fonctionnement de l'interpréteur ou de l'ensemble du serveur et vous ne devriez jamais faire cela. Même s'il n'analysera qu'une seule fois par exécution, il peut ré-analyser à chaque exécution et ne pas mettre en cache une représentation analysée (d'autres systèmes le feront mais vous ne pouvez pas le savoir à l'avance). Et généralement, plus un script est octet, plus il faudra de temps pour analyser. Donc, Diorthotis n'a pas tort en général, il / elle ne peut avoir tort qu'en ce qui concerne un système spécifique.
Mecki

0

Vous pouvez utiliser des noms courts qui rendent votre code moins lisible. Vous économiserez une microseconde ou deux. Mais parce que le code est moins lisible, il est plus difficile d'améliorer le code et de le rendre plus rapide. Ainsi, votre code incontrôlable et inamovible avec des noms courts finira par fonctionner beaucoup plus lentement à la fin.

Donc, pour répondre à votre question ("cela affecte-t-il les performances"): Oui, mais pas comme vous le souhaitez.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.