Quelles «bonnes pratiques» populaires ne sont pas toujours les meilleures et pourquoi? [fermé]

Les "meilleures pratiques" sont omniprésentes dans notre secteur. Une recherche Google sur les "meilleures pratiques de codage" donne près de 1,5 million de résultats. L'idée semble apporter du réconfort à beaucoup; Il suffit de suivre les instructions et tout ira bien.

Lorsque je lis une bonne pratique - par exemple, je viens de lire plusieurs articles récemment dans Clean Code - je suis nerveuse. Est-ce que cela signifie que je devrais toujours utiliser cette pratique? Y at-il des conditions attachées? Y a-t-il des situations où cela pourrait ne pas être une bonne pratique? Comment puis-je savoir avec certitude jusqu'à ce que j'en ai appris davantage sur le problème?

Plusieurs des pratiques mentionnées dans Clean Code ne me convenaient pas, mais honnêtement, je ne sais pas si c'est parce qu'elles sont potentiellement mauvaises, ou si ce sont juste mes préjugés personnels. Je sais que de nombreuses personnalités du secteur des technologies semblent penser qu’il n’ya pas de meilleures pratiques , alors au moins mes doutes persistants me placent en bonne compagnie.

Le nombre de bonnes pratiques que j'ai lues est tout simplement trop important pour être énuméré ici ou poser des questions individuelles, aussi j'aimerais reformuler cette question en une question générale:

Quelles pratiques de codage communément qualifiées de "meilleures pratiques" peuvent être sous-optimales, voire nuisibles dans certaines circonstances? Quelles sont ces circonstances et pourquoi rendent-elles la pratique pauvre?

Je préférerais entendre parler d’exemples et d’expériences spécifiques.

Je pense que vous avez frappé le clou avec cette déclaration

Je détesterais prendre les choses pour argent comptant et ne pas y penser de façon critique

J'ignore presque toutes les meilleures pratiques sans explications sur les raisons de leur existence

Raymond Chen le dit le mieux dans cet article quand il dit

Un bon conseil vient avec une justification afin que vous puissiez dire quand cela devient un mauvais conseil. Si vous ne comprenez pas pourquoi quelque chose devrait être fait, alors vous êtes tombé dans le piège de la programmation culte du fret, et vous continuerez à le faire même quand ce n'est plus nécessaire ou même devient nuisible.

On pourrait aussi bien jeter ceci dans le ring:

Premature optimization is the root of all evil.

Non ce n'est pas.

La citation complète:

"Nous devrions oublier les petites économies, disons environ 97% du temps: l'optimisation prématurée est la racine de tous les maux. Cependant, nous ne devrions pas laisser passer nos opportunités dans ces 3% critiques."

Cela signifie que vous tirez parti d' améliorations de performances stratégiques spécifiques tout au long de votre processus de conception. Cela signifie que vous utilisez des structures de données et des algorithmes compatibles avec les objectifs de performance. Cela signifie que vous êtes conscient des considérations de conception qui affectent les performances. Mais cela signifie également que vous n'optimisez pas de manière frivole, car vous obtiendrez des gains mineurs au détriment de la maintenabilité.

Les applications doivent être bien architecturées, pour ne pas tomber à la fin lorsque vous leur appliquez une petite charge, puis vous les réécrivez. Le danger de la citation abrégée est que, trop souvent, les développeurs l'utilisent comme excuse pour ne pas penser à la performance du tout jusqu'à la fin, alors qu'il est peut-être trop tard pour faire quoi que ce soit. Mieux vaut construire dès le départ de bonnes performances, à condition de ne pas se focaliser sur les détails.

Supposons que vous construisez une application en temps réel sur un système intégré. Vous choisissez Python comme langage de programmation, car "l'optimisation précoce est la racine de tout mal". Maintenant , je n'ai rien contre Python, mais il est un langage interprété. Si la puissance de traitement est limitée et qu'un certain volume de travail doit être effectué en temps réel ou quasi réel, et que vous choisissez une langue qui nécessite plus de puissance de traitement que le travail que vous avez, vous êtes royalement bousillé. Il faut maintenant recommencer avec un langage capable.

Un retour par fonction / méthode.

