10 astuces pour éviter les structures if/else ennuyeuses dans votre code

[@lambertteisserenc5915]

Excellente vidéo ! Il y a juste un point où je ne suis pas totalement d’accord c’est le fait de trier un tableau pour ensuite le parcourir. On perd en performance car on fait parcourir à l’ordinateur deux fois le tableau, une pour le trier et une pour le parcourir. Pour gagner en visibilité j’aime bien mettre une condition qui vérifie à chaque itération de ma boucle si je dois ignorer ou non cette itération. C’est lisible et plus performant 😊 Pour des tableaux qui sont trees longs, si on peut diviser le temps par deux ce n’est pas négligeable.

[@marcelouiki7220]

c'est du js ils en ont rien a faire de la perf

[@quenti7728]

En fait c'est bien de penser au perf mais il est préférable de d'abord penser à la lisibilité et si vraiment la perf montre qu'il y a un problème alors on optimise en rendant des fois le code moins propre. Sachant que en réalité on ne parcours le tableau 2 fois complètement que si le filtres renvoient tous les éléments donc dans le pire des cas on est sur du 2*n éléments et au meilleurs des cas ou est sur du 1*n éléments parcouru. Autre point aussi si tu as besoin de garder la valeur après filtres pour plusieurs choses à faire c'est possible aussi. En tout cas je préfère un code lisible d'abord puis optimiser que l'inverse car l'inverse quand on doit update le code est plus risqué.

[@kadwallenboscogne1745]

Le code, c'est fait avant tout pour être utiliser sur la machine de l'utilisateur final. Il faut donc viser la fiabilité (pas de bug, résilience, etc.) et la performance en premier lieu. La lisibilité est intéressante dans la mesure ou elle permet de mieux retrouver ses billes. Encore ne faut il pas confondre ce qui relève de la structuration du code et ce qui relève du sucre syntaxique. L’intérêt de trier un tableau dépend de l'algo utilisé, du nombre d'entrées que contient le tableau et de combien de recherche seront faites ultérieurement dans ce tableau. En fait, plus les tableaux sont long, plus il devient intéressant de les trier avant, car le temps mi pour le tri sera compensé par la vitesse à laquelle on trouvera la donnée recherché. Cela dit les tableaux "long" en JS sont en général des tableaux court dans d'autres langages. Le test à chaque itération est généralement plus performant.

[@iamavegetable1936]

J'ai regardé cette vidéo à plusieurs reprises, car je trouve son contenu très pertinent et enrichissant. Au fur et à mesure de mes visionnages, force est de constater que je n'écris plus mon code de la même manière. Bravo à vous et merci de nous partager tous ces conseils.

[@JeanMariePapillon]

Petite remarque : laisser les codes à l’écran plus longtemps.. C’est difficile de lire sans faire de pause dans la vidéo. Le « guard clause », est un excellent réflexe pour limiter les imbrications, j’utilise toujours ça. C’est plus lisible, ce qui est le critère de qualité le plus important d’un code.

[@codeursenior]

D’accord, merci pour votre retour. Cependant pour ne pas polluer la vidéo j’essaye d’éviter de laisser les captures d’écrans trop longtemps. Je pense envoyer les extraits de code par e-mail en compléments pour ceux qui sont abonnés a la Newsletter. Merci pour votre retour constructif ! À bientôt, Simon.

[@gilpel77]

J'apprends énormément avec le contenu que tu nous proposes et ta pédagogie est unique, mais je suis comme @JeanMariePapillon, je dois faire pause et retrouver le screenshot fugace pour travailler tes exemples. Je vais de ce pas m'abonner à ta newsletter, mais je ne suis pas certain que je ferai toujours l'effort de retrouver le mail quand je regarderai ta vidéo. Donc je pense que les laisser en insert plus longtemps sur le côté de ta vidéo, ou même en plein milieu de l'´écran (si c'est plus simple à l'éditing), serait parfait. En tous les cas, merci pour tout ce que tu nous proposes!

[@codeursenior]

@@gilpel77 Hello, merci pour ton retour constructif. C'est un vrai sujet, parler de sujet technique en vidéo, et trouver un équilibre entre les explications et les captures d'écran. Je vais regarder comment équilibrer tout ça. Peut-être compléter la vidéo avec un article "écrit" pour retrouver plus rapidement tout ça. Bon code !

