Franchement je suis Encore à un niveau très basique mais je sais déjà qu'il faut avoir le code le plus optimisé et lisible possible donc merci de nous partager ça 👍💪
@@tokie1294 tu troll? Dans un code tu auras toujours des refactos/amélioration à faire mais de la à dire qu'il ne faut pas suivre les bonnes pratiques..
Merci de l'astuce, c'est bien expliqué 👍 D'ailleurs, je me demande si pour les procédures on peut remplacer les 'return' par des 'break' pour skip les autres cas ?
C'est une bonne solution. Mais attention avec ce genre de pratiques, en particulier avec les langages faiblement (ou non) typés. Exemple en python : a = 10 if (a): return "ok" Va retourner un "ok". Mais, if(!a): return "ok" Va throw une SyntaxError... Attention également d'un point de vue sécurité, si vous zappé un return ou un "!", vous pourriez ne pas vous en rendre compte et ouvrir une console admin à un user non privilégié. Et ça va passer silencieusement ! Il ne faut pas oublier que l'esprit humain fonctionne mal avec les négations. Bref, un bon outil, mais toujours penser : lisibilité > beauté > nesting.
Je suis assez géner car normalement dans les bonnes pratiques ont dois avoir qu'un return. Comme le code fais toujours la même chose un tableau contenant la condtion + l'erreur serais plus pertinant avec un break pour mettre fin au for si erreur.
Ce pattern dépends du language (notamment en C) , de la fonction et du besoin recherché. En python et JS cela est fortement utilisé. C'est un exemple simple ici et concernant ton tableau, il ne suit aucune norme et ne serait pas maintenable dans une grande imbrication ( suffit juste de loger une action entre islogin et isadmin)
@@axelcode_exe merci,, pour cette précision je suis plus habitué au rust et le c. Et l'utilisation de plusieurs return est fortement déconseillé dans ces langages.
@@elie_silva avec plaisir, oui dans ces langages les early return sont déconseillés. Si tu utilise ce pattern en C, il faut faire attention à la libération de mémoire ect
@@axelcode_exe @elie_silva tu peux tenter un truc dans ce style : function anyFunction() { if( canContinue() ) { showAdminPanel() } } ca te permet d'eviter les early return mais en gardant ta fonction plus legere. Ton canContinue va servir a log. D'ailleurs le early retrun t'empeche de loger toutes les erreurs (si tu veux voir en meme temps si il n'est ni log ni admin)
Non, tu ne peux pas car chaque if effectue une action ( et dans un cas plus complet il pourrait y avoir des actions entre les if comme la dernière action)
Je suis développeur depuis peu j'ai découvert ta chaine ce matin avec tes shorts j'aime beaucoup ton contenu simple et bien expliqué merco !
@@moshodai Merci ça fait plaisir !
Franchement je suis Encore à un niveau très basique mais je sais déjà qu'il faut avoir le code le plus optimisé et lisible possible donc merci de nous partager ça 👍💪
Avec plaisir , oui si tu part sur de bonnes bases tu sera au top 👌
Grosse erreur de vouloir optimiser son code, surtout quand on est débutant ! C'est vraiment la derniere derniere chose à faire !
@@tokie1294 tu troll? Dans un code tu auras toujours des refactos/amélioration à faire mais de la à dire qu'il ne faut pas suivre les bonnes pratiques..
Merci de l'astuce, c'est bien expliqué 👍
D'ailleurs, je me demande si pour les procédures on peut remplacer les 'return' par des 'break' pour skip les autres cas ?
Merci !
Pour les break tu peux dans les conditions / boucle mais avec ce pattern tu ne peux pas remplacer les return par des break
Excellente vidéo, continue comme ça ! je m'abonne
Merci beaucoup !
Merci pour le partage, je l'utilisait déjà mais je ne savais pas que c'était un pattern
Avec plaisir !
C'est une bonne solution.
Mais attention avec ce genre de pratiques, en particulier avec les langages faiblement (ou non) typés.
Exemple en python :
a = 10
if (a): return "ok"
Va retourner un "ok".
Mais,
if(!a): return "ok"
Va throw une SyntaxError...
Attention également d'un point de vue sécurité, si vous zappé un return ou un "!", vous pourriez ne pas vous en rendre compte et ouvrir une console admin à un user non privilégié. Et ça va passer silencieusement ! Il ne faut pas oublier que l'esprit humain fonctionne mal avec les négations.
Bref, un bon outil, mais toujours penser : lisibilité > beauté > nesting.
Exactement, à adapter selon le language comme tout pattern !
Je suis assez géner car normalement dans les bonnes pratiques ont dois avoir qu'un return. Comme le code fais toujours la même chose un tableau contenant la condtion + l'erreur serais plus pertinant avec un break pour mettre fin au for si erreur.
Euh il présente un pattern la tu es entrain d'inventer ta propre 'norme' qui va stocker des objets inutilements
Ce pattern dépends du language (notamment en C) , de la fonction et du besoin recherché. En python et JS cela est fortement utilisé.
C'est un exemple simple ici et concernant ton tableau, il ne suit aucune norme et ne serait pas maintenable dans une grande imbrication ( suffit juste de loger une action entre islogin et isadmin)
@@axelcode_exe merci,, pour cette précision je suis plus habitué au rust et le c. Et l'utilisation de plusieurs return est fortement déconseillé dans ces langages.
@@elie_silva avec plaisir, oui dans ces langages les early return sont déconseillés.
Si tu utilise ce pattern en C, il faut faire attention à la libération de mémoire ect
@@axelcode_exe @elie_silva tu peux tenter un truc dans ce style :
function anyFunction() {
if( canContinue() ) {
showAdminPanel()
}
}
ca te permet d'eviter les early return mais en gardant ta fonction plus legere. Ton canContinue va servir a log.
D'ailleurs le early retrun t'empeche de loger toutes les erreurs (si tu veux voir en meme temps si il n'est ni log ni admin)
Est ce qu'on pourrait faire mieux en mettant les conditions des trois dans un seul du genre if(!Login or !isAdmin...)
Non, tu ne peux pas car chaque if effectue une action ( et dans un cas plus complet il pourrait y avoir des actions entre les if comme la dernière action)
Un discord ça vient ouuu ???
Ça va venir le s 😁
Merci veineux du ch..😂
Tu fais partie de la team 😂