Ne pas réinventer la roue est un dogme largement mal utilisé. Son idée est que si une solution appropriée existe, utilisez-la au lieu de créer la vôtre; outre les efforts d’économie, la solution existante est probablement mieux mise en œuvre (sans bug, efficace, testée) que ce que vous auriez proposé au départ. Jusqu'ici tout va bien.

Le problème est qu’il existe rarement une solution adaptée à 100%. Une solution appropriée à 80% pourrait exister, et son utilisation est probablement satisfaisante. Mais qu'en est-il de 60%? 40%? Où tracez-vous la ligne? Si vous ne tracez pas la ligne, vous risquez d'incorporer une bibliothèque saturée à votre projet, car vous utilisez 10% de ses fonctionnalités, simplement parce que vous souhaitez éviter de "réinventer la roue".

Si vous réinventez la roue, vous obtiendrez exactement ce que vous voulez. Vous apprendrez également à fabriquer des roues. Apprendre en faisant ne devrait pas être sous-estimé. Et à la fin, une roue personnalisée pourrait bien être meilleure qu'une roue générique standard.

"Tout tester."

J'ai souvent entendu dire que tous les codes devraient comporter des tests unitaires, ce sur quoi je suis en désaccord. Lorsque vous testez une méthode, toute modification apportée à la sortie ou à la structure de cette méthode doit être effectuée deux fois (une fois dans le code, une fois dans le test).

En tant que tel, les tests unitaires devraient, à mon avis, être proportionnels à la stabilité structurelle du code. Si j'écris un système en couches de bas en haut, ma couche d'accès aux données aura des tests sur le wazoo; ma couche de logique métier sera assez bien testée, ma couche de présentation comportera des tests et mes vues seront peu ou pas testées.

Toujours programmer pour les interfaces.

Parfois, il n'y aura qu'une seule implémentation. Si nous retardons le processus d'extraction d'une interface jusqu'au moment où nous en voyons le besoin, nous constaterons souvent que ce n'est pas nécessaire.

N'utilisez rien de code source ouvert (ou non-Microsoft pour vos développeurs .NET)

Si Microsoft ne l'a pas développé, nous ne l'utilisons pas ici. Vous souhaitez utiliser ORM - EF, vous souhaitez utiliser IOC - Unity, vous souhaitez vous connecter - le bloc d'application de journalisation d'entreprise. Il existe de nombreuses bibliothèques de meilleure qualité - et pourtant, je suis toujours coincé dans le menu des dollars du monde du développement. Je jure chaque fois que j'entends les meilleures pratiques de Microsoft que je pense aux "directives nutritionnelles de McDonald's". Bien sûr, vous vivrez probablement si vous les suivez, mais vous serez également mal nourri et en surpoids.

• Notez que ceci n’est peut-être pas votre meilleure pratique, mais c’est une pratique courante suivie presque partout où j’ai travaillé.

Orientation d'objet

Il y a l'hypothèse, juste parce que le code est "orienté objet", c'est magiquement bon. Les gens insèrent donc des fonctionnalités dans des classes et des méthodes, juste pour être orientés objet.

Tout le code doit être commenté.

Non, ça ne devrait pas l'être. Certaines fois, vous avez du code évident, par exemple les setters ne doivent pas être commentés, jusqu'à ce qu'ils fassent quelque chose de spécial. Aussi, pourquoi devrais-je commenter ceci:

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

Méthodologies, particulièrement scrum. Je ne peux pas garder un visage impassible quand j'entends les adultes utiliser la phrase "Scrum Master". J'en ai tellement marre d'entendre les développeurs protester contre certains aspects de Methodology X qui ne fonctionnent pas pour leur entreprise. Seul un gourou m'a dit que cela ne fonctionnait pas parce qu'ils ne sont pas, en fait, de véritables praticiens. de la Méthodologie X. "Scrum Hard, vous devez, mon apprenant Padawan!"

Il existe de nombreuses pépites de sagesse dans les méthodologies agiles - beaucoup d'entre elles - mais elles sont souvent formées dans tellement de fumier que je ne peux pas combattre mon réflexe nauséeux. Prenez ce bit de la page Scrum de Wikipedia :

Un certain nombre de rôles sont définis dans Scrum. Tous les rôles appartiennent à deux groupes distincts - porcs et poulets - en fonction de la nature de leur implication dans le processus de développement.