[@TwistedPJ]

J'utilise déjà ce genre d'astuces la plupart du temps mais c'est une vidéo intéressante. Tout les langages ne fournissent pas forcément tout les outils nécessaires pour supprimer if/else a ce point (par exemple le C étant par nature très bas niveau n'a pas tout ces sucres syntaxiques mais on peut déjà supprimer énormément de if/else). Après voilà, il ne faut pas non plus être obsédé par les supprimer a tout prix mais plutôt ne pas en faire un automatisme ce qui devrait déjà être le cas pour tout développeur ayant un peu d'expérience. Je n'ai pas regardé le reste de la chaine mais ça me fait penser que avoir un seul 'return' par fonction est, quand c'est raisonnable, une bonne chose aussi par exemple.

[@Creativeetea]

Merci encore, je regarde cette vidéo plusieurs fois, et elle m'a gravement fait avancer. Franchement c'est ce genre de contenu qui m'intéresse (sans musique, ni élément flashy de KZbinur, juste du basique, tant que le contenu est là, la forme est futile. Je dirais même la forme tend a tuer le contenu, tant elle laisse le youtubeur dans une sorte de contentement, étant donné qu'il pense que la lumière violette, le micro et les animations sont une finalité en soi).

[@codeursenior]

Tout à fait d'accord avec vous. Lors de la production de chacune de ma vidéo, je me pose la question "Est-ce que ça sert réellement à quelqu'un" ? Si la réponse est oui, alors je la publie.

[@AngusBox]

Mais excellent !!! Le coup du if else sur un return... mais comment j'ai fait pour ne pas penser à ça avant! Tellement évident, mais tellement smart.

[@scottmeyer1550]

Merci pour tes explications. C'est très claire et propre 👍 (juste le code sur les objets qui sont encore difficile pour moi à comprendre). Bravo. Grâce à toi je progresse ! 😎

[@ecom79fr]

Superbe vidéo, merci ! Petite question, en terme de performance, quelles sont les avantages, que ce soit en terme de vitesse ou d'utilisation mémoire ?

[@albinpouilles]

a 14:36, la fonction hasImage() retourne true si il n'y a pas d'image et false si il en a une? ce devrait être le contraire, mais ce n'est pas le propos de la séquence qui est sur image()....

[@DavidRENAUD-ss5yj]

Merci Simon, très instructif, surtout le ?? que je ne connaissais pas 👍

[@codeursenior]

Oui cet opérateur est méconnu et c’est bien dommage ! Bon code à toi, Simon.

[@udyrEnJellabaLacoste]

Super vidéo merci, existe t'il des livres en français super dans le domaine JS, PHP, SQL ? (pour ne pas citer de librairie)

[@nunn]

Il ne faut pas croire que ces vidéos ne sont faites que pour des dev's sur la voie de la séniorisation : en tant qu'amateur je me suis délecté. Merci infiniment.

[@codeursenior]

Holà, merci pour votre retour. Au top que la vidéo soit accessible à tout le monde ! Bon code et bon apprentissage, Simon.

[@bid0u12345]

9:43 Le double point d'exclamation, pas d'interrogation. Super intéressant ceci dit ! C'est dommage de ne pas être rentré dans les détails pour le 9 car ça aurait justement valu le coup de ne pas l'expédier. C'est un peu frustrant. Tu en as d'autres des vidéos comme ça, où tu montres comment réduire son code efficacement avec un exemple avant/après ? Y a tellement de "raccourcis" que c'est pas évident de tout connaître. Je dirais même que c'est pas évident de simplement savoir que ça existe. 😅

[@daaa57150]

Pour le 9, cherche le "strategy pattern".

[@honkhonkv2236]

Salut! Déjà merci , si tu continues sur ce genre de format, ce serait incroyable si tu pouvais partir d'un exercice avec un code non-refactorisé, nous laisser essayer de le faire de notre coté et ensuite nous montrer / expliquer la re-factorisation. En tous cas super vidéo.

[@codeursenior]

Hello, idée absolument génial. 1H de live de refactoring. Tu as une idée de code Angular à reprendre ? Au plaisir d'échanger !

[@honkhonkv2236]

