Si mon équipe a peu de compétences, devrais-je baisser les compétences de mon code? [fermé]

156

Par exemple, il existe un fragment de code commun dans JS pour obtenir une valeur par défaut:

function f(x) {
    x = x || 'default_value';
}

Ce type d'extrait n'est pas facile à comprendre pour tous les membres de mon équipe, leur niveau de JS étant bas.

Devrais-je pas utiliser cette astuce alors? Cela rend le code moins lisible par les pairs, mais plus lisible que ce qui suit selon n'importe quel développeur JS:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

Bien sûr, si j'utilise cette astuce et qu'un collègue la voit, ils peuvent alors apprendre quelque chose. Mais le cas est souvent qu’ils voient cela comme "essayer d’être intelligent".

Alors, devrais-je baisser le niveau de mon code si mes coéquipiers ont un niveau plus bas que moi?

Florian Margaine
la source
42
Je pense que cela se résume à la question "Devriez-vous écrire du code idiomatique et forcer les gens à ce niveau? Ou écrire un code non-idiomatique qui énonce tout explicitement?"
53
Ne baissez pas le niveau de compétence de votre code! J'ai beaucoup appris en lisant le code de programmeurs plus avancés. Créez une culture dans laquelle, si vos pairs ne comprennent pas quelque chose, ils sont encouragés à demander (et à apprendre). Assurez-vous que vous êtes cohérent.
Kosta Kontos
6
Avez-vous des critiques de code? Ce serait un excellent endroit pour eux de poser des questions sur un code comme celui-là.
thegrinner
3
Une partie de la compétence de codage est la clarté, en prenant en compte votre "public". Cet idiome semble valoir la peine d'être enseigné, mais il y aura certainement des cas où il sera plus logique d'utiliser un style de codage plus transparent.
LarsH
3
Est-ce juste une question de savoir qui pense que le deuxième exemple est de meilleure qualité que le premier exemple, puisque ce qui est fait est clair? On dirait que le deuxième exemple est plus lisible que la version abrégée qui est le premier exemple. N'y a-t-il pas des outils qui prendront automatiquement le code créé par l'homme et l'optimiseront pour Javascript? D'après mon expérience en Javascript, le code réellement exécuté ne doit pas nécessairement être aussi efficace que possible.
Ramhound

Réponses:

135

Ok, voici mon point de vue sur ce sujet vaste et compliqué.


Avantages pour garder votre style de codage:

  • Des éléments comme x = x || 10idiomatiques dans le développement JavaScript et offrent une forme de cohérence entre votre code et le code des ressources externes que vous utilisez.
  • Un niveau de code plus élevé est souvent plus expressif, vous savez ce que vous obtenez et il est plus facile de lire avec des professionnels hautement qualifiés.
  • Vous apprécierez plus votre travail. Personnellement, j’apprécie créer de jolis codes. Je pense que cela me procure beaucoup de satisfaction dans mon travail.
  • Généralement, cela crée un style plus lisible. S'en tenir aux idiomes de la langue peut être très précieux - ce sont souvent des idiomes pour une raison.

Inconvénients pour garder votre style de codage:

  • Les programmeurs de niveau inférieur auront plus de difficulté à suivre. Ce sont souvent les personnes chargées de la maintenance de votre code et celles qui devront lire ce que vous écrivez.
  • Les mainteneurs de code, souvent le code JavaScript provient d'autres langues. Vos programmeurs sont peut-être compétents en Java ou en C # mais ne comprennent pas comment et quand JavaScript diffère exactement. Ces points sont souvent idiomatiques - une expression de fonction immédiatement appelée (IIFE) est un exemple d'une telle construction.

Mon opinion personnelle

Vous ne devriez pas baisser les compétences de votre code. Vous devriez aspirer à écrire un code expressif, clair et concis. Si vous avez des doutes sur le niveau de votre équipe, informez- les . Les gens sont plus que disposés à apprendre que vous ne le pensez et à adapter de nouveaux concepts s’ils sont convaincus qu’ils sont meilleurs.