Vraiment? Porcs et poulets, vous dites? Fascinant! J'ai hâte de présenter celui-ci à mon patron ...

Cartographie relationnelle d'objet ... http://en.wikipedia.org/wiki/Object-relational_mapping

Je ne veux jamais être isolé de mes données, ni perdre ce contrôle et cette optimisation précis. Mon expérience avec ces systèmes a été extrêmement médiocre ... Les requêtes générées par ces couches d'abstraction sont encore pires que celles que j'ai pu voir en délocalisation.

Écrire les noms de fonctions comme s'il s'agissait de phrases anglaises:

Draw_Foo()
Write_Foo()
Create_Foo()

etc. Cela peut sembler génial, mais c'est une douleur lorsque vous apprenez une API. À quel point est-il plus facile de rechercher un index pour "Tout ce qui commence par Foo"?

Foo_Draw()
Foo_Write()
Foo_Create()

etc.

MVC - Je trouve souvent que résoudre de nombreux problèmes de conception Web dans l'approche MVC consiste davantage à rendre un framework (rails, etc.) plus agréable que la simplicité ou la structure. MVC est un favori des "astronautes de l'architecture" qui semblent privilégier les échafaudages excessifs par rapport à la simplicité. ymmv.

OO basé sur la classe - à mon avis encourage les structures complexes de l'état mutable. les seuls cas convaincants que j'ai trouvés pour OO basé sur les classes au fil des ans sont les exemples "forme-> rectangle-> carré" ringards qui forment le chapitre 1 de n'importe quel livre OO

YAGNI

