Discussion :

[zecreator]

Bonjour à tous,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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..."

[ProgElecT]

Salut

Oui on pourrait cesser.

[NoSmoking]

Bonjour,
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).

[psychadelic]

C'est vrai, il faut mieux écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Marco46]

ESLint est ton ami.

[zecreator]

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

[SpaceFrog]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Doksuri]

3615 MAVI

[zecreator]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[NoSmoking]

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

[Invité]

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[Marco46]

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 !

[psychadelic]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Projector.start=Projector.start||timestamp;

plus court encore...

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

[zecreator]

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...

[Invité]

Projector.start=Projector.start||timestamp;

non car 0!=null

[Marco46]

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.

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".

[zecreator]

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...

[Marco46]

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.

[zecreator]

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.

[shroomsconect]

Bonjour,

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

Code js :

Sélectionner tout - Visualiser dans une fenêtre à part

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