S'ils pensent que vous êtes simplement "intelligent", essayez de défendre votre point de vue. Soyez prêt à admettre que vous vous trompez parfois, et quoi qu'il en soit, essayez de maintenir la cohérence des styles dans votre environnement de travail. Cela aidera à éviter l'hostilité.

Le plus important est de rester cohérent.

Le code d'une équipe doit être écrit comme si une personne l'avait codé. Vous devez absolument vous mettre d' accord sur les directives de codage. Vous devez respecter ces directives. Si les directives de codage spécifient que la lecture des paramètres facultatifs doit être effectuée de manière "moins intelligente", c'est le chemin à suivre.

Benjamin Gruenbaum
la source
1
Je sais que l'apprentissage est une chose constante, mais est-ce vraiment le travail de ce développeur de former ses collègues? La direction doit vraiment trouver la formation la plus appropriée pour eux.
CorsiKa
8
@corsiKa Il est peu probable que ces développeurs apprennent toutes les particularités d'une langue par le biais d'une "formation payée" (c'est-à-dire le type de formation que la direction enverrait au personnel). Je considère que le lieu de travail est malade lorsque les collègues n'apprennent pas les uns des autres. Ce n'est pas comme si le PO devait leur donner une formation en classe. Les gens peuvent simplement poser des questions lorsqu'ils sont bloqués et, comme mentionné dans un commentaire ci-dessus, la révision de code peut être utile pour partager ce type de connaissances.
MetalMikester
2
Ses collègues devraient apprendre seuls, à partir des exemples donnés par le PO (et d’autres). Sinon, ils ne pourront jamais dépasser leurs connaissances actuelles. Le PO ne devrait pas prendre des heures chaque jour pour les former personnellement, mais des critiques de code et une session occasionnelle avec un sac brun peuvent aider tout le monde (enfin, tous ceux qui veulent apprendre, c'est-à-dire).
Alroc
1
@corsiKa a convenu qu'un examen du code d'un développeur senior ne constitue pas en soi une formation adéquate, bien qu'il puisse être un bon moyen d'identifier les éléments que le développeur junior devrait consulter plus tard.
Dan Lyons
2
@yms assez juste, c'est un point de vue valable. Je n'ai jamais prétendu que la lisibilité était la règle. J'ai une forte objection à utiliser plusieurs langues comme si elles étaient la même langue. Une objection "gagnée" en des centaines d'heures de débogage. Bien que je sois tout à fait d’ accord pour dire que la lisibilité est la règle, je pense que vous ne pouvez pas traiter les codes dans plusieurs langues de la même manière. De plus, je pense que la plupart de la "mauvaise réputation" de JavaScript est due à cela. Les gens s'attendent à ce qu'il se comporte comme une autre langue, mais ce n'est pas le cas. Je conviens que la lisibilité est essentielle à la mission. Un meilleur code est toujours plus lisible :)
Benjamin Gruenbaum
47

Bien commenter

Devez-vous baisser les compétences de votre code? Pas nécessairement, mais vous devriez certainement augmenter la compétence de vos commentaires . Veillez à inclure de bons commentaires dans votre code, en particulier autour des sections que vous pensez être plus compliquées. N'utilisez pas autant de commentaires que le code devient difficile à suivre, mais assurez-vous de bien préciser le but de chaque section.

La réalité est qu’être un peu plus bavard avec des commentaires peut être utile avec des membres d’équipe moins expérimentés, mais que ceux qui ont les compétences les plus faibles avec les ignorent, surtout s’il y en a trop, n’en faites pas trop.

Une question de style?

L'exemple que vous avez fourni est quelque peu basique, mais aussi plutôt stylistique. Un commentaire sur chaque variable par défaut serait assez fastidieux à maintenir et à lire. Au lieu de cela, des raccourcis stylistiques ou répétés ou des modèles de code devraient probablement être établis en tant que norme. Si vous pensez que quelque chose comme cette forme de défaut de paramètre doit être compris de tous et utilisé à chaque fois, écrivez ces idées et transmettez-les à votre responsable d'équipe. Il est possible que tout ce que vous aurez à enseigner à vos coéquipiers soit une simple réunion au cours de laquelle vous discuterez des normes que vous avez proposées.

Comme une autre réponse déjà énoncée, maintenez-le cohérent .

Apprendre à un homme à pêcher ...

Enseigner à vos coéquipiers est probablement le meilleur moyen d'aider toutes les personnes impliquées. Dites clairement que si quelqu'un a une question sur un morceau de code avec votre nom dans le journal de validation ou les horodatages, il doit se sentir libre de vous en parler. Si votre équipe dispose de révisions de code, il s'agit d'une excellente occasion d'expliquer à vos coéquipiers tout code éventuellement commenté pouvant prêter à confusion . Si votre équipe n'a pas de révision de code, pourquoi pas? Allez-y!

Vous devez cependant faire attention. Vous n'êtes peut-être pas toujours là pour enseigner aux gens et vous pourriez même oublier ce que vous essayiez à l'origine de faire dans une section de code donnée.

Astuces "Clever"

Il est certes important de garder à l'esprit les capacités de vos coéquipiers, mais écrire du code maintenable signifie souvent ne pas utiliser de raccourcis obscurs pour résoudre des problèmes qui pourraient donner lieu à des solutions plus courantes. Ceci est important même lorsque vos coéquipiers sont intelligents. Vous ne voulez pas faire en sorte que le code prenne trop de temps à saisir ou à avoir des effets secondaires subtils mais importants qui pourraient être omis. En général, il est préférable d'éviter les astuces "intelligentes" lorsqu'il existe des alternatives appropriées. Vous ne savez jamais qui pourrait avoir à gérer le code sur toute la ligne. Souvent, les anciennes versions de nous-mêmes ne se souviendront pas des détails ou des raisons de ces astuces.

Si vous constatez que vous devez mettre en œuvre une astuce intelligente, suivez au moins les conseils suivants ...

BAISER

En cas de doute, restez simple . Que le code soit simple ou non ne correspond pas nécessairement aux compétences du programmeur, comme vous pourriez le penser. En fait, certaines des solutions les plus brillantes à un problème sont les plus simples, et certaines des solutions les plus compliquées aboutissent sur TheDailyWTF . Garder votre code simple et concis peut faciliter la prise de certaines des décisions les plus intelligentes, voire contre-intuitives.

Corion
la source
10
Le problème est que les fonctionnalités linguistiques sont considérées comme des "astuces intelligentes", même si je pense qu'elles ne le sont manifestement pas. Avez-vous déjà vu une fermeture? Vous avez déjà vu un IIFE? Vous avez déjà vu une référence de fonction passée en tant que rappel? Ce sont des fonctionnalités linguistiques connues de tous les développeurs JS expérimentés . Pourtant, ce sont des "astuces intelligentes" pour les développeurs JS moins expérimentés.
Florian Margaine
1
@ FlorianMargaine me semble que vous devez travailler à changer la terminologie, c'est-à-dire: ce ne sont pas des "astuces intelligentes", ce sont des fonctionnalités plus avancées du langage ... 1 implique que votre code n'est pas bien compris / une mauvaise chose, 2 implique une opportunité d'apprendre et d'améliorer 'mes' compétences en codage (comment amener les autres à changer de terminologie? Commentez, encouragez les questions, partagez des articles de code expliquant comment ces fonctionnalités sont utiles, etc.)
Andrew Bickerton le
3
Si cela vous aide à soulager vos maux de tête, une partie de la frustration peut être due au fait que Javascript, en tant que langage, n'a pas de sens. Cela a du sens pour les États-Unis, les personnes postant ici, parce que cela fait longtemps. Mais peu importe la façon dont nous avons fait en sorte que le langage fonctionne "bien", cela n'a aucun sens pour les neutres. D'un autre côté; tristement, vous pouvez démontrer la valeur de l’ embauche de développeurs expérimentés , ou de préférence de développeurs «n’importe quel langage» avec une grande volonté d’apprendre de nouveaux paradigmes.
Katana314
1
@ FlorianMargaine Je travaille aussi principalement en JavaScript, je connais la douleur que vous ressentez. J'ai abordé cela en essayant d'éduquer les coéquipiers. Les vidéos JavaScript de Crockford ( 1 , 2 ) aident. Je ne pense pas que les choses que vous avez énumérées relèvent des astuces "intelligentes" - vos coéquipiers devraient les apprendre - mais certaines des choses que vous faites avec ces fonctionnalités de langage pourraient être du mauvais genre "intelligentes". Comment convaincre votre entreprise d'engager des développeurs expérimentés est probablement une autre question ...
Corion
2
Les commentaires ne sont pas toujours bons. J'ai lu "Clean Code" il y a quelque temps et ses remarques sur les commentaires sont excellentes. Si vous ressentez le besoin d'écrire des commentaires pour expliquer votre code, il y a de fortes chances que le code soit mal écrit. Si le code était plus expressif, un commentaire est superflu. Chaque fois que vous êtes sur le point d'écrire un commentaire, arrêtez-vous un instant pour déterminer si la refactorisation pourrait être une meilleure option. Si le code est expressif, expliquer son but devient inutile. En outre, les commentaires peuvent devenir trompeurs ou simplement erronés si le code est modifié mais que les commentaires ne sont pas mis à jour pour correspondre.
Pappa
34

Il semble y avoir une grande aversion pour la création d’une fonction dans JS. Cette aversion incite les gens à faire preuve d'intelligence et à utiliser des astuces ridicules simplement pour garder les éléments dans une ligne, comme cela aurait été le cas pour un appel de fonction. Bien entendu, le nom de la fonction dans un appel sert également de documentation supplémentaire. Nous ne pouvons pas associer un commentaire à une expression délicate, car cela éviterait de le faire et nous l'appelons simplement "idiome js" et tout à coup, cela se comprend.

Javascript est extrêmement accessible, la plupart des gens ne mangent pas les spécifications du petit-déjeuner comme nous le faisons. Ainsi, ils ne comprendront jamais quelles sont les hypothèses cachées et les cas extrêmes d’un idiome.

x = x || 'default_value';

Le joe moyen soit ne comprend pas cela ou a mémorisé que c’est l’idiome de la valeur par défaut. Les deux sont nuisibles, en fait le dernier l'est encore plus. Il ne comprendra pas les hypothèses et les cas extrêmes ici. Il ne se souciera pas de lire le cahier des charges et de le comprendre jamais.

Quand je regarde ce code je vois « si elle est nullou undefined, réglez ensuite à cette valeur par défaut. Bien qu'il traitera également implicitement +0, -0, NaN, falseet ""ne pas les valeurs appropriées. Je dois rappeler que 3 mois à partir de maintenant , quand que les besoins changer. Je vais probablement l’oublier. "

L’hypothèse implicite est extrêmement susceptible de provoquer un bogue dans l’avenir. Lorsque votre base de code regorge d’astuces de ce type, il n’ya aucune chance que vous les gardiez toutes dans votre tête lorsque vous songez à ce qu’une modification affectera. Et ceci est pour le "JS pro", le joe moyen aurait écrit le bogue même si les exigences étaient d’accepter une valeur falsy pour commencer.

Votre nouveau fragment de code a une syntaxe plus familière, mais le problème ci-dessus persiste.

Vous pouvez aller avec:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

Maintenant, vous pouvez avoir une logique très complexe pour gérer les cas extrêmes et le code client est toujours aussi beau et lisible.


Maintenant, comment faites-vous la différence entre des fonctionnalités de langage avancées telles que le passage d’une fonction en argument ou un truc astucieux comme || "default"?

Les astuces intelligentes fonctionnent toujours avec des hypothèses cachées qui pourraient être ignorées lors de la création initiale du code. Je n'aurai jamais à modifier un IIFE en autre chose car une exigence a changé, elle sera toujours là. Peut-être qu'en 2020, je pourrai utiliser des modules réels, mais oui.

| 0ou la version culte de cargaison ~~numutilisée pour les revêtements de sol suppose des bornes d’entiers positives signées et de 32 bits.

|| "default" suppose que toutes les valeurs de falsy sont les mêmes que de ne pas transmettre un argument du tout.

Etc.

Esailija
la source
4
Vous vous concentrez sur un exemple. Qu'en est-il de l'utilisation d'éléments tels que les IIFE, les fermetures, les références de fonctions? C'est le point principal de ma question.
Florian Margaine
1
@ FlorianMargaine Vous ne pensez pas que j'ai abordé cela assez bien dans la deuxième partie?
Esailija
3
Eh bien, cela ne dit rien sur la façon de gérer la situation où j'utilise simplement "la fonctionnalité de langage avancé", que ses coéquipiers comprennent mal comme un "truc intelligent".
Florian Margaine
J'aime cette réponse +1, je pense qu’il manque une grande partie de la question, mais elle parle en détail d’autres parties et de scénarios à ce sujet et explique les problèmes rencontrés par les autres développeurs d’équipe qui ramassent de tels concepts par eux-mêmes code.
Benjamin Gruenbaum
@ FlorianMargaine vous voulez dire comment gérer réellement une situation sur votre lieu de travail où vous utilisez IIFE et quelqu'un pense que c'est une astuce? Comme je l'ai expliqué, puisqu'il n'y a pas d'hypothèses cachées, une mémorisation telle que "les variables ne seront pas globales" fonctionnera parfaitement pour la moyenne.
Esailija
23

Vous ne devriez pas réduire vos compétences en programmation, mais vous devrez peut-être ajuster votre écriture de code. Le but, avant tout, est de rendre votre code clair pour les personnes qui doivent le lire et le maintenir.

Malheureusement, il est difficile de juger si un style particulier est "intelligent" ou juste comme une utilisation avancée. Le code de la question en est un bon exemple: votre solution n'est pas nécessairement meilleure que l'autre. Certains diront que c'est le cas, d'autres ne seront pas d'accord. Étant donné que les deux solutions offrent effectivement des performances d'exécution égales (lisez: l'utilisateur ne saura jamais la différence), choisissez le style avec lequel l'équipe dans son ensemble est le plus à l'aise.

Dans certains cas, vous devez leur apprendre à mieux coder, mais à d'autres moments, vous devez faire des compromis dans un souci de clarté.

Bryan Oakley
la source
+1 Ni l'un ni l'autre des exemples donnés par le PO ne sont empiriquement meilleurs que les autres, ils sont simplement différents.
Ross Patterson
très bonne réponse @ Bryan-Oakley. À la vôtre
Andy K
7

Cela a peut-être déjà été dit dans une autre réponse, mais je voudrais répondre à cette question par mes propres ordres.

Directive générale

Lorsque vous travaillez en équipe, vous n'êtes pas le public cible d'un morceau de code. Votre public est constitué des développeurs de votre équipe. N'écrivez pas de code qu'ils ne peuvent pas comprendre sans bonne raison.

  1. À moins d'un inconvénient spécifique, tout le code doit être écrit en suivant un modèle ou une directive spécifique qui facilitera la maintenance par les développeurs qui le maintiendront. (Mise en garde: suivre de mauvaises habitudes simplement parce qu'elles sont actuellement dans la base de code est une pratique terrible.)
  2. Si vous pouvez trouver une bonne raison d'utiliser un idiome spécifique à une langue qui ne soit pas facilement lisible par le public cible, ajoutez un commentaire. Si vous estimez que vous devez ajouter un commentaire à chaque ligne, vous souhaiterez peut-être réécrire votre code pour qu'il soit plus lisible par votre public. Je ne trouve pas utile d'être idiomatique pour être idiomatique.

Exemple spécifique

Nous avons un grand nombre de scripts Perl dans notre base de code. Nous n'utilisons généralement perl que pour des opérations très simples et la grande majorité du code est écrite par des développeurs java. Son style est donc très semblable à celui de java. Nous avons un ensemble de scripts Perl et un cadre qui a été écrit par un «gourou de Perl» qui a depuis quitté notre entreprise. Ce code contient bon nombre des idiomes les plus obscurs de Perl et aucun de nos développeurs, y compris moi-même, ne peut lire ce code Perl sans effort. Nous le maudissons souvent pour cela. :)

utilisateur606723
la source
5

Si vous écrivez un bon code mais que vous pensez que vos collègues actuels ou futurs peuvent avoir des difficultés à le suivre, vous devez ajouter un bref commentaire pour l'expliquer.

De cette façon, vous pourriez leur apprendre quelque chose sans insulter leur intelligence individuelle ni embarrasser personne dans une discussion de groupe.

DavidR
la source
3

Je n'appellerais pas votre exemple un tour, mais juste idiomatique. Si vous devez l'utiliser, cela dépend non seulement du niveau actuel de votre équipe, mais de la présence de (au moins certains) de vos coéquipiers disposés à apprendre de nouveaux idiomes. Bien sûr, vous devriez discuter de ce sujet avec eux et ne pas leur imposer ce style. Et vous ne devriez pas leur demander d’apprendre chaque jour 5 nouvelles choses ou "astuces". Mais honnêtement, si vous avez seulement des coéquipiers qui ne veulent pas apprendre quelque chose de nouveau, même si c'est si simple et si petit que cet idiome, vous devriez envisager de passer à une autre équipe.

Doc Brown
la source
3

En lisant cette question et les réponses et discussions ultérieures, il semble y avoir deux points. Le premier: est-il possible d’utiliser des fonctionnalités linguistiques avancées? La seconde: comment puis-je faire cela sans apparaître comme si je "montrais"?

Dans le premier cas, il est judicieux d'utiliser des améliorations et des fonctionnalités avancées. Par exemple: en C #, vous n'avez pas à utiliser les expressions Linq ou Lambda, mais la plupart des gens le font car cela rend le code plus ordonné et plus facile à comprendre, une fois que vous savez réellement ce qu'il fait. Au début, ça a l'air étrange.

Les gens s'habituent aux habitudes et, dans de nombreux cas, ils utilisent la même méthode pour faire le travail. Je suis aussi coupable que le prochain homme. Nous avons tous des délais. À certains égards, vous êtes coupable d'introduire de nouvelles idées et de nouvelles façons de penser! Cela nous amène au deuxième point et c’est probablement là que vous rencontrerez peut-être le plus de résistance.

Pour la personne qui utilise le site Web, ils ne se soucient pas du style utilisé Tout ce qui compte pour eux, est-ce que ça marche? Est-ce rapide? Donc, s'il n'y a pas d'avantage en termes de performances, il n'y a pas de bonne ou de mauvaise manière dans l'exemple que vous donnez. Votre manière de rendre le code plus lisible ou non? Cela peut se faire une fois que vos collègues sont habitués.

Alors, comment introduisez-vous ces changements? Essayez de discuter avec vos collègues dans le sens suivant: saviez-vous que cette fonction peut être écrite de cette façon? Les revues de code et la programmation en binôme peuvent être un bon moment pour permettre une «pollinisation croisée» des idées. C'est difficile pour moi de prescrire quoi faire parce que je ne connais pas l'environnement dans lequel vous travaillez. Je trouve que certains programmeurs peuvent être très défensifs et résistants au changement. Encore une fois, je suis coupable de cela. La meilleure façon de travailler avec ces types de programmeurs est de passer du temps à comprendre ce qui les motive, à comprendre leurs antécédents, puis à comparer et contraster vos styles et expériences avec les leurs. Cela prend du temps mais c'est du temps bien dépensé. Si possible, essayez de les encourager.

Daniel Hollinrake
la source
Si vous pensez qu'il est plus facile pour vous d’expliquer ce que vous voulez dire dans un environnement C #, je doute que l’opération ne me dérange pas - je ne le ferais pas. Cette question ne concerne pas JavaScript. Imaginez que vous abandonniez des paramètres facultatifs, ou des lambdas dans votre code, car les autres développeurs de l’équipe ne le comprennent pas. Feriez-vous cela? Je pense que vous soulevez des idées intéressantes ici, mais si vous cessez de vous inquiéter du langage spécifique, vous pouvez l'écrire d'une manière plus convaincante :)
Benjamin Gruenbaum
1
Je travaille principalement avec C #, c’est donc l’exemple qui m’a le plus marqué. Vous faites valoir un excellent argument, à savoir si je renoncerais à des fonctionnalités linguistiques utiles simplement parce que d’autres ne les connaissent pas. La réponse devrait être non, mais bien sûr, la difficulté consiste à amener les autres à voir les avantages de cette nouvelle méthode, qui semble être le principal problème de Florian.
Daniel Hollinrake
3

N'allez pas travailler pour la Royal McBee Computer Corp alors, car qui dira que vous n'êtes pas un programmeur inexpérimenté?

Bien sûr, il est bon d’écrire du code court et succinct et il pourrait être utile dans un environnement javascript (jusqu’à ce que quelqu'un produise un compilateur Js à télécharger sur les navigateurs, mais c’est une autre histoire).

Cependant, ce qui est important, c’est la capacité de votre code à survivre au-delà des quelques minutes qu’il vous a fallu pour l’écrire. Bien sûr, c'est rapide et facile et vous pouvez le découper et passer à autre chose, mais si vous devez y revenir des années plus tard, c'est à ce moment-là que vous pourriez penser "quel muppet a écrit ceci", et réaliser que c'est vous! (Je l'ai fait, bien sûr, la plupart des gens l'ont fait aussi, honnêtement, je blâme les délais trop agressifs).

C’est la seule chose importante à garder à l’esprit, alors même si je dirais oui, allez-y avec cet opérateur si cela fonctionne et est clair, et vos développeurs «inexpérimentés» (bien que cela leur soit péjoratif, je sais des développeurs inexpérimentés qui connaissent tous les opérateurs et astuces car ils ont mémorisé divers tutoriels et références de pages Web, ils écrivent le pire code même s'ils connaissent chaque petite astuce ... il pourrait y avoir plus que des coïncidences)

Quoi qu'il en soit, si vous pouviez lire l'histoire de Mel , vous vous rendriez compte que les astuces ne sont pas les meilleures choses à intégrer dans un code, même si Mel était un véritable programmeur de premier ordre. Cela fait payer à tout argument où quelqu'un dit qu'il peut écrire un bon code et que tous les autres doivent en apprendre davantage pour suivre le rythme.

gbjbaanb
la source
1
Je ne connais pas un seul programmeur qui ne soit pas retourné à son code (il y a un mois!) Et soit allé "qui diable a écrit ça". Nous évoluons toujours dans le style (au moins nous essayons). Dans ce cas particulier , OP écrit du code standard, pas du code WTFish. OP ne parle pas d’écrire du code "intelligent" ou du code "plus court pour être cool", c’est idiomatique JS.
Benjamin Gruenbaum
2

Eh bien, pour commencer, cela ressemble à JS de base pour moi.

Mais en général - vous ne devriez pas utiliser de hacks intelligents, pour paraphraser "le débogage est deux fois plus difficile que la programmation. Si vous écrivez du code aussi intelligent que possible, vous êtes par définition incapable de le déboguer".

Cela ne signifie pas que vous devriez éviter le code simplement parce que les autres ne le comprendraient pas - vous devriez l'écrire de la manière la plus claire et la plus cohérente possible. Mais vos critères de clarté devraient être "est-ce que je comprendrai cela en première lecture dans un an" et non "quiconque le comprendra-t-il".

Ecrivez clairement que vous n’avez aucune difficulté à comprendre et laissez les autres travailler pour améliorer leurs compétences - ne vous handicapez pas afin de ne pas épargner aux autres un problème hypothétique.

jmoreno
la source
1

Je voudrais discuter avec mes coéquipiers du type de normes de codage que nous souhaitons, car il s’agit surtout de savoir comment faire ce que nous pouvons faire de plusieurs façons pour notre base de codes. S'il y avait un consensus, ce serait ma tentative initiale de réponse.

Si ce n’est pas le cas, j’examinerai probablement le type de norme proposée qui a du sens et la mettrai en pratique une fois que je l’aurai clarifiée avec la direction et une partie de l’équipe. L’idée ici est de s’assurer que la gestion est acceptable avec cette idée et que je ne me contente pas de faire ce que je veux et que je force ensuite tout le monde à l’accepter.

Je regarderais cela plus comme la question du type de normes et de pratiques de votre équipe plutôt que de simplement le niveau de compétence car il y a plusieurs façons d'évaluer le code. Comment bien les autres peuvent-ils le maintenir est l'un de ces critères.

JB King
la source
1

Le problème est que vous voulez une bonne lisibilité de la source, mais la lisibilité est dans les yeux de celui qui regarde.

Je dirais que nous avons besoin de meilleurs outils pour résoudre ce problème. Rien de complexe, remarquez, nous avons la technologie pour le faire depuis plus de 50 ans. Incluez un analyseur dans l'éditeur et demandez à l'éditeur de sauvegarder le code source sous la forme de sexps (oui, comme pour lisp). Ensuite, la source est lue, l'éditeur la déparre dans la syntaxe et la typographie (vous savez, les espaces, les tabulations, les virgules), la forme que l'utilisateur préfère.

De cette façon, vous pouvez taper et lire x = x || 10et les autres programmeurs le liront comme

if (0 == x) { x = 10;}

Emacs a toutes les pièces pour le faire facilement.

Pascal Bourguignon
la source
1
Dans ce cas, nous savons qui est le spectateur. Ils sont nos collègues. Je pense que cette phrase est normalement utilisée lorsque vous ne connaissez pas votre public.
Dcaswell
-1

Plutôt que de simplifier le code, pourquoi ne pas améliorer la qualité de l'équipe? La formation, l’encadrement, l’éducation et l’amélioration des pratiques d’embauche peuvent grandement contribuer à l’amélioration continue.
L'étatisme, la pourriture du code, le refus d'améliorer et d'innover parce que quelqu'un ne veut pas travailler à l'amélioration de soi-même ne font que causer des problèmes sur toute la ligne, et le plus tôt possible.

Bien sûr, dans le cas spécifique que vous montrez, vous essayez simplement d’être intelligent et d’écrire délibérément du code obfusqué, ce qui n’est jamais une bonne idée. Le code doit d’abord et avant tout être lisible, facilement compréhensible, et non pas écrit pour montrer à quel point vous êtes habile à créer quelque chose dans le moins de déclarations possible (sauf cas particuliers, comme lorsque davantage de déclarations conduiraient à une performance inacceptable, auquel cas de nombreux commentaires sont appelés pour).

jwenting
la source
5
Dans ce cas, je ne suis pas intelligent. J'écris du code idiomatique pour tout développeur expérimenté. Voyez-vous pourquoi je me bats maintenant? :)
Florian Margaine
3
Votre premier paragraphe est sur place, mais -1 parce que votre deuxième paragraphe est loin du but. Il est inexact de dire que cet exemple est une tentative délibérée d’être intelligent. C'est en fait très clair et, plus important encore, c'est un style idiomatique sur lequel de nombreux développeurs en javascript sont d'accord. Ce n'est pas le seul langage javascript utilisé pour les paramètres de fonction par défaut, mais c'est un langage courant.
Ben Lee