( Vous n'en aurez pas besoin )

Cette approche m'a coûté des heures et des heures lorsque j'ai dû implémenter des fonctionnalités sur une base de code existante, où une planification minutieuse aurait préalablement inclus ces fonctionnalités.

Certaines de mes idées ont souvent été rejetées à cause de YAGNI, et la plupart du temps, quelqu'un devait payer pour cette décision plus tard.

(Bien sûr, on pourrait affirmer qu'une base de code bien conçue permettrait également d'ajouter des fonctionnalités ultérieurement, mais la réalité est différente)

Pour SQL

1. Ne pas utiliser de déclencheurs
2. Toujours masquer les tableaux derrière les vues

En ordre:

1. Ils sont une caractéristique qui a sa place. Vous avez plusieurs chemins de mise à jour vers une table ou avez besoin d'un audit à 100%?

2. Juste pourquoi? Je le ferais si je refactaisais pour maintenir un contrat, mais pas après avoir lu que les gens modifiaient la vue pour correspondre aux changements de table

Modifier:

Numéro 3: Éviter * avec EXISTS. Essayez 1/0. Ça marche. La liste de colonnes n'est pas évaluée selon le standard SQL. Page 191

Modèles de conception principalement. Ils sont trop utilisés et sous-utilisés.

Le principe de responsabilité unique

^{("chaque classe ne devrait avoir qu'une seule responsabilité; en d'autres termes, chaque classe devrait avoir une et une seule raison de changer")}

Je ne suis pas d'accord. Je pense qu'une méthode ne doit avoir qu'une raison de changer et que toutes les méthodes d'une classe doivent avoir une relation logique entre elles , mais la classe elle-même peut en réalité faire plusieurs choses (liées).

D'après mon expérience, ce principe est trop souvent appliqué avec trop de zèle et vous aboutissez à de nombreuses petites classes à une méthode. Les deux magasins agiles où j'ai travaillé l'ont fait.

Imaginez si les créateurs de l'API .Net avaient eu ce genre de mentalité: plutôt que List.Sort (), List.Reverse (), List.Find (), etc., nous aurions des classes ListSorter, ListReverser et ListSearcher!

Plutôt que de me disputer davantage contre le PÉR (qui en soi n’est pas terrible en théorie) , je vais partager quelques-unes de mes longues expériences anecdotiques:

À un endroit où j’ai travaillé, j’ai écrit un solveur de flux max très simple composé de cinq classes: un nœud, un graphe, un créateur de graphes, un solveur de graphes et une classe permettant d’utiliser les créateurs / solveurs de graphes pour résoudre un problème. problème du monde réel. Aucun n'était particulièrement complexe ou long (le solveur était de loin le plus long à environ 150 lignes). Cependant, il a été décidé que les classes avaient trop de «responsabilités», alors mes collègues se sont mis à la refactorisation du code. Quand ils ont fini, mes 5 classes ont été étendues à 25 classes, dont le nombre total de lignes de code était plus du triple de ce qu’elles étaient à l’origine. Le flux du code n'était plus évident, pas plus que l'objectif des nouveaux tests unitaires; J'avais maintenant du mal à comprendre ce que mon propre code faisait.

Au même endroit, presque toutes les classes n’avaient qu’une seule méthode (sa seule "responsabilité"). Suivre le déroulement du programme était presque impossible, et la plupart des tests unitaires consistaient à vérifier que cette classe appelait du code provenant d' une autre classe , dont le but était également un mystère pour moi. Il y avait littéralement des centaines de classes où il aurait fallu (IMO) seulement des dizaines. Chaque classe ne faisait qu'une "chose" , mais même avec des conventions de nommage telles que "AdminUserCreationAttemptorFactory" , il était difficile de dire la relation entre les classes.

À un autre endroit (qui avait également la mentalité classes-devrait-avoir-seulement-une-méthode ), nous essayions d'optimiser une méthode qui prenait 95% du temps au cours d'une certaine opération. Après (plutôt bêtement) l’optimiser un peu, j’ai tourné mon attention vers pourquoi on l’appelait des bajillions de fois. Il était appelé dans une boucle d'une classe ... dont la méthode était appelée dans une boucle d'une autre classe .. qui était également appelée dans une boucle ..

En tout, il y avait cinq niveaux de boucles répartis sur 13 classes (sérieusement). Il était impossible de déterminer ce qu’une classe faisait réellement en la regardant: vous deviez dessiner un graphe mental de ses méthodes, des méthodes appelées par ces méthodes, et ainsi de suite. Si tout avait été regroupé dans une seule méthode, il n'aurait fallu que 70 lignes de long avec notre méthode par problème imbriquée dans cinq niveaux de boucles immédiatement évidents.

Ma demande de refactoriser ces 13 classes en une seule classe a été refusée.

Maintenant que vous avez mentionné Clean Code, bien qu'il contienne de bonnes idées, je pense que son obsession de refactoriser toutes les méthodes en sous-méthodes et celles en sous-méthodes, etc. est beaucoup trop poussée. Au lieu de quelques méthodes à dix lignes, vous êtes censé préférer vingt-un (soi-disant bien nommés). Évidemment, quelqu'un pense que c'est propre, mais pour moi, cela semble bien pire que la version originale.

En outre, le remplacement de simples choses élémentaires telles que

0 == memberArray.length

dans une classe avec un appel à la méthode de la classe, telle que

isEmpty()

est une "amélioration" discutable IMHO. Addition: la différence est que la première vérification fait exactement ce qu'elle dit: vérifie si la longueur du tableau est égale à 0. Ok, isEmpty()peut aussi vérifier la longueur du tableau. Mais cela pourrait aussi être implémenté comme ceci:

return null != memberArray ? 0 == memberArray.length : true;

C'est-à-dire qu'il inclut un contrôle nul implicite! Cela peut être un bon comportement pour une méthode publique - si le tableau est null, alors quelque chose est certainement vide - mais lorsque nous parlons d'internals de classe, cela ne va pas si bien. Bien que l’encapsulation à l’extérieur soit indispensable, les internes de la classe doivent savoir exactement ce qui se passe dans la classe. Vous ne pouvez pas encapsuler la classe à partir de elle-même . Explicite est meilleur qu'implicite.

Cela ne veut pas dire que la décomposition de méthodes longues ou de comparaisons logiques impliquées ne soit pas une bonne chose; bien sûr, mais dans quelle mesure le faire - là où se situe le bonbon - est évidemment une question de goût. Décomposer une méthode longue entraîne davantage de méthodes, et ce n'est pas gratuit. Vous devez parcourir le code source pour voir ce qui se passe réellement, quand vous pourrez le voir en un coup d'œil si tout cela était dans une seule méthode.

J'irais même jusqu'à dire que dans certains cas, une méthode d'une ligne est trop courte pour mériter d'être une méthode.

"Soyez libéral avec des commentaires"

Les commentaires sont définitivement une bonne chose, mais un trop grand nombre d’entre eux est tout aussi mauvais sinon pire que pas assez. Pourquoi? Eh bien, les gens ont tendance à écarter les commentaires s’ils en voient trop. Je ne dis pas que vous pouvez avoir un code parfaitement auto-documenté, mais il est préférable de coder pour avoir besoin de commentaires pour des explications.

GoTo considéré comme nuisible

Si vous implémentez une machine à états, une instruction GOTO peut avoir plus de sens (lisibilité et code efficace) qu'une approche de "programmation structurée". Cela a vraiment inquiété certains collègues lorsque la première partie de code que j'ai écrite dans un nouvel emploi comprenait non pas une mais plusieurs déclarations de goto. Heureusement, ils étaient suffisamment intelligents pour comprendre que c’était la meilleure solution dans ce cas particulier.

Toute "meilleure pratique" qui ne permet pas d'exceptions raisonnables et documentées à ses règles est tout simplement effrayante.

Les sacrifices que nous faisons pour rendre le code testable

Je saute à travers de nombreuses étapes pour rendre mon code testable, mais je ne prétends pas que je ne le ferais pas si j'avais le choix. Cependant, j'entends souvent des gens insister pour que ce soient des "meilleures pratiques". Ces pratiques incluent (écrites dans la langue de .Net, mais s’appliquent aussi à d’autres langues) :

• Créer une interface pour chaque classe. Cela double le nombre de classes (fichiers) à traiter et duplique le code. Oui, la programmation d'interface est bonne, mais c'est à quoi servent les spécificateurs public / privé.
• Chaque classe non instanciée au démarrage nécessite une fabrique. Clairement, new MyClass()c'est beaucoup plus simple que d'écrire une fabrique, mais maintenant la méthode qui la crée ne peut pas être testée séparément. Sinon, je ne ferais que 1 / 20e du nombre de classes d’usine que je fais maintenant.
• Rendre chaque classe publique, ce qui va à l’encontre de l’obtention de spécificateurs d’accès sur les classes. Cependant, les classes non publiques ne sont pas accessibles (et donc testées) à partir d'autres projets. La seule autre option consiste à déplacer tout le code de test dans le même projet (et donc à le publier avec le produit final).
• Injection de dépendance. Clairement, le fait de donner à chaque autre classe un champ et un paramètre constructeur représente beaucoup plus de travail que de simplement les créer lorsque j'en ai besoin; mais alors je ne peux plus tester cette classe en isolation.
• Le principe de responsabilité unique, qui m'a causé tant de maux de tête que je l'ai déplacé vers sa propre réponse .

Alors, que pourrions-nous faire pour résoudre ce problème? Nous aurions besoin d'un changement radical dans l'architecture de la langue:

• Nous aurions besoin de la capacité de se moquer des cours
• Nous aurions besoin de la possibilité de tester des méthodes privées de classes internes provenant d'un autre projet (cela peut sembler être une faille de sécurité, mais je ne vois pas de problème si le client est obligé de nommer ses classes de test) .
• L'injection de dépendance (ou le site de service), ainsi que quelque chose d'équivalent à notre modèle d'usine existant, devrait être une partie essentielle de la langue.

En bref, nous avons besoin d’ un langage conçu à partir de la base avec à l’esprit la testabilité .

Séparer les applications en niveaux; Couche de données, couche métier, couche d'interface utilisateur

La principale raison pour laquelle je n'aime pas cela est que la plupart des endroits qui suivent cette méthode utilisent des cadres très fragiles pour le faire. La couche d'interface utilisateur IE est codée à la main pour traiter les objets de la couche de gestion, tandis que la base de données est SQL et est déjà assez fragile et est gérée par le groupe "DBA" qui n'aime pas les modifications.

Pourquoi est-ce mauvais? La demande d'amélioration la plus courante est probablement "J'ai besoin d'un champ sur l'écran X qui a Y". Coup! Vous avez juste une nouvelle fonctionnalité qui affecte chaque couche, et si vous séparez des couches avec différents programmeurs, cela devient simplement un gros problème impliquant plusieurs personnes et groupes, pour un changement très simple.

De plus, je ne sais pas combien de fois je me suis disputé avec des arguments similaires. "Le champ du nom est limité à 30 caractères. S'agit-il d'un problème de couche d'interface utilisateur, de couche métier ou de couche de données?" Et il y a cent arguments, et aucune bonne réponse. La réponse est la même, elle affecte toutes les couches, vous ne voulez pas rendre l'interface utilisateur stupide et devez parcourir toutes les couches et échouer au niveau de la base de données, juste pour que l'utilisateur découvre que son entrée est trop longue. Si vous le modifiez, cela affecte toutes les couches, etc.

Les "couches" ont tendance à fuir également; Si une couche est physiquement séparée par des limites de processus / de machines (interface utilisateur Web IE et logique d'arrière-plan métier), les règles sont dupliquées pour que tout fonctionne raisonnablement bien. Par exemple, une logique métier aboutit dans l'interface utilisateur, même s'il s'agit d'une "règle de gestion", car l'utilisateur a besoin que l'interface utilisateur soit réactive.

Si le cadre utilisé, ou l'architecture utilisée, est résistant aux petites modifications et aux fuites, c'est-à-dire qu'il repose sur des métadonnées et qu'il est ajusté de manière dynamique dans toutes les couches, cela peut être moins pénible. Mais la plupart des frameworks représentent une douleur royale, nécessitant des modifications de l'interface utilisateur, de la couche de gestion et de la base de données, pour chaque modification mineure, et générant plus de travail et moins d'aide que celle que la technique est censée produire.

Je vais probablement être critiqué pour cela, mais voilà :)

JavaBeans

L'utilisation de JavaBeans en Java. Voir ma question Pourquoi ne devrais-je pas utiliser des POJO immuables au lieu de JavaBeans? sur StackOverflow.

Histoires d'utilisateurs / Cas d'utilisation / Personas

Je comprends la nécessité de ces éléments lorsque vous programmez une industrie que vous ne connaissez pas bien, mais je pense que lorsqu'ils sont mis en œuvre de manière pleinement effective, ils deviennent trop corporatifs et deviennent une perte de temps.

Les limites de 80 caractères / ligne sont muettes

Je comprends que certains compromis doivent être faits pour correspondre au rythme du coureur le plus lent du côté de l'interface graphique (limitations de résolution d'écran, etc.), mais pourquoi cette règle s'applique-t-elle au formatage du code?

