Discussion :

[lefou123456]

Bonjour,

Depuis quelques mois déjà j'ai commencé à développer en JS pour le web.
J'ai remarqué que dans certains points, on doit écrire des structures plutôt imposantes
et ne me semblant pas élégantes. J'ai aussi noté que chaque programme d'auteurs autres
présentent des fonctions longues, peu claires, avec des noms de variables courtes, ne décrivant pas la valeur...
Est-t-il nécessaire d'en faire de même, ou devrais-je changer ma façon de faire ?

Merci de l'attention !

[psychadelic]

On peut écrire du code dégeu dans tous les langages, même en JavaScript.

disons qu'en javaScript comme on peut rapidement tester et voir le résultat d'un bout de code en cours de test, certains ne prennent pas le temps de bien réécrire proprement leur code, voir même n'en prennent même pas conscience.

A toi de voir si tu veux être ou non dans le clan des chevaliers blancs et propres.

Avoir des noms de variable à rallonge n'a aucune importance, du moment que tu compresse ensuite ton code pour le placer en exploitation.
exemple : https://closure-compiler.appspot.com/home

[lefou123456]

D'abord, merci beaucoup pour la réponse !
Donc peu de personnes prennent pas le temps d'écrire du code propre !

[danielhagnoul]

Écrire du code "propre" c'est être capable de se relire rapidement, de corriger ou de modifier son code 6 mois ou un an plus tard.

L'indentation du code, les commentaires et les espaces pour aérer, rien n'est superflu. Si vous n'arrivez pas à coder avec "discipline", utiliser un "beautifyer" (exemple en ligne : https://html-cleaner.com/js/).

Mais il ne faut pas confondre le code en développement ( celui qui doit être maintenu par un humain) et le code en production (une copie du code en développement à l'instant T). Le code en production peut avoir été modifié par divers programmes (voir l'univers de node.js) et il est toujours compressé (exemple en ligne : https://closure-compiler.appspot.com/home), après quoi il est quasi illisible pour un être humain.

[SpaceFrog]

Les noms de variables explicites et autres commentaires ainsi que l'indentation correcte sont indispensables et permettent de reprendre son code 6 mois plus tard comme le dit Daniel.
Pour ma part j'ai des fichiers de développement qui sont bien indentés et commentés, mais cela n'est pas toujours imparable pour un poisson rouge comme moi... Un tour de bocal et hop j'ai déja oublié pourquoi j'ai codé telle ou telle bidouille. Et mon commentaire qui me semblait très explicite au moment ou je l'ai rédigé devient une énigme. Mais cela fait le charme du développement ^^.
J'ai à coté de cela les fichiers de production qui eux sont passés au compresseur afin de raccourcir les noms de variables et supprimer les commentaires, juste histoire de gagner quelque kilo avant l'été sur la plage. Pardon avant la mise en production.
Et personne n'a besoin de comprendre mes js en prod ...

Donc selon moi le code propre n'a de sens que pour la maintenance.

Après si par "propre" tu entends en utilisant les bonnes méthodes et pas de bidouilles ... Je pense que 98% des js en production sont truffés de bidouilles et autres contournement par méconnaissance du JavaScript. Et puis il y a plusieurs écoles, plusieurs façons de coder...

[Marco46]

Un bon moyen de progresser sur les bonnes pratiques et de contrôler son code est d'utiliser des linters. ESLint est le plus connu et le plus utilisé (énormément de plugins pour personnaliser en fonction des pratiques et des frameworks et librairies utilisées).

[lefou123456]

Merci !

[ABCIWEB]

Pour ma part j'ai des fichiers de développement qui sont bien indentés et commentés, mais cela n'est pas toujours imparable pour un poisson rouge comme moi... Un tour de bocal et hop j'ai déja oublié pourquoi j'ai codé telle ou telle bidouille. Et mon commentaire qui me semblait très explicite au moment ou je l'ai rédigé devient une énigme. Mais cela fait le charme du développement ^^.

Tiens ça me rappelle quelqu'un

Le problème est que l'on fait des commentaires par rapport à un contexte donné, et ce contexte n'est plus le même quand on regarde le code d'un point de vue global. C'est le problème que j'ai constaté le plus souvent dans mes commentaires. En même temps on est "obligé" de coder assez vite pour ne pas perdre la logique du code qu'on est entrain de faire sinon le temps de développement augmente significativement. Et l'on se retrouve toujours devant l'éternel dilemme entre la productivité/rentabilité et le fait de passer suffisamment de temps (que le client considèrera souvent comme du temps perdu) pour bien documenter le code afin de faciliter sa maintenance et son évolution.

Ce n'est donc pas étonnant que lefou123456 puisse voir des choses très différentes, mais comme dit psychadelic ce n'est pas spécifique à ce langage. Par contre, comparé à un langage "facile" comme Php, javascript est beaucoup plus complexe car la programmation événementielle demande plus de réflexion et par ailleurs javascript est très polymorphe. Pour dire que les commentaires ont ici une importance cruciale.

Niveau pratique, coder avec le mode "use strict" permet d'éviter beaucoup des erreurs d'inattention (variables non déclarées etc.).

Après niveau "élégance", "fonctions longues" cela peut aussi être très variable et dépendre du contexte.

[Watilin]

Peut-on programmer proprement en JavaScript ?

C’est marrant cette question, j’aurais presque cru à un troll si on n’était pas sur Developpez.com. Heureusement ici l’ambiance est à la patience et à la pédagogie.

J'ai aussi noté que chaque programme d'auteurs autres
présentent des fonctions longues, peu claires, avec des noms de variables courtes, ne décrivant pas la valeur...

Le problème de JavaScript c’est son écosystème. Les ressources qu’on trouve sur le Web sont, pour une majorité, trop vieilles, encouragent des pratiques obsolètes ou tout simplement mauvaises. Il faut déjà avoir une certaine expérience pour déterminer ce qui est une bonne ressource de ce qui ne l’est pas. Par exemple, le site w3schools a longtemps été critiqué, à tel point que le site parodique w3fools a vu le jour. Depuis, w3schools a fait des efforts pour rattraper son retard, mais ça reste inégal.

J’aurais tendance à vanter le MDN pour son aspect wiki qui le rend plus réactif aux évolutions technologiques. Personnellement, j’aime aussi m’alimenter aux blogs de différents gourous quand il s’agit de points très techniques ou de nouveautés du langage. Des noms en vrac : Brendan Eich, Peter-Paul Koch, David Walsh, Douglas Crockford, etc. J’en oublie certainement des tas !

[Marco46]

Eric Elliott et sa JavaScript Scene sur Medium aussi c'est bien sympa.

[psychadelic]

Pour en rajouter une couche, je dirais qu'a force de réécrire son code plus proprement, de bien analyser et de confronter son écriture avec celle d'autres codeurs, on fini par savoir écrire un code presque propre dès le départ.

l'expérience y joue indubitablement son rôle.

[ABCIWEB]

Je rebondis sur le message de Watilin pour appuyer l'utilisation de la doc MDN qui est presque toujours la plus complète et même souvent traduite en français ce qui ne gâche rien. Dans un moteur de recherche il suffit de taper le nom d'une fonction javascript ou d'une balise html suivie de mdn pour trouver la doc en première ligne. Pratique pour consulter la meilleure source en premier. W3school peut rendre aussi de bon services mais j'y vais toujours en seconde intention.