Super merci, je suis entrain de lire le livre clean code (j’en suis un peu plus de la moitié) et en peu de temps tu as réussi synthétiser pas mal de principes. La règle « description plutôt que concision » est très dur à faire comprendre à d’autre dev qui depuis plusieurs années ont cherché à être le plus concis possible… Ça fait du bien de voir du contenu utile sur youtube.
Je ne suis pas du tout d'accord concernant les commentaires. Ils sont parfois nécessaires et utiles, ne serait-ce que pour baliser certaines sections du code (pour s'y retrouver plus facilement, notamment). Ils peuvent permettre de segmenter et d'aérer le code, de servir de notes quand on a terminé sa journée et qu'on veut se souvenir de ce qu'il y aura à faire le lendemain, c'est utile pour ses collaborateurs actuels et prochains, etc, etc... Les bannir, non. Il faut les utiliser avec parcimonie, oui, forcément.
bannir est peut être un peu fort mais dans Clean Code c'est très bien expliqué. Le code est généralement entretenu et corrigé, amélioré au fil des années... Pas les commentaires, ce qui fait qu'ils deviennent une source de désinformations au fil du temps car le commentaire est resté le même alors que la fonction a été modifié à plusieurs reprises et elle ne réalise plus exactement ce qui a été décrit et c'est là où ca devient très embêtant. Surtout qu'on a tendance à les oublier et à ne plus les lires :S Après oui si c'est un moyen de se souvenir où tu t'es arrêté la veille pourquoi pas, mais ce n'est pas vraiment le rôle d'un commentaire de faire cela mais plutôt d'un bloc note, il me semble
Le problème, c'est qu'il faut souvent opter pour la concision quand il s'agit de nommer des fonctions ou des variables. Parce qu'on ne peut pas faire des phrases à rallonge pour expliquer la nature complexe d'une portion de code. Alors, d'après-moi, il faudra toujours des commentaires et travailler, en revanche, sur la concision de ceux-ci (expliquer en peu de mot ce que réalise telle ou telle section de notre code). Et puis, après, ça dépend de l'état du projet. S'il est en cours, et qu'on passe par des versions alpha, bêta, les commentaires sont plutôt de l'ordre du proofreading/débogage. Il est clair que les codes finaux devraient être les plus épurés et concis possibles.
Un système à utiliser, plutôt que des commentaires simples, c'est l'autodocumentation du code. Ce commentaire s'affiche avec l'autocompletion, et facilite le bon choix des fonctions. Après, pour les commentaires, il FAUT commenter le code de bas niveau. Même bien écrit, celui ci sera abscon parce qu'il demande des connaissances particulières et implique des choix techniques pas toujours évidents.
Vidéo vraiment bien construit, reconnaissante sur le branding de ta chaîne, j'ai beaucoup aimé en plus les principes qui sont peu mis en valeur dans les autres vidéos. Continue comme ça, t'es sur le bon chemin 👍
Tes vidéos sont très cool juste dommage que ça ne s'applique pas au système Camerounais Mais jaime la manière donc tu présente la chose Des idées de projet qui peuvent Marcher dans un pays en développement ??
Intéressant de très bon conseil, cela dit j'émets un petit doute pour les commentaires j'ai tendance à ne pas être d'accord. S'insérer dans un projet de plusieurs milliers de lignes de codes, avec 4/5 développeurs travaillant en parallèle sans commentaires c'est l'enfer. J'en fais les frais aujourd'hui , je perds du temps à lire le code existant (non documenté svp) et c'est frustrant. Je ne prône pas les commentaires inutiles mais les commentaires intelligents, je pense que c'est important parfois. En tout cas excellente vidéo :)
Comme toujours, trop de commentaire ne sert à rien et ca veut dire que le code est mal construit. Pas de commentaire, et à la moindre chose qui n'est immédiatement compréhensible et tu perds un temps fou à remonter le fil. Le commentaire est une chose nécessaire même en solo quand tu veux revenir sur ton projet. Mais il doit être utilisé avec intelligence pour décrire le strict nécessaire. Après, le plus simple est de faire sa doc, ca peut valoir le coup sur certains projet d'y consacrer du temps.
Pour ma part, je pense qu'il est préférable d'écrire les commentaires avant d'écrire des lignes de code. Ainsi, nous voyons si nous sommes au clair avec l'aspect fonctionnel.
3 года назад
Que pensez-vous de mettre un a devant un attribut ex: aInventaire de mettre un p devant un paramètre ex: pInventaire et de mettre un v devant une variable ex: vInventaire ? Me souvient avoir appris ça en cours de POO en java :), mais comme je suis pas dev j'ai pas trop trop d'avis précis la dessus x)
Hello! Alors j’ai déjà entendu parler de cette méthode, ou alors les underscore pour signifier qu’une propriété est privée. Mais je ne trouve pas cette technique très top, parce que pour moi ça n’a pas vraiment d’utilité et ça alourdît le code :)
3 года назад
@@developpeurlibre D'accord ! merci de la réponse ! :)
Dans clean code, l'auteur en parle et il le déconseille car si jamais une des variables n'est plus un attribut mais une variable global ou autre peu importe, tu devras changer le nom de tes variables partout dans ton programme. De plus, mettre une lettre devant ta variable pour préciser d'où elle vient n'a pas d'utilité si tu as bien suivi la règle qu'une fonction, méthode doit faire environ 5 lignes de code car tu retrouveras la définition de ta variable rapidement et le nombre de variables est censé être faible (1 ou 2, au pire 3, comme précisé dans Clean Code)
Ça y est elle sort cette formation ^^ comme on en avais déjà parlé, je ne la prendrai pas. Par contre, vu que tu as un expert web qui travaille avec toi sur les formations, est ce qu'on peut espérer la formation jumelle avec une implémentation web?
@@developpeurlibre perso ça me plairait 👌 l'avantage de votre côté c'est que ça serait plus un refactor qu'une écriture complète. Ça sera moins lourd a faire
Spectateurs, ne croyez surtout pas que ce qu'il vient de lister dans cette vidéo est très facile à appliquer et à maintenir, souvent, dans les projets, il y'a les délais, l'urgence qui vient s'introduire entre les délais, la nature fastidieuse de certaines tâches ... feront en sorte que vous serez amenés, et ce malgré vous, à violer non pas toutes les règles qu'il a énumérées mais bien d'autres. À tout bon entendeur (lecteur :p)
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
J'adore cette vidéo! Plein de principe que je rabâche à longueur de journée!
Je partage sur ma chaine 👍
Merci beaucoup 😉
Merci beaucoup David ! :D
Super merci, je suis entrain de lire le livre clean code (j’en suis un peu plus de la moitié) et en peu de temps tu as réussi synthétiser pas mal de principes.
La règle « description plutôt que concision » est très dur à faire comprendre à d’autre dev qui depuis plusieurs années ont cherché à être le plus concis possible…
Ça fait du bien de voir du contenu utile sur youtube.
Je ne suis pas du tout d'accord concernant les commentaires.
Ils sont parfois nécessaires et utiles, ne serait-ce que pour baliser certaines sections du code (pour s'y retrouver plus facilement, notamment). Ils peuvent permettre de segmenter et d'aérer le code, de servir de notes quand on a terminé sa journée et qu'on veut se souvenir de ce qu'il y aura à faire le lendemain, c'est utile pour ses collaborateurs actuels et prochains, etc, etc...
Les bannir, non. Il faut les utiliser avec parcimonie, oui, forcément.
Totalement d’accord, le terme « bannir » est abusif.
bannir est peut être un peu fort mais dans Clean Code c'est très bien expliqué. Le code est généralement entretenu et corrigé, amélioré au fil des années... Pas les commentaires, ce qui fait qu'ils deviennent une source de désinformations au fil du temps car le commentaire est resté le même alors que la fonction a été modifié à plusieurs reprises et elle ne réalise plus exactement ce qui a été décrit et c'est là où ca devient très embêtant.
Surtout qu'on a tendance à les oublier et à ne plus les lires :S
Après oui si c'est un moyen de se souvenir où tu t'es arrêté la veille pourquoi pas, mais ce n'est pas vraiment le rôle d'un commentaire de faire cela mais plutôt d'un bloc note, il me semble
Le problème, c'est qu'il faut souvent opter pour la concision quand il s'agit de nommer des fonctions ou des variables. Parce qu'on ne peut pas faire des phrases à rallonge pour expliquer la nature complexe d'une portion de code. Alors, d'après-moi, il faudra toujours des commentaires et travailler, en revanche, sur la concision de ceux-ci (expliquer en peu de mot ce que réalise telle ou telle section de notre code). Et puis, après, ça dépend de l'état du projet. S'il est en cours, et qu'on passe par des versions alpha, bêta, les commentaires sont plutôt de l'ordre du proofreading/débogage. Il est clair que les codes finaux devraient être les plus épurés et concis possibles.
Un système à utiliser, plutôt que des commentaires simples, c'est l'autodocumentation du code. Ce commentaire s'affiche avec l'autocompletion, et facilite le bon choix des fonctions.
Après, pour les commentaires, il FAUT commenter le code de bas niveau. Même bien écrit, celui ci sera abscon parce qu'il demande des connaissances particulières et implique des choix techniques pas toujours évidents.
Je ne m'y attendais pas du tout 😅😅
Allez je m'y lance.
Top merci :D C'est la vidéo surprise, pas de leasing sur Instagram cette fois ci :p
@@developpeurlibre Oui je me disais bien que c'était une surprise 😊 ça fait plaisir en tout cas 😉
Vidéo vraiment bien construit, reconnaissante sur le branding de ta chaîne, j'ai beaucoup aimé en plus les principes qui sont peu mis en valeur dans les autres vidéos.
Continue comme ça, t'es sur le bon chemin 👍
Merci beaucoup c’est top ! Vraiment cool d’avoir un retour constructif comme le tien !
Tu fais du bon taf mec continue !
Bonjour. J'arrive à regarder cette vidéo sur le tard. Est-ce que le livre "coder proprement", de Robert C. Martin peut être utile ?
Merci beaucoup pour les conseils😉
Avec plaisir, merci à toi !
Les bases pour tout bon dev !
Merci :D
Nice, une nouvelle video
Yes, merci :D
Merci pour cette vidéo. J'ai une question. Comment améliorer sa productivité dans le freelancing ?
ne pas regarder des vidéos de ce type
Salut. On ne nait pas architecte. Quel chemin nous proposes-tu ?
Je te propose de lire le livre "Clean Code", c'est un super bouqun :D
Un résumé des principes SOLID en informatique
C'est ça :)
Je compte quitter le php et le web ou le mobile avec flutter
Des conseils svp
Hmm je dirais de commencer à apprendre le Flutter via n’importe quel tuto ou via leur site directement
Puis de se lancer sur des projets d’app :)
Tes vidéos sont très cool juste dommage que ça ne s'applique pas au système Camerounais
Mais jaime la manière donc tu présente la chose
Des idées de projet qui peuvent Marcher dans un pays en développement ??
Merci et bonne continuation
Merci, à toi aussi :D
Intéressant de très bon conseil, cela dit j'émets un petit doute pour les commentaires j'ai tendance à ne pas être d'accord.
S'insérer dans un projet de plusieurs milliers de lignes de codes, avec 4/5 développeurs travaillant en parallèle sans commentaires c'est l'enfer.
J'en fais les frais aujourd'hui , je perds du temps à lire le code existant (non documenté svp) et c'est frustrant.
Je ne prône pas les commentaires inutiles mais les commentaires intelligents, je pense que c'est important parfois.
En tout cas excellente vidéo :)
Comme toujours, trop de commentaire ne sert à rien et ca veut dire que le code est mal construit.
Pas de commentaire, et à la moindre chose qui n'est immédiatement compréhensible et tu perds un temps fou à remonter le fil.
Le commentaire est une chose nécessaire même en solo quand tu veux revenir sur ton projet. Mais il doit être utilisé avec intelligence pour décrire le strict nécessaire.
Après, le plus simple est de faire sa doc, ca peut valoir le coup sur certains projet d'y consacrer du temps.
@@Tagadarealty Je partage entièrement ton avis.
Merci d'avoir complétés mes propos .
Pour ma part, je pense qu'il est préférable d'écrire les commentaires avant d'écrire des lignes de code. Ainsi, nous voyons si nous sommes au clair avec l'aspect fonctionnel.
Que pensez-vous de mettre un a devant un attribut ex: aInventaire de mettre un p devant un paramètre ex: pInventaire et de mettre un v devant une variable ex: vInventaire ?
Me souvient avoir appris ça en cours de POO en java :), mais comme je suis pas dev j'ai pas trop trop d'avis précis la dessus x)
Hello! Alors j’ai déjà entendu parler de cette méthode, ou alors les underscore pour signifier qu’une propriété est privée.
Mais je ne trouve pas cette technique très top, parce que pour moi ça n’a pas vraiment d’utilité et ça alourdît le code :)
@@developpeurlibre D'accord ! merci de la réponse ! :)
Dans clean code, l'auteur en parle et il le déconseille car si jamais une des variables n'est plus un attribut mais une variable global ou autre peu importe, tu devras changer le nom de tes variables partout dans ton programme. De plus, mettre une lettre devant ta variable pour préciser d'où elle vient n'a pas d'utilité si tu as bien suivi la règle qu'une fonction, méthode doit faire environ 5 lignes de code car tu retrouveras la définition de ta variable rapidement et le nombre de variables est censé être faible (1 ou 2, au pire 3, comme précisé dans Clean Code)
Quel est le meilleur moyen pour débuter en swifth
Acheter un mac😂😂😂😂
En effet pour se lancer dans le dev iOS il faut un Mac :) Sinon pour débuter il faut apprendre et pratiquer le plus possible
l’introduction au début c’est tout moi
Ça y est elle sort cette formation ^^ comme on en avais déjà parlé, je ne la prendrai pas. Par contre, vu que tu as un expert web qui travaille avec toi sur les formations, est ce qu'on peut espérer la formation jumelle avec une implémentation web?
Hello, actuellement ce n’est pas au programme mais on va en discuter pour voir si on fait une formation jumelle ! :D
@@developpeurlibre perso ça me plairait 👌 l'avantage de votre côté c'est que ça serait plus un refactor qu'une écriture complète. Ça sera moins lourd a faire
La fonction User est un verbe du premier groupe, du coup je comprends pas ... ;-)
Ah mais c’est en anglais haha ^^
Commentaires :
Pourquoi on le fait : oui.
Comment on le fait : non.
Hello, est ce que tu peux préciser un peu ? :)
je le fais tout le temps et apres cest un probleme
Qu’est ce que tu fais tout le temps ? Et en quoi c’est un problème ?
@@developpeurlibre donner des noms bizarres à mes variables et après je sais plus comment je les est nommé.
Spectateurs, ne croyez surtout pas que ce qu'il vient de lister dans cette vidéo est très facile à appliquer et à maintenir, souvent, dans les projets, il y'a les délais, l'urgence qui vient s'introduire entre les délais, la nature fastidieuse de certaines tâches ... feront en sorte que vous serez amenés, et ce malgré vous, à violer non pas toutes les règles qu'il a énumérées mais bien d'autres.
À tout bon entendeur (lecteur :p)
C’est justement ce que je dis dans la vidéo, et la raison pour laquelle j’ai créé une formation.
Esprit
Écrire un commentaire pour dire qu'aucun commentaire est à inscrire dans l'emplacement dudit commentaire
C’était pour l’exemple… 😅
Non, ça ne m'est jamais arrivé 🤣
tu fais caca dans la cuisine toi ??🤣
ta vidéo est très très dure à visionner 🤣🤣
elle est pas très clean 🤣🤣🤣
Tu fais mieux toi ?
@@developpeurlibre bah nan, j'fais pas caca dans la cuisine.
Faire mieux, oui, et ce ne sera pas un exploit 😉
merci pour le cadeau
Avec plaisir ! :D