Voir ... Il y avait cette petite invention appelée la barre de défilement horizontale qui a été créée pour gérer l'espace d'écran virtuel en dehors de la limite de pixels la plus à droite. Pourquoi les développeurs, qui ont réussi à créer d'excellents outils d'amélioration de la productivité, tels que la coloration syntaxique et l'auto-complétion, ne l'utilisent pas?

Bien sûr, il existe des éditeurs CLI religieusement utilisés par les dinosaures * nix qui respectent les anciennes limitations fatiguées de leurs terminaux VT220, mais pourquoi sommes-nous tenus de respecter les mêmes normes?

Je dis, vis la limite de 80 caractères. Si les dinosaures sont assez épiques pour pirater emacs / vim toute la journée, pourquoi ne devraient-ils pas être capables de créer une extension encapsulant automatiquement des lignes ou offrant des capacités de défilement horizontal à leurs IDE CLI?

Les moniteurs 1920x1080 pixels deviendront éventuellement la norme et les développeurs du monde entier continueront de vivre dans les mêmes limites, sans se soucier de savoir pourquoi, sauf que c'est ce que leurs aînés leur avaient demandé de faire lorsqu'ils commençaient tout juste à programmer.

Les limites de 80 caractères ne sont pas une pratique exemplaire mais une pratique de niche pour une très petite minorité de programmeurs et doivent être traitées comme telles.

