Faut-il éviter certaines constructions de programmation (et autres) pour des raisons de maintenance?

Question

Je travaille sur un projet non-personnel, donc il est sûr de dire que le programmeur de maintenance ne sera pas moi, sinon je n'aurais pas besoin de poser cette question.

Maintenant il y a quelques constructions (délégués, expressions lambda) que je voudrais essayer dans mon code, non pour rendre intentionnellement le code plus difficile à lire, mais parce qu'elles se prêtent à la situation (et moins de code pour taper bien), et de pratiquer les utiliser aussi bien que je suis nouveau à la langue. Cependant, je ne suis pas sûr si le programmeur de maintenance connaîtra chaque construction, comme beaucoup d'entre nous ne sont pas venus d'arrière-plan, et je ne suis pas sûr s'il est aussi enthousiaste à propos de la programmation que moi ou juste traiter c'est comme un travail régulier. Mes questions sont les suivantes:

• Si certaines constructions de programmation être évités pour améliorer maintainabilily?

• Si la réponse à la question ci-dessus est oui, alors le sous-ensemble de constructions est-il à éviter?

• Est-il de la responsabilité du programmeur de maintenance d'apprendre une langue complètement?

Answer 1

Je suis contre les moins-Dénominateur commun de codage. Nous sommes des professionnels, une partie de ce que nous devrions faire est apprendre des choses que nous ne savons pas.

D'autre part, je suis également contre le code de gloire. Utilisez les constructions les plus simples qui peuvent faire le travail - le code de débogage est deux fois plus dur que l'écriture, donc vous feriez mieux d'écrire seulement le code moitié aussi intelligent que vous êtes capable de!

Answer 2

Je pense que la règle générale est de s'assurer que votre code est lisible avec beaucoup de commentaires, en particulier dans les endroits où vous faites quelque chose qui n'est pas simple. Éviter certaines constructions telles que les délégués et les expressions lambda ne devrait pas être la bonne façon d'y aller, si elles sont utilisées correctement et judicieusement, des fonctionnalités comme celles-ci peuvent grandement réduire la complexité de votre code et le rendre plus concis et expressif. Après tout, c'est la beauté de LINQ, n'est-ce pas? ;-)

Je pense que vous devriez vous concentrer à faire votre part du travail du mieux que vous le pouvez, que les autres programmeurs aient ou non toutes les connaissances nécessaires pour comprendre que votre code est hors de votre contrôle. Si ce programmeur d'entretien part et que quelqu'un d'autre entre, qu'est-ce qui se passe alors? Vous ne devriez pas adapter votre code au programmeur de maintenance, mais plutôt adapter votre code au problème que vous êtes chargé de résoudre.

Answer 3

Je pense que même si vous écrivez sur votre propre projet, il vaut la peine de coller autant que possible aux idiomes communs/standard dans n'importe quelle langue que vous utilisez. Je suis moi-même tombé sur ce piège - j'ai écrit du code qui a fait quelque chose de «malin», je ne l'ai pas documenté suffisamment et j'ai introduit un bug sérieux quand je suis revenu changer le code quelques mois plus tard.

Ma règle générale - utilisez le «langage de base» autant que possible humainement, et lorsque vous divergez de cela, documentez soigneusement votre approche. Évitez d'exploiter le sucre syntaxique pour raccourcir votre code, sauf s'il s'agit d'un idiome standard (par exemple, les propriétés en C#).La lisibilité devrait l'emporter sur la vitesse de frappe à chaque fois.

Si vous attendez des codeurs de maintenance pour prendre en charge votre travail, tout ceci est doublement vrai. Vous ne peut pas s'attendre codeurs de maintenance à maîtriser plusieurs paradigmes dans la plupart des organisations. Par conséquent, si vous par ex. commencez à utiliser des constructions de programmation logiques/fonctionnelles comme lambdas dans votre code orienté objet, c'est un peu comme écrire un chapitre en allemand dans un livre en anglais. Vous pourriez souhaiter que vos lecteurs soient des passionnés multilingues, mais il est fort probable qu'ils ne le soient pas.

Answer 4

Je crois surtout que les expressions lambda facilitent la lecture du code. Au lieu d'avoir plusieurs pour-chacun avec beaucoup de conditions - un lambda propre peut presque être lu. D'après mon expérience, les choses qui rendent le code difficile à lire sont des arguments Func génériques et intelligents ... Ils ne suppriment souvent que les fonctions tw0 + faciles à lire et les remplacent par des fonctions génériques difficiles à lire. Donc, il est plus important dans mon livre d'avoir des méthodes avec de bons noms que d'éviter certaines constructions. Mais ne vous inquiétez pas pour eux ne les connaissant pas - ils devraient les apprendre de toute façon.