@@codeursenior Je n'y connais absolument rien en angular malheureusement mais simplement """refaire""" tes vidéos "n'utilisez pas..." sous forme d'exercices ou sous forme de live (encore mieux) avec rediffusion sur cette chaine, perso ça me mettrait TRÈS TRÈS bien. Que ce soit du js natif / angular (pour ceux que ça intéressent, j’imagine qu'il y en a beaucoup sur ta chaine) / react ou autre, pour être sincère même du html non-sémantique en html sémantique je trouverais ça fou. Ce serait top de chez top !

[@codeursenior]

@@honkhonkv2236 Hello, ce n'est pas tombé dans l'oreille d'un sourd ! Je me note l'idée pour une vidéo, peut être cette année !

[@honkhonkv2236]

@@codeursenior 🙏

[@nrt255]

à 6:06 : J'avais appris le fait de mettre des return au lieu de if else (c'était en java et il y a de cela pas mal d'années). Cependant aujourd'hui de plus en plus de développeurs et même tech lead ne supportent plus d'avoir plusieurs return dans une fonction, c'est régulièrement refusé dans les PR

[@codeursenior]

Bonjour, sur quelle langage vous travaillez où plusieurs instructions "return" sont refusées ?

[@Crocmitou]

Merci. Toujours pertinent

[@myfreedom42]

j'ai rien appris, mais c'est chouette comme vidéo ;)

[@LinkingWorlds]

Pour les jeunes développeurs, c'est super de sensibiliser à cette approche du codage, même si je sais, des seniors font encore ce genre de.... Merci Simon pour tes partages et ton intégrité, ta transparence.

[@Jol_CodeWizard]

Je vous conseillerais d'écouter plusieurs sons de cloches, et de ne pas juger un "senior" sous prétexte qu'il ne tient pas le même discours qu'un autre "senior" que vous aimez bien.

[@thomstunes6485]

Les guard close je les écrit même sur une seule ligne. Comme ça, rien qu'en survolant le code des yeux je sais que c'est une condition qui sort immédiatement de la fonction ou de la méthode.

[@moaly4738]

Trop excellente cette vidéo ! merci !!

[@shadowysuper-coder6120]

Bonjour Simon, je cherche sans succès la vidéo que tu as faites sur Filter, Map, Reduce... Tu avais une méthode très sympa pour savoir instantanément laquelle est celle dont on a besoin en fonction du résultat attendu (une valeur, un tableau plus petit que le tableau intial, un tableau de même taille). Saurais tu me dire quel est son titre ? Merci !

[@ctrl_fj]

"3 méthodes JavaScript à connaître absolument : 25 min de Tutoriel JavaScript" - map() : Mon tableau est différent mais fait la même longueur - filter() : Mon tableau est plus petit en longueur - reduce() : Mon tableau de sortie est une valeur

[@amarasalim5706]

Merci Simon , des astuces tres importantes .J'ai une question par rapport une architecture scalable cote front avec angular . Quel choix strategique je peux appliquer pour mon application (nx , micro front , Ngrx , story book , module federation...)? Et merci 0:01

[@misterbalise]

merci pour la video 👍 meme si je ne fais pas de javascript pour le moment mais du python/php la vidéo est tout de même exploitable, car ce qui compte c'est les idées et les concepts

[@maeltoukap1903]

Bravo. Tu me change la vie 🤌🏾👏

[@thiernodiallo782]

De très bons astuces ! Le seul souci est qu'il est un petit peu axé sur JavaScript, ce qui fait que certaines astuce ne sont valide qu'en js et libs/metaLangage/frameworks

[@codeursenior]

C'est exactement ça. Il faut trier tout adapter si vous êtes sur des langages plus "robustes".

[@fabricehategekimana5350]

Super vidéo ! Je me suis abonné à la chaîne. Ce sont des tips super pratiques ! Je me rends compte que ces cas avec les if else peuvent être étonnament facile à éviter avec un système de type comme typescript. Je dois avoué que le typage statique du langage Rust me fait écrire une condition if else seulement tout les 1000 lignes de code. Je pense que les systèmes de type sont l'avenir

[@mwlulud2995]

Intéressant!

[@TwistedPJ]