Modifier:

Il est compréhensible que de nombreux développeurs n'aiment pas la barre de défilement horizontale car elle nécessite un geste de la souris alors ... Pourquoi ne pas augmenter la limite de largeur de colonne à un nombre plus élevé (que 80) pour ceux d'entre nous qui utilisent des écrans modernes.

Lorsque les écrans 800x600 sont devenus la norme pour la plupart des utilisateurs, les développeurs Web ont augmenté la largeur de leur site Web pour répondre aux besoins de la majorité ... Pourquoi les développeurs ne peuvent-ils pas en faire autant?

Mesurer, mesurer, mesurer

Tellement bien, mesurez-le, mais pour isoler les bugs de performance, la mesure fonctionne à la fois comme une élimination successive. Voici la méthode que j'utilise.

J'ai essayé de localiser la source de la mesure-mesure "sagesse". Quelqu'un avec une caisse à savon assez grande l'a dit, et maintenant ça voyage.

Mon professeur exige que je commence tous mes identifiants (sans les constantes) avec des lettres minuscules, par exemple myVariable.

Je sais que cela semble être une chose mineure, mais de nombreux langages de programmation exigent des variables pour commencer par des lettres majuscules. J'apprécie la cohérence, c'est donc mon habitude de tout commencer par des lettres majuscules.

