Share
Nous avons tous nos mauvaises habitudes. Dans cet article, nous allons passer en revue une liste des mauvaises pratiques qu'il convient d'examiner, de réévaluer et de corriger immédiatement..
Tutoriel republiéToutes les quelques semaines, nous revoyons certains des articles préférés de nos lecteurs tout au long de l'histoire du site. Ce tutoriel a été publié pour la première fois en février 2011.
Chaque fois que j'ouvre un projet qui n'est pas le mien, il est effrayé de penser que je vais entrer dans une sorte de scénario du Temple maudit, rempli de pièges, de codes secrets et de cette ligne de code qui modification, fait tomber toute l'application (et envoie peut-être un rocher géant fonçant vers moi dans un couloir étroit).
Quand on a tort et que tout va bien, à part quelques différences mineures dans "comment je l'aurais fait", nous poussons un soupir de soulagement, nous retroussons les manches et nous plonge dans le projet..
Mais quand on a raison… Eh bien, c'est une toute autre histoire.
Notre première pensée en voyant ce gâchis profane est généralement du type "Qui diable pense ce mec?" Et à juste titre; quel genre de programmeur créerait volontiers un tel gâchis impie d'un projet?
Awful Code est l'accumulation de multiples petits raccourcis ou concessions..
Votre premier instinct pourrait être de supposer que le gars qui a construit le projet est un novice, ou peut-être qu'il est juste un idiot. Mais ce n'est pas toujours le cas.
Ma théorie est que le code horrible est l’accumulation de multiples petits raccourcis ou concessions - aussi souvent que c’est le produit de l’inexpérience ou de la stupidité. Cela rend l'application Temple of Doom beaucoup plus effrayante, car celui qui l'a construite peut être aussi intelligent, averti et lu que vous l'êtes. Ils sont juste devenus paresseux ou ont mis les choses en place à la hâte, et chacun de ces petits raccourcis s’est ajouté au cauchemar sinueux qui vient de tomber sur vos genoux..
Encore plus effrayant, cela pourrait signifier qu’à un moment donné, quelqu'un a hérité de votre code et a immédiatement fondu en larmes..
Il est toujours utile de réexaminer vos pratiques actuelles et de vous assurer que vous ne prenez pas de raccourcis qui pourraient contribuer au sommeil perdu de quelqu'un.
Prenons quelques minutes et passons en revue certains raccourcis, concessions et autres mauvaises pratiques courants afin de nous assurer que nos projets ne font pas peur aux villageois..
Avant d'écrire une seule ligne de code, vous devez avoir un plan d'attaque solide..
Avant d'écrire une seule ligne de code, vous devez avoir un plan d'attaque solide. Cela vous permet de rester sur la bonne voie et d’éviter les codes errants qui vous troubleront plus tard, sans parler de quelque autre pauvre âme..
Une approche qui m'a permis de gagner du temps - à la fois dans le développement et dans les commentaires - consiste à écrire d'abord un aperçu dans les commentaires:
Comme vous pouvez le constater, sans écrire une seule ligne de code, je sais déjà à quoi ressemble exactement le fichier. Le meilleur de tous, vous pouvez planifier une application entière de cette façon, et si vous arrivez à un point où une fonctionnalité nécessite un ajustement de fonctionnalité à une autre, il suffit de changer le commentaire.
Cela nécessite un changement d'approche dans votre approche du développement, mais cela mettra vos compétences d'organisation du projet à rude épreuve.
REMARQUE: Certains de ces commentaires ne sont pas nécessaires; certains d'entre eux vont changer; d'autres devront être ajoutés - c'est prévu. C'est un peu comme écrire un plan pour un papier ou écrire une liste d'épicerie: cela vous permet de rester sur la bonne voie lorsque vous allez finir le travail..
Vous ne commentez rien
Pourtant, le problème le plus grave que je rencontre avec la plupart des codes est qu’il est mal commenté ou pas du tout commenté..
Cela me rend triste de devoir écrire cela. Quand quelque chose est aussi facile que de commenter, cela ne devrait pas être quelque chose que nous devons nous rappeler mutuellement de faire..
Pourtant, le problème avec la plupart des codes que je rencontre est qu’il est mal commenté, ou pas du tout. Cela ne prend pas seulement beaucoup de temps à ma familiarisation initiale avec le projet, mais cela garantit quasiment qu’un correctif réalisé par une méthode non conventionnelle par nécessité va me confondre. Ensuite, si je finis une refactorisation, je casserai l'application par inadvertance, car je n'ai pas rencontré les circonstances atténuantes qui ont nécessité la correction..
Ce processus peut durer de 10 minutes à 6 heures. (Et vous m'avez fait ça, je sais où vous habitez. Je viens pour vous.)
Alors dis ceci à haute voix:
je, [Donnez votre nom], par la présente jure de faire des commentaires dans toutes les situations où le but du code que j'ai écrit n'est pas immédiatement apparent.
"Immédiatement apparent" fait référence à un code qui ne peut pas être auto-documenté (car il ne serait pas raisonnable de le faire) et / ou ne termine pas une tâche extrêmement simple. Pensez-y de cette façon: si vous deviez vous arrêter et réfléchir à votre solution plus de quelques secondes, elle mériterait probablement une petite explication..
Pour illustrer mon propos, je vais utiliser un exemple tiré d'un article que j'ai écrit récemment pour les débutants. Considérer ce qui suit:
$ pieces = exploser ('.', $ nom_image); $ extension = array_pop ($ pieces);Qu'est-ce que ça fait? Avez-vous eu à vous arrêter et à y penser? Vous ne savez toujours pas avec certitude ce qui est stocké dans $ extension?
Regardez à nouveau cet extrait, mais avec un bref commentaire:
// Récupère l'extension de l'image nomfichier $ pieces = explode ('.', $ Nom_image); $ extension = array_pop ($ pieces);Cinq secondes à la fois vont s'additionner.
Maintenant, jeter un coup d'œil à ce code ne nécessite pas de puissance cérébrale supplémentaire: vous voyez le commentaire, vous voyez le code et vous n'avez jamais à remettre en question son intention.
Cela vous évitera peut-être cinq secondes de réflexion, mais si vous avez une application complexe, cinq secondes à la fois vous rapporteront beaucoup..
Alors arrêtez de faire des excuses. Ecrire le foutu commentaire.
Vous sacrifiez la clarté pour la brièveté
Parmi les bons exemples de perte de clarté au profit de la brièveté, citons les noms de variables peu clairs et la suppression des accolades.
C'est une tentation universelle de faire quelque chose avec le moins de caractères possible, mais cette tentation est un peu comme la tentation de n'avoir qu'un seul sous-vêtement: bien sûr, le linge est fait rapidement, mais les problèmes qui découlent de votre choix extrêmement l'emporte sur les avantages.
Parmi les bons exemples de perte de clarté au profit de la brièveté, citons les noms de variables courts et peu clairs (tels que
$ a- qu'est-ce que$ astocker?) et laisser tomber les accolades.Laisser tomber des accolades des structures de contrôle est une bête noire de ma famille. Si vous n'aimez pas les accolades, passez en Python. En PHP, il est trop facile de perdre le sens sans eux.
Par exemple, examinez cet ensemble d'instructions if-else imbriquées sans accolades:
5) echo "Supérieur à 5!" sinon echo "Moins de 5!"; sinon echo "Supérieur à 10!"; écho "
Une autre note. ";En bref, il semble que la dernière ligne ne devrait être déclenchée que si la valeur de
$ fooest supérieur à 10. Mais ce qui se passe réellement est un cas d'indentation inappropriée; la dernière déclaration d'écho va tirer quoi qu'il arrive$ foomagasins.Pouvez-vous comprendre si vous le regardez pendant quelques secondes et sachez que les déclarations if-else sans accolades affectent uniquement la ligne suivante immédiate? Bien sûr.
Si vous deviez gaspiller l’énergie pour le comprendre? Absolument pas.
L'ajout d'accolades ajoute quelques lignes, mais cela clarifie énormément la déclaration, même avec l'indentation étrange:
5) echo "Supérieur à 5!"; else echo "Moins de 5!"; else echo "Supérieur à 10!"; écho "
Une autre note. ";Oui, c'est une bonne chose de garder votre code concis, mais pas au détriment de la clarté. Cela vaut la peine de prévoir des lignes supplémentaires pour que personne ne se cogne la tête contre un clavier qui tente de passer au crible votre code.
Vous ne suivez pas une norme de codage
Choisissez un standard et respectez-le.
Être mignon avec votre formatage peut satisfaire vos envies artistiques, mais cela ne sert à rien. Choisissez une norme (je recommande la norme de codage PEAR) et respectez-la. Tout le monde va vous remercier. (Vous y compris, un jour.)
Croyez-moi. J'étais ce type une fois - je voulais avoir un "style de signature" - et j'ai perdu beaucoup d'heures à réparer mon formatage atroce par la suite. Il y a un temps pour être différent et un temps pour le faire comme tout le monde.
En matière de programmation, considérez-le comme une langue parlée. La grammaire et la ponctuation existent pour une raison: nous pouvons donc nous comprendre clairement lorsque nous écrivons. Pensez à des normes de codage comme une version geek des Elements of Style de Strunk & White. En suivant les instructions, les gens comprendront ce que vous essayez de dire, sans pour autant être ennuyeux..
Vous dupliquez le code
Vous le faites mal.
Essayez de regarder chaque élément de votre application comme quelque chose qui devra changer à un moment donné. Si tel est le cas, devrez-vous mettre à jour plusieurs fichiers? Si vous avez répondu oui, il est temps de réévaluer la manière dont vous écrivez le code..
Si le code fait la même chose à plus d'un endroit dans votre application, vous le faites mal.
Vous ne suivez pas un modèle de développement
Vous devriez toujours avoir une structure lorsque vous codez.
Vous devriez toujours avoir une structure lorsque vous codez. Je ne veux pas dire que vous devez suivre le modèle MVC ou quelque chose d'aussi rigide, mais je veux dire que vous devez savoir comment classer les composants et savoir où ils doivent aller..
En suivant un modèle de développement logique, de nombreuses décisions deviennent automatiques, et une personne entrant dans votre code n'a pas à en deviner beaucoup lorsqu'elle recherche une certaine fonctionnalité dans votre base de code..
Cela ne prend pas longtemps, et cela clarifiera vraiment vos applications.
Vous êtes trop malin pour votre bien
La solution la plus simple est généralement la plus appropriée
Il y a une différence entre une solution astucieuse et une solution compliquée.
Il est toujours tentant d'essayer un nouveau truc doux que vous avez appris, mais nous devons résister à l'envie de forcer une solution complexe dans un espace où un simple suffit..
Au niveau de base, la solution la plus simple est généralement la plus appropriée. Vous essayez d'obtenir de point A à point B - faire un détour point génial est amusant, mais n'apporte vraiment aucun avantage.
Votre solution super-douce pose cependant un problème dans lequel quelqu'un d'autre peut ne pas avoir vu cette solution particulière et va juste se perdre. Ce n'est pas non plus parce qu'ils ne sont pas aussi intelligents que vous; c'est probablement parce qu'ils n'ont pas vu cet article en particulier ou n'essayaient pas de forcer un concept carré à un problème rond.
Ne vous engourdissez pas, mais rappelez-vous d'éviter de trop compliquer les choses "juste parce que".
Vous êtes un wang
Évitez de rendre votre code difficile à comprendre à tout prix.
Lorsque j'ai commencé à travailler dans le développement, j'ai travaillé avec un gars qui était un programmeur auto-proclamé "expert". Chaque fois que j'ai eu une question sur un concept, il ne m'a jamais donné une réponse directe; afin d'obtenir la réponse à ma question initiale, je devais répondre à quelques questions préliminaires afin de "prouver que vous pouviez gérer la réponse".
Ce gars était aussi très bon pour écrire du code cryptique, obscurci et déroutant..
Des fichiers comme le sien sont le résultat de programmeurs qui pensent qu’ils ont besoin de rendre leur code difficile à lire afin de "garder les idiots à l’écart".
La philosophie générale derrière ceci est généralement la suivante: "Si vous n'êtes pas assez intelligent pour comprendre ce code, vous ne devriez pas y être déjà."
Il s’agit d’une approche profondément erronée et antisociale en matière de programmation. C'est une façon très élitiste de voir les choses, et cela montre que le programmeur a perdu le contact avec ses racines débutantes, alors qu'il avait lui-même besoin d'aide.
Évitez de rendre votre code difficile à comprendre à tout prix. Cela ne vous rend pas plus cool ou plus intelligent, et cela ne renforce pas le respect. Ça fait de toi un wang.
Mec, de quoi tu parles?
Si vous arrêtez d'apprendre, les projets sur lesquels vous travaillez sont bloqués quelle que soit la période que vous avez décidé de régler..
En plus des raccourcis et de la paresse générale décrits ci-dessus, une autre chose qui pourrait vous freiner est le manque d'apprentissage continu et de progrès.
La technologie ne change pas parce que la communauté en général s'ennuie et nous avons décidé de redécorer; la plupart des nouvelles technologies émergent pour résoudre plus efficacement et facilement les problèmes existants. Choisir d'ignorer les progrès, c'est choisir de commencer le lent processus de marginalisation de vos compétences.
Voici quelques choses que nous pouvons tous arrêter de faire pour nous assurer que nos compétences sont à jour, sans devoir abandonner nos week-ends..
Vous essayez de le faire vous-même
Découvrez lesquels de ces programmeurs ont une approche similaire et laissez-les vous renseigner sur les grandes nouvelles.
Vous ne pouvez pas suivre toute la communauté. Comme tous ceux qui ont déjà essayé de suivre un abonnement à plus de 200 blogs techniques vous le diront, cela ne peut tout simplement pas être fait dans un délai raisonnable..
Heureusement, certains membres de la communauté consacrent leur temps à surveiller l'évolution de la technologie et à rendre compte de leurs résultats. Si vous prenez le temps de découvrir lequel de ces programmeurs a une approche et un style similaires, vous pouvez les laisser vous renseigner sur la grande nouvelle.
Il peut être plus bénéfique de regarder 2 à 5 de ces blogueurs de type "adopteur précoce" que de s'abonner à tous les blogs technologiques que vous rencontrez pour plusieurs raisons:
David Walsh et Chris Shiflett sont parmi les blogueurs PHP..
Je veux simplement suggérer que vous serez plus épanoui en tant que programmeur et que vos talents progresseront de plus en plus si vous choisissez de toujours regarder au prochain niveau de programmation..
Si vous ne faites pas quelque chose qui vous met au défi, quelque chose ne va pas. Trouver de nouveaux défis dans les projets est ce qui rend la programmation enrichissante (ou du moins ça devrait l'être).
Essayez de vous poser les questions suivantes lorsque vous commencez à regarder de nouveaux projets:
Gardez à l'esprit: je ne parle pas de faire des choses extrêmement complexes, ici.
Cela peut être aussi simple que de penser à ajouter des Docblocks à vos objets, ou complexe, de rendre votre application compatible avec XMLRPC afin que les utilisateurs puissent publier plus facilement des mises à jour..
Essayez simplement de ne pas vous installer et de vous convaincre d'avoir appris tout ce que vous allez apprendre. C'est à ce moment-là que ça va devenir moche pour toi.
Discutez toujours de votre code avec vos collègues programmeurs.
Le meilleur moyen d’améliorer consiste à discuter de votre code avec vos collègues programmeurs. Cela peut être fait de différentes manières: si vous vous sentez particulièrement sociable, écrivez un tutoriel ou publiez un projet open-source; Si vous ne vous sentez pas à la hauteur de cette envergure, vous pourriez peut-être sortir sur un forum communautaire et offrir de l'aide aux nouveaux arrivants..
"Comment aider les noobs à m'aider à progresser?" tu demandes. Habituellement, si vous publiez une solution qui pourrait être optimisée, d’autres programmeurs expérimentés s’engageront et proposeront des améliorations. Cette approche est donc un double choc de génialité: vous aidez non seulement à faire progresser la communauté en offrant vos connaissances aux débutants, mais vous perfectionnez vos propres compétences en accroissant vos capacités à tout le monde et à vous aider à développer..
Si vous voulez entrer dans quelque chose de nouveau et de cool qui est un peu trop impliqué pour être mis dans un vrai projet, la meilleure façon d'apprendre est de démarrer un projet parallèle qui utilise ladite technique..
De cette façon, vous pourrez progresser à votre rythme, pendant votre temps libre, et ne jamais risquer de manquer une échéance ou de "faire les choses mal".
Si nous le faisons bien, nous devrions toujours nous améliorer. Et la logique nous dit que si nous sommes meilleurs maintenant, alors nous étions pires avant. Et si nous suivons cette ligne de raisonnement assez loin en arrière, il y avait un point où nous étions terribles.
Je sais que quand je regarde en arrière certains des codes que j'ai écrits dans le passé, je suis horrifié.
Nous ne serons jamais parfaits. Mais nous pouvons faire tout ce qui est en notre pouvoir pour nous assurer de nous rapprocher le plus possible..
Quelles sont vos marottes en ce qui concerne le code d'autres développeurs? Faites-moi savoir dans les commentaires!
Accentsconagua