Ecriture de code que je déteste

Bonjour à tous,

Est-ce que l'on pourrait cesser d'écrire des conditions en JS de cette façon :

Code:

---

if (Projector.start === null) Projector.start = timestamp;

---

C'est franchement illisible lorsqu'il y a 20 000 lignes de codes à inspecter. Merci d'écrire :

Code:

---

1 2 3

if (Projector.start === null){ Projector.start = timestamp; }

---

En respectant l'indentation qui va avec. Merci.
C'est tout de même pas compliqué, BORDEL DE M...

Les accolades, faut pas hésiter à les utiliser, juste parce que "T'ES PAS TOUT SEUL AVEC TON CODE..."

Salut

Oui on pourrait cesser. :aie: :mouarf2:

Bonjour,
:koi: je ne comprends pas trop le but de ton post, coup de gueule ?

Oui c'est une mauvaise façon de faire, entre bien d'autres.

Pourquoi ne pas commencer à le dire au(x) principal(aux) concerné(s) que tu as rencontré(s).

C'est vrai, il faut mieux écrire :

Code:

---

Projector.start = Projector.start || Math.round(+new Date() / 1000);

---

:mouarf:

ESLint est ton ami.

Citation:

---

Envoyé par NoSmoking

:koi: je ne comprends pas trop le but de ton post, coup de gueule ?

---

Oui, je râle :) Je dois me farcir 37 000 lignes de codes de ce genre, avec des commentaires quand le ou les mecs ont eu le temps d'en mettre, et de l'indentation merdique. Et pour l'indentation, merci d'utiliser la touche TAB, pas 2 ou 3 espaces (le nombre varie selon la générosité du codeur). Si ce n'était que des cas isolés, ça irait, mais j'ai l'impression que ce genre d'écriture se généralise...

ça va me faire une bonne semaine je crois lol

Code:

---

(Projector.start === null) && (Projector.start = timestamp);

---

Code:

---

Projector.start= (Projector.start === null)? timestamp : Projector.start ;

---

3615 MAVI

Citation:

---

Envoyé par SpaceFrog

Code:

---

(Projector.start === null) && (Projector.start = timestamp);

---

Code:

---

Projector.start= (Projector.start === null)? timestamp : Projector.start ;

---

---

Ou comment économiser 3 lignes pour rendre son code illisible. Même pas sûr que ce genre de code puisse être correctement tracé par le débuggeur...

Fait une simple recherche avec beautifier javascript, tu économiseras bien du temps par la suite.

Citation:

---

Projector.start= (Projector.start === null)? timestamp : Projector.start ;

---

tant qu'à faire sauvons quelques caracteres grace à la coercion :mrgreen:

Code:

---

1 2 3

Projector.start+=(Projector.start==null)*timestamp;{ }

---

ps: j'ai pris soin de rejouter les accolades et l'indention.

Citation:

---

Envoyé par zecreator

Oui, je râle :) Je dois me farcir 37 000 lignes de codes de ce genre

---

Tu as une option --fix sur ESLint qui te fixe automatiquement une grande partie de ces problèmes. Tu devrais peut être jeter un oeil à cet outil !

Citation:

---

Envoyé par galerien69

tant qu'à faire sauvons quelques caracteres grace à la coercion :mrgreen:

Code:

---

Projector.start+=(Projector.start==null)*timestamp;

---

---

Code:

---

Projector.start=Projector.start||timestamp;

---

plus court encore... :mrgreen:

ceci dit, je commence à loucher du coté d'ESLint, mais je n'ai rien vu qui y parle de prés ou de loin qui permette de régler le style, au moins en Allman (le plus reconnu), même si je penche plutôt pour le Whitesmiths (qui semble boudé par le reste de la planète)
https://fr.wikipedia.org/wiki/Style_...le_Whitesmiths

Non mais j’ai pas besoin d’un outil pour m’expliquer un code, à partir du moment où il est correctement codé. Après si le standard c’est de coder salement, alors oui, ESLint devient un Outil indispensable au codeur. Quelle tristesse...

Citation:

---

Projector.start=Projector.start||timestamp;

---

non car 0!=null

ESLint ne sert pas à t'expliquer le code, il sert à garantir qu'un style consistant sera appliqué partout, c'est à dire exactement ce que tu reproches au code sur lequel tu travailles de ne pas avoir.