D'un autre côté la plupart des langages ont un typage statique, je n'ai pas compris votre remarque. Si vous venez de php et de javascript c'est sur que ça doit vous changer. Javascript a la base c'est un truc fait a l'arrache pour mettre un peu de dynamisme dans les pages web et l'auteur n'a jamais eu vocation à ce que ça devienne ce que c'est aujourd'hui et c'est pour ça que ça à été pendant des années un langage "de merde" (excusez-moi). Ce n'est finalement que ces 10 dernières années que l’écosystème et les outils (comme l'apparition de typescript et d'autres éléments) l'ont sorti de ce statut de "langage pour bricoler un truc vite fait".

[@lepangolin]

Super cool comme vidéo :) !

[@codeursenior]

Merci !

[@frankdearr2772]

sujet bien presenté, merci 👍

[@codeursenior]

Au top, merci pour ton retour. Bon code !

[@hichamasbagui3746]

Salut Simons. Tes vidéos sont super intéressante et instructive, ta manière d'expliquer est parfaite pour moi. J'aurai juste une remarque à faire, tu devrais mettre plus en avant les images du code que te filmé. C'est un peu galère de mettre la vidéo en pause pour check le code puis remettre en marche et suivre ton explication. En tout cas un grand merci pour le temps que tu passes sur tes vidéos

[@petit-hommeben-jacques5606]

Merci beaucoup! J'ai tellement appris ...🤩😍

[@codeursenior]

Au top, merci pour ton retour. Bon code pour la suite !👍

[@eo3432]

Oui, pas bon les if/else pour la multiplication des branches d'exécution. Dommage que le code refactoré soit encore moisi. Affecter un age avec une chaîne de caractères ? Sérieusement ?

[@codeursenior]

Merci pour votre commentaire bienveillant !

[@lsequoiass3704]

Je ne connaissais pas l'opérateur de chainage donc merci

[@quinqua_burne]

Dans la fonction canRedirectToAdminDashboard(), j'aurais plutôt vu un switch type es2020 : switch(true) { case(!wifi): console.log("Must be connected first"); break; case(!login): console.log("Must be login first"); break; case(!admin): console.log("Must be connected as administrator"); break; } Qu'en penses-tu ?

[@DystoKhan]

C'est sensiblement la même chose qu'un if/else. Match/if-else/Switch c'est du pareil au même dans les langages interprétés. Par contre utiliser une programmation "branchless" c'est efficace (donc éviter les structures de condition)

[@quenti7728]

Je suis dacord et en plus on pert l'intérêt du switch avec la condition 'true' que tu mets à l'intérieur. Le fait de faire en guard clause comme montrer permet vraiment d'avoir une logique d'exécution plus claire (je trouve)

[@robintruvelot573]

Super vidéo encore merci pour ces précieux conseils !

[@codeursenior]

Avec plaisir ! Bon code à toi, Simon.

[@twoonetwo7751]

Ça fait plaisir de te revoir Simon ! Reviens au plus vite ac du contenu angular 🙏🏼

[@codeursenior]

Merci, j'y compte bien ! 🚀

[@moneyfr]

C'était magnifique 🎉

[@juliensambo5672]

Une Master Class bro...

[@SoftSkillSecrets]

merci simon toujours du code 1% , je kiff ton taf tu es genial tu nous aide vraiment a passer pro

[@codeursenior]

Merci pour ton retour, l’objectif est atteint alors ! 💪

[@wpecnik2]

Dans le test d egualité on met TOUJOURS la constante en premier !!! If a == '1' devient if '1' == a ....pourquoi ? Car si on oublie un = ..l affectation a une constante fait une erreur !

[@daaa57150]

Ahh j'avais jamais pensé à ça

[@pinnin94]

Merci Simon pour ce contenu remarquable. Pourrais-tu s’il te plaît. Nous faire la liste de 10 livres que tu nous recommande ?

[@ypeex7772]

j'ai regarder la vidéo avec beaucoup de présomption, et au final je suis agréablement surpris.

[@codeursenior]

Au top, mission accomplie.

[@pegasusgemini6541]

Les guard clauses (fail-first) c'est hyper important : - on tue (ou mitige) la dépendance de probabilité entre 2 conditions - le code est plus clean - ON GERE MIEUX LES SCENARII ALTERNATIFS, ET IL EST PLUS FACILE D'EN AJOUTER OU D'EN RETIRER

[@codeursenior]