Utilisez Singletons

Quand vous ne devriez avoir qu'une seule instance de quelque chose. Je ne peux pas être en désaccord plus. N'utilisez jamais un singleton, allouez-le une seule fois et passez le pointeur / objet / la référence selon les besoins. Il n'y a absolument aucune raison de ne pas le faire.

Utiliser unsigned int comme itérateur

Quand apprendront-ils que l'utilisation de Int signé est beaucoup plus sûre et moins sujette aux bogues? Pourquoi est-il si important que l'index d'un tableau ne puisse être qu'un nombre positif, que tout le monde est heureux de passer à côté du fait que 4 - 5 correspond à 4294967295?

Les méthodes ne doivent pas être plus longues qu'un seul écran

Je suis tout à fait d'accord avec le principe de responsabilité unique, mais pourquoi les gens le perçoivent-il comme signifiant "une fonction / méthode ne peut avoir qu'une seule responsabilité au niveau le plus détaillé de granularité logique"?

L'idée est simple. Une fonction / méthode doit accomplir une tâche. Si une partie de cette fonction / méthode peut être utilisée ailleurs, découpez-la en sa propre fonction / méthode. S'il peut être utilisé ailleurs dans le projet, déplacez-le dans sa propre classe ou dans une classe utilitaire et rendez-le accessible en interne.

Avoir une classe qui contient 27 méthodes d'assistance appelées une seule fois dans le code est stupide, c'est une perte de place, une complexité inutile et une perte de temps considérable. Cela semble plutôt être une bonne règle pour les personnes qui veulent avoir l’air occupé à refactoriser le code mais qui ne produisent pas beaucoup.

Voici ma règle ...

Écrire des fonctions / méthodes pour accomplir quelque chose

Si vous êtes sur le point de copier / coller du code, demandez-vous s'il serait préférable de créer une fonction / méthode pour ce code. Si une fonction / méthode n'est appelée qu'une fois dans une autre fonction / méthode, y a-t-il vraiment un intérêt à l'avoir en premier lieu (l'appellera-t-elle plus souvent à l'avenir)? Est-il utile d’ajouter plus de sauts dans les fonctions / méthodes lors du débogage (c’est-à-dire que le saut ajouté rend le débogage plus facile ou plus difficile)?

Je suis tout à fait d’accord pour dire que les fonctions / méthodes de plus de 200 lignes doivent être vérifiées, mais certaines fonctions n’accomplissent qu’une tâche sur autant de lignes et ne contiennent aucune partie utile pouvant être abstraite / utilisée dans le reste du projet.

Je le regarde du point de vue de l'API dev ... Si un nouvel utilisateur examinait le diagramme de classes de votre code, combien de parties de ce diagramme auraient un sens dans l'ensemble du projet et combien existeraient uniquement des aides à d’autres parties internes au projet.

Si je devais choisir entre deux programmeurs: le premier a tendance à écrire des fonctions / méthodes qui tentent de faire trop; le second casse chaque partie de chaque fonction / méthode au plus fin niveau de granularité; Je choisirais les premières mains. Le premier en ferait plus (c’est-à-dire, rédigerait plus de viande de l’application), son code serait plus facile à déboguer (en raison du nombre réduit de sauts dans les fonctions / méthodes pendant le débogage), et il perdrait moins de temps à travailler, à perfectionner le code semble vs perfectionner la façon dont le code fonctionne.

Limitez les abstractions inutiles et ne polluez pas la saisie semi-automatique.