L'idée c'est d'avoir un système automatisé qui va te dire "à la ligne 38 du fichier toto.js t'as pas respecté le style (règle bidule violée), à la ligne 23 du fichier titi.js t'as violé la règle truc", et t'auras la possibilité de réexécuter l'outil avec l'option --fix pour corriger ça automatiquement.

Si tu te rajoutes des hooks de precommit / prepush qui exécutent ton linter + tes tests tu t'assures d'avoir une code base propre dans ta branche d'intégration des devs.

Citation:

---

Envoyé par zecreator

si le standard c’est de coder salement, alors oui, ESLint devient un Outil indispensable au codeur.

---

ESLint (ou autre) est indispensable pour les projets sérieux parce que tout le monde fait des erreurs à ce niveau, même les plus expérimentés. Ça permet aux débutants de s'appuyer sur un outil automatique avec une superbe doc pour progresser et ça évite aux plus anciens de perdre du temps avec le style lors des revues de code.

Il y a de plus en plus de boites et de projets opensource ou tu ne pourras pas ajouter une contribution sans passer ce genre de vérification exactement comme l'exécution de suites de test.

Tu as tort de prendre ça de cette manière, c'est à peu près comme refuser les tests automatisés parce que "tester c'est douter".

Citation:

---

Envoyé par Marco46

Tu as tort de prendre ça de cette manière, c'est à peu près comme refuser les tests automatisés parce que "tester c'est douter".

---

Et comment tu appliques ESLint, sur du code vieux de 10 ans, où il y a eu 15 développeurs qui codaient différemment ? Non, parce que tu te doutes bien que j'ai essayer d'appliquer des rêgles de style. mais sur du code archi-pourri, et écrit de 20 manières différentes, ça ne sert à rien. Voire, c'est pire...

Sans compter des morceaux de code qui sont présents et qui ne sont jamais utilisés. J'aurais pas perdu ma semaine, mais mon sommeil sans doute...

Ben si t'as pas de tests automatisés pour vérifier que le fix ne casse rien effectivement ça risque d'être un peu chaud avec 30K+ LoC.

Mais il y a quand même un bon paquet de choses qui peuvent être fixées automatiquement sans risquer de casser ton code, à commencer par l'indentation et les tab au lieu des espaces.

Je suis un développeur "old school". A l'époque, quand j'ai appris le métier, on m'a enseigné les bons réflexes. Et je dois bien avouer que aujourd'hui, je ne comprends pas cette confiance aveugle qu'ont les développeurs pour les systèmes qui "réécrivent" le code à leur place.

Même si aujourd'hui dans mon métier, on me l'impose, je ne peux pas m'empêcher de reformuler le code car souvent (très souvent même), ma réécriture est plus optimisée, et je sourie quand l'un de mes collègues me remercie d'avoir indenté comme il faut et placé des commentaires compréhensibles sur un script qui lui aurait demandé 6 jours à comprendre.

Après, oui niveau délais, je suis souvent dans les choux. Mais mon code est ultra propre lol.

Bonjour,

Utiliser des raccourcis, n'est pas forcement synonyme d'illisibilité.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

// Excuse d'avance la tabulation ne fonctionne pas sur cette éditeur de code let test=false;   (test)?console.log('VRAIE'):console.log('FAUX'); test=true;   (test)?console.log('VRAIE'):console.log('FAUX'); test=false;   if(test){ console.log('VRAIE'); test=false;} else{ console.log('FAUX'); test=true;}

---

Je ne vois pas en quoi c'est illisible, j'aime bien, cela simplifie le code et le rend plus dégustatif.
Chacun sa méthode et je pense que votre problème c'est surtout l'indentation qui peut vite être exécrable.

C'est surtout que vous avez l’habitude d'un code formulait d'une certaine manière et on vous le change, c'est un peu comme utiliser un autre langage de programmation, essayez le shell c'est bien sympa ;)

Là oui, y a pas de difficulté majeure à lire ton code et à le comprendre. Mais quand tu as ce type de code, encapsulé dans une bouillie de code non indentée, sans saut de ligne, sans espace (je soupçonne le mec d'avoir voulu minifier son code à la main), ben tu prends 20 ans en 1 semaine.

J'ai fini par dire au client que con code n'était pas exploitable et que cela allait me demander 10 fois plus de temps à le mettre à jour qu'à lui recoder un truc propre. Avec le budget initial, c'était juste pas rentable pour moi de faire le job. Après avoir fait appel à 5 autres développeurs qui l'on aussi lâché pour les même raisons, il est revenu vers moi et attends une proposition de re-développement. Enfin, un client lucide...