Contant d'avoir un soutien sur les Guard Clause !

[@leunam3859]

superbe vidéo merci beaucoup

[@codeursenior]

De rien, bon code pour la suite !👍

[@karterel4562]

Excuse , t'aurais pas la liste des livres les dont tu parle je vais les acheter, au fait j'aime bien les versions numérique ! J'espère que c'est pareille

[@xavier_le_x]

"Ca a fait planter le projet en production", la phase de recette ? Le test unitaire ? 😅

[@oliviernavatte3614]

Vidéo indispensable ! Merci beaucoup, j'ai appris plein de choses. Par contre, il me semble qu'il manque l'opérateur ternaire, qui est un grand classique. (Trop évident pour apparaitre dans la vidéo peut-être ?) Example: if(login) { message = "Connection successful"; } else { message = "Must login first"; } Remplacé par: message = login ? "Connection successful" : "Must login first";

[@codeursenior]

Merci pour ton retour ! Concernant le ternaire (et la structure conditionnelle switch), pour moi cela n'a pas sa place dans la vidéo, car ce sont juste 3 syntaxes permutables pour faire la même chose (ternaire, if/else ou switch). L'idée ici est de casser la structure conditionnelle en une couche plus pertinente en fonction du cas d'utilisation. Qu'en penses-tu ? Au plaisir d'échanger, Simon.

[@petit-hommeben-jacques5606]

Opérateur ternaire👍

[@sasori1187]

J'adore tes vidéos !

[@d00DotCss]

const age = response?.data?.age ?? "String" - Super sexy, merci, je ne connaissais pas🤩

[@samir1441a]

9:10 planté en prod ?!! tu n'as pas testé ton appli (TU / Tests fonctionnels) 😉

[@makes5819]

T'es miniature sont excellents 😂

[@alexg7282]

Super utile Merci !

[@codeursenior]

👌

[@koomky]

Bien! Attention, qualité audio très moyenne, écho trop présent.

[@codeursenior]

Hello, ok merci pour le retour. Je vais être attentif sur ce point, une vidéo dans l’audio c’est pas la peine.

[@matthieudantes4129]

Merci!

[@codeursenior]

De rien!

[@Melon-Vert]

Super intéressant, ça donne envie d’aller voir tes autres vidéos. Merci pour ce contenu

[@fayepapamamadou9332]

Excellent !

[@kevinsamuelndoum6992]

Merci

[@Arasiian]

Super conseils :) merci

[@codeursenior]

Merci pour ton retour, au top !

[@synergydevelopment3666]

Bonne vidéos, par contre j'ai pas vu de switch/case ou de ternaire (ou je les ai raté) puis il y a aussi if (a===0) return true; else return false; on peut juste faire return a===b;

[@codeursenior]

Hello, de mon point de vue c'est du bidouillage de syntaxe sans apport sur le traitement algorythmique (if/else switch ternaire).

[@quenti7728]

switch case de mon côté je m'en sert jamais quasiment car tout comme on peut replace des if/else par d'autre méthode, on a la même chose avec switch case. Exemple remplacer par un objet avec clef/valeur qui serait ce que tu ferais avec ton switch case Pour le ternaire c'est vrai qu'il est intéressant par exemple comme retour de function qui ne renvoie pas un boolean. Exemple (con mais c'est l'idée): function isAdult(age: int): string { if (age === 18) { return 'First year as an adult GG' } return age > 18 ? 'Adult' : 'Child' } ça m'arrive parfois d'avoir une fonction/méthode qui finit comme ceci : function a() { return condition() ? value_when_true() : value_when_false() }

[@codeursenior]

@@quenti7728 Hello, oui aucun soucis. Quand je dis « bidouillage de syntaxe", je veux dire que je n'ai aucune croyance forte là-dessus. C'est ce qui convient le mieux à l'équipe qui fait foi. Bon code à toi ! Simon.

[@kadwallenboscogne1745]

J'utilise ces mêmes techniques et d'autres (notamment en utilisant les opérateurs bit à bit) sans avoir ouvert le moindre bouquin à ce sujet. Ce qui différencie une "good practice" d'une "bad practice" tient au fait de si une personne relativement connu en parle dans son blog, livre, conférence. Les structures if/else ne sont pas forcément ennuyeuse. Tout dépend de ce qui est testé et de comment c'est testé...

[@Jol_CodeWizard]

"Ce qui différencie une "good practice" d'une "bad practice"" Tu n'en as plus du tout la même conception au bout de trente ans, dont vingt à maintenir des applications 🙂

[@philtoa334]

Excellent.

[@jc13OM]

Essentiel, merci !

[@codeursenior]

Au top, le niveau est en train de monter !

[@djcaesar9114]

Tes miniatures me font rêver.

[@codeursenior]

De loin ma partie favorite de chaque vidéo. 👍

[@djcaesar9114]

@@codeursenior Figure toi que c'est grâce à elles que j'ai jeté un coup d'oeil à ta chaîne. Bon investissement de ta part!

[@codeursenior]

​@@djcaesar9114 Au top, il me reste plus qu'à bosser sur le contenu et je serai officiellement KZbinur. 👍

[@sasalilime]

Vidéo intéressante Par contre il vaudrait mieux utiliser le Boolean() que le !! Pour la lisibilité :)

[@codeursenior]

Bonjour, sujet intéressant car le l’inter JavaScript de Airbnb recommande plutôt l’opérateur « !! ». Le plus important sur ce genre de sujet est généralement de se mettre d’accord avec son équipe.

[@maldoror4035]

C'est pas Martin Flower. C'est Martin Fowler. (Et ça se prononce Martine)

[@Jordan-my5gq]

Excellente vidéo ! Attention au montage, tu fais des cuts qui coupent des mots. Je n'apprécie déjà pas trop l'utilisation abusive des cuts mais si en + ça coupe des mots c'est terrible. Et je ne sais pas pourquoi tu as choisi cette photo pour la miniature mais elle est parfaite mdr.

[@codeursenior]

Merci pour ton retour constructif. 👍 Pour le montage, je bricole encore ça à la main. J'envisage d'embaucher un monteur en freelance prochainement pour améliorer la qualité du montage et consacrer plus de temps à la création de contenu de valeur. Bon code à toi ! Simon.

[@Jordan-my5gq]

@@codeursenior La forme peut être améliorée mais le fond est parfait, et c'est le plus important. Un monteur peut être une solution. Je me permet de te dire ce qui pourrait être amélioré dans cette vidéo selon moi : Le son -> Qualité du micro -> Mixage audio L'image -> Moins de cuts (c'est que mon avis et c'est un sujet à débats) -> Attention à ne pas couper les mots -> Laisser un peu + longtemps les extraits de code. J'ai à peine le temps de lire le code, mais pas de le comprendre. Je lis vite mais je comprends lentement car je suis un développeur débutant et je pense que je suis justement la cible de tes vidéos. Il y a toujours la solution de mettre pause à la vidéo (ce que j'ai fait) mais pas très pratique pour un viewer. C'est que mon avis et là je pointe ce que je pense être les défauts de ta vidéo car tu as l'air d'apprécier les retours et pistes d'amélioration mais je répète que je la trouve excellente, le contenu est vraiment top !!

[@codeursenior]

@@Jordan-my5gq Merci pour ton précieux retour. C'est noté pour la suite de consolider ces points ! 👍

[@chulopapi812]

Merci

[@Kihilbill]

Souvent j'utilise If not et ça simplifie le code et diminue l'indentation 😊

[@killerpopholly4054]

La miniature est légendaire 😂

[@codeursenior]

Haha merci ! Je m'amuse comme un fou à prendre en photo les miniatures !

[@pegasusgemini6541]

Pour ceux que ça intéresse : ?? Est appelé coalesce operator

[@codeursenior]

Très bon.

[@AdrienGiboire]

Puisque tu mentionnes le polymorphisme, ça pourrait t'intéresser d'étendre le concept avec le Null Object Pattern. Happy hacking :)

[@etsionchangeaitlemonde3200]

mouai c'est bien mais ça marche pas en C tout ça :')

[@codeursenior]

La vidéo est (très) orientée développement web et JavaScript.

[@quenti7728]

La majorité des élements sont faisable mais faut juste adapter la façons de faire. Exemple le guard clause n'est pas lié à un langage.

[@codeursenior]

@@quenti7728 Merci pour ton retour plus complet. Effectivement, beaucoup de "techniques" ne sont liées à aucun langage en particulier. Bon code !

[@TheodorSirmanoff]

t'es génial. Merci bcp. Je commence le prog language, mais j'aurai ceci en tête. Bcp plus esthétique, sans parler de l'efficacité sur le moment et surtout en cas de besoin de furutre modif du code. Excellent. Juste une précision: l'auteur du livre que tu cites n'est pas Flower, mais Fowler ;)

[@krissclotilde8857]

Je le fais de plus en plus aussi d éliminer les if else

[@A7ka7]

Qu'on se le dise, tout le monde a cliqué pour la miniature.

[@A7ka7]

2eme chose vidéo excellente, c'est ce genre de contenu avec une vraie valeur qu'on aime.

[@codeursenior]

@@A7ka7 "Vraie valeur" 🔥

[@JeremyGasperowicz]

👍

[@codeursenior]

🔥

[@Jol_CodeWizard]

Dans tous les cas où if... else... est plus facile à lire que n'importe quoi d'autre, et à moins que cela puisse se justifier pour des raisons techniques (performance ?) ou théoriques, on garde les if... else... Non ? PS : faut arrêter avec le "syndrome de l'imposteur". Cela n'est normalement jamais un problème de dire qu'on ne sait pas.

[@codeursenior]

Absolument pas d’accord. La performance à la nanoseconde est moins importante que la lisibilité et la maintenabilite du code dans 99% des apps. Et If else n’est pas plus lisible que n’importe quoi d’autre. C’est la solution brute force utilisé par défaut, et rarement la plus optimisé. Le nesting devrait peut etre remplacé par le polymorphisme.

[@Jol_CodeWizard]

@@codeursenior " La performance à la nanoseconde est moins importante que la lisibilité et la maintenabilite du code dans 99% des apps. " Oui. Et au final 99% des devs ne sont bons ni pour l'un ni pour l'autre. " Et If else n’est pas plus lisible que n’importe quoi d’autre. " Oh que si. C'est pourquoi il est si ancien dans les langages de programmation. " C’est la solution brute force utilisé par défaut, et rarement la plus optimisé. " Mais je croyais que dans 99% des cas, l'optimisation passait au second plan ? Un programmeur doit savoir écrire du code "naturellement un peu optimisé", en tout cas au minimum pas stupide sous cet angle-là, et ce sans sacrifier quoi que ce soit à la maintenabilité. Cela implique -- entre des millions d'autres choses -- de savoir dans quels cas l'utilisation de ifs ne posera pas de problème de performance.

[@codeursenior]

@@Jol_CodeWizard Merci pour votre retour peu intéressant.

[@ledganache]

Ce qui serait bien && mieux && bien mieux ce serait carrément d'éliminer 80% du javascript (du moins, dans le web)

[@codeursenior]

Supprimer 80% du web serait bien pour qui ?

[@ledganache]

@@codeursenior _"80% du javascript"_ et pas 80% *du web.* J'imagine que ça ferait du bien aux PC, et probablement aussi à la planète. Les sites étaient bien plus performants, et les navigateurs bien moins gourmands il y a 10 ans de ça, sans les usines à gaz JS.

[@codeursenior]

@@ledganache Intéressant.

[@amaikesdamiennguema5842]

Ca c'est pas pour les débutants. J ai l impression de ne pas suivre

[@codeursenior]

Débutants != Novice

[@JoelCosmono]

10 astuces pour éviter de programmer ...

[@mwlulud2995]

If else: 😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂

[@wanstalker107]

???

[@darkfllame]

if (you don't want to code) { fuck off } else { use if/else statement }

[@recorr]

Cela dit, ça se fait depuis très très longtemps et même si on n'est pas convaincu, il faut connaître ces pratiques pour lire le code d'autrui.

[@darkfllame]

@@recorr en fait, le problème c'est que certains problèmes requièrent les if-else, comme strcmp en C qui check si deux strings song égales, ou même en java, même problème, on peut malheureusement pas utiliser de switch-case, et au final si vous voulez pas utiliser de if-else, je sais pas, codez en assembly mdr

[@donaldthiery3402]

En 6 je ferais plutôt : return user?.isLoggedIn === true; C’est bien plus simple à lire et déterministique que : return !!(user?.isLoggedIn);

[@TheoLeChnow]

ou encore Boolean(user?.isMachin) :)