Y a-t-il des techniques de programmation que vous trouvez trop utilisées (IE beaucoup plus que ce qu’elles devraient être) ou mal utilisées, ou utilisées un peu pour tout, sans être une très bonne solution à de nombreux problèmes que l’on essaie de résoudre? résoudre avec elle.

Cela peut être des expressions régulières, une sorte de motif de conception ou peut-être un algorithme, ou quelque chose de complètement différent. Vous pensez peut-être que les gens abusent de l'héritage multiple, etc.

Commentaires dans le code

J'espère que les professeurs d'université comprendront qu'ils n'ont pas besoin d'apprendre à leurs étudiants à écrire 10 lignes de commentaires indiquant que le code suivant est une boucle for, en effectuant une itération de 1 à un nombre de x. Je peux le voir dans le code!

Apprenez-leur à rédiger un code auto-documenté en premier lieu, puis des commentaires appropriés sur ce qui ne peut pas être ensuite auto-documenté de manière adéquate. Le monde du logiciel serait un meilleur endroit.

Le modèle de conception singleton.

C'est un modèle utile, mais chaque fois qu'un nouveau programmeur découvre ce modèle, il commence à essayer de l'appliquer à chaque classe qu'il crée.

La chose la plus diabolique pour protéger la programmation muette. tout mettre dans une prise d'essai et ne rien faire avec la prise

        try
        {
            int total = 1;
            int avg = 0;
            var answer = total/avg;
        }
        catch (Exception)
        {

        }

Je frémis quand je vois un essai qui ne fait rien et qui est conçu pour gérer une logique idiote. En général, les captures sont trop utilisées, mais dans certains cas, elles sont très utiles.

Comptez sur StackOverflow pour résoudre vos problèmes au lieu de le résoudre à la dure.

Les nouveaux programmeurs qui découvrent (trop souvent) la richesse des connaissances sur SO postent avant de penser et d’essayer des choses.

De mon temps, nous devions coder à partir de livres, pas d'internet, pas de SO. Maintenant sortez de ma pelouse.

OOP évidemment. C'est très utile, mais quand on l'utilise mal, cela peut assez facilement obscurcir un code autrement clair (on peut penser à quelques exemples de programmation S4 en R), et peut engendrer une surcharge énorme inutile et qui peut vous faire perdre beaucoup de temps en performances.

Une autre chose est que (dans Perl, par exemple) OOP revient souvent à écrire la même chose dans l’inverse: result = $object ->function(pars)au lieu de result = function(object, pars)Cela a parfois un sens, mais mélangé à une programmation procédurale, la lecture du code peut être assez déroutante. Et en dehors de cela, vous introduisez simplement plus de frais généraux là où cela n'améliore pas la conception. Cela revient aussi à ce qui est dit à propos du motif singleton: devrait être utilisé, mais pas sur tout.

J'utilise moi-même la programmation orientée objet, mais dans mon domaine (calcul scientifique), les performances sont un gros problème, et la programmation orientée objet y est souvent utilisée de manière abusive, car tous les étudiants acquièrent Java de nos jours. C'est génial pour traiter de gros problèmes, pour conceptualiser et ainsi de suite. Mais si vous travaillez avec des séquences d’ADN dans BioPerl, par exemple, l’utilisation systématique des objets et l’utilisation systématique de getters et de setters peuvent décupler le temps de calcul. Lorsque votre code est exécuté quelques jours au lieu de quelques heures, cette différence est primordiale.

Ayant passé plusieurs années dans les formulaires Web ASP.NET, je devrais dire sans équivoque:

L'interface utilisateur intelligente

Bien qu'il soit tout à fait possible de créer des applications multicouches et testables dans des formulaires Web, Visual Studio facilite trop la tâche des développeurs pour leur permettre de cliquer en un clic sur des formulaires étroitement liés à leur source de données, la logique de l'application étant jalonnée de tout le code de l'interface utilisateur.

Steve Sanderson explique cet anti-motif beaucoup mieux que je ne le pouvais dans son livre Pro ASP.NET MVC:

Pour créer une application Smart UI, un développeur construit d'abord une interface utilisateur, généralement en faisant glisser une série de widgets d'interface utilisateur sur un canevas, puis il remplit le code du gestionnaire d'événements pour chaque clic de bouton possible ou tout autre événement d'interface utilisateur. Toute la logique de l'application réside dans ces gestionnaires d'événements: logique permettant d'accepter et de valider les entrées de l'utilisateur, d'effectuer l'accès et le stockage des données et de fournir des informations en mettant à jour l'interface utilisateur. L'ensemble de l'application est constitué de ces gestionnaires d'événements. C'est ce qui a tendance à apparaître par défaut lorsque vous placez un novice devant Visual Studio. Dans cette conception, il n'y a aucune séparation des préoccupations. Tout est fusionné, organisé uniquement en fonction des différents événements de l'interface utilisateur pouvant se produire. Lorsque des règles logiques ou métier doivent être appliquées dans plusieurs gestionnaires, le code est généralement copié et collé. ou certains segments choisis aléatoirement sont factorisés dans des classes d’utilitaires statiques. Pour de nombreuses raisons évidentes, ce type de motif est souvent appelé anti-motif.

Je le vois de temps en temps et cela résulte généralement d'une compréhension insuffisante des expressions booléennes.

if (someCondition == true)

Réimplémentation de la fonctionnalité de base (ou fournie d'une autre manière), soit en raison de son ignorance de son existence, soit en raison d'un besoin perçu de personnalisation.

Héritage.

Ne pas imposer, c’est là où cela n’a aucun sens.

Personnalisation des logiciels disponibles dans le commerce.

Bien que je sache que cela peut être utile, je me demande combien d’argent est dépensé pour faire de petites choses pour des gains discutables. C’est là qu’une entreprise peut dépenser des centaines, voire des millions de dollars, en licences de certains logiciels, qui sont ensuite personnalisés, car ils sont tellement configurables, modifiables et flexibles qu’ils ne font pas grand-chose par défaut. En fin de compte, il s’agit d’une application personnalisée à cause du nouveau code ajouté à ce qui a été acheté.

Utiliser le compliant comme un débogueur.

Ignorer les avertissements de conformité ou les désactiver complètement.

Variables globales.

Tous les modèles de conception.

Ils sont comme le sel ou le sucre. Certains d’entre eux rendent votre nourriture géniale, beaucoup d’entre eux rendent votre nourriture nulle.

Ne vous méprenez pas. Les modèles de conception sont des techniques merveilleuses. Je les ai beaucoup utilisés. Mais parfois, je trouve des programmeurs (dont certains sont mes ex-patrons), qui avaient ces "vous devez utiliser un motif de conception", même si cela ne correspond pas au problème !!!

Un exemple est le "modèle de visiteur" qui est plus destiné aux "collections linéaires / séquentielles". J'ai dû travailler une fois avec une structure de données arborescente. Afin de "visiter" chaque élément, je code une méthode de modèle non-design, et un ancien patron insiste pour utiliser ou adapter le "modèle de visiteur". Ensuite, je navigue sur le net, pour un deuxième avis. Eh bien, d'autres programmeurs avaient la même situation et la même solution. Et appelez-le "Modèle de visiteur arbre / hiérarchique"., Comme un nouveau modèle de conception

J'espère que c'est ajouté en tant que nouveau modèle aux modèles existants, dans une nouvelle version du livre "Design Patterns".

Utiliser des exceptions comme contrôle de flux. Sorte de semblable à cette réponse , mais différent.

Avaler des exceptions est une mauvaise forme car cela introduit des bogues mystérieux et difficiles à trouver dans le code. En revanche, utiliser des exceptions comme contrôle de flux est une mauvaise solution car il rend le code beaucoup plus inefficace qu’il pourrait l’être et est conceptuellement bâclé.

La gestion des exceptions ne doit être utilisée que pour gérer des scénarios vraiment exceptionnels (duh), imprévus, et non des choses comme un utilisateur tapant un caractère alphabétique où un nombre est attendu. Ce type d'abus d'exception est extrêmement courant chez les mauvais programmeurs du monde Java.

Je vais aller avec inflexibilité par la dissimulation excessive de données.

Nous savons tous que l'abstraction et la dissimulation de la mise en œuvre sont bonnes, mais plus n'est pas toujours meilleur. Si vous en faites trop, vous pouvez obtenir un résultat inflexible qui ne peut pas faire face aux changements d’exigences. Pour gérer le changement, vous devez non seulement modifier la classe qui doit gérer ce changement, mais vous devez également créer un moyen pour que les informations dont il n'a jamais eu besoin auparavant soient accessibles malgré les couches de données masquées.

Le problème est que, comme pour tout problème de trouver le bon équilibre pour chaque contexte, il faut de l'expérience.

Exposer les tableaux internes

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

Selon http://www.oracle.com/technetwork/java/seccodeguide-139067.html

copier des objets mutables avant de retourner, sauf si l'intention est de partager l'état.

Etat mutable et boucles. Vous n’avez presque jamais besoin d’eux, et vous obtenez presque toujours un meilleur code sans eux.

Par exemple, cela provient directement d'un thread StackOverflow:

// ECMAScript
var thing, things_by_type = {};
for (var i = 0; i < things.length; i++) {
    thing = things[i];
    if(things_by_type[thing.type]) {
        things_by_type[thing.type].push(thing);
    } else {
        things_by_type[thing.type] = [thing];
    }
}

# Ruby
things_by_type = {}
things.each do |thing|
  (things_by_type[thing.type] ||= []) << thing
end

Ils font tous les deux la même chose. Mais je n'ai aucune idée de ce qu'ils font. Heureusement, la question explique en fait ce qu’ils font, alors j’ai pu les réécrire comme suit:

// ECMAScript
things.reduce(function (acc, thing) {
    (acc[thing.type] || (acc[thing.type] = [])).push(thing);
    return acc;
}, {});

# Ruby
things.group_by(&:type)

// Scala
things groupBy(_.type)

// C#
from thing in things group thing by thing.Type // or
things.GroupBy(thing => thing.Type);

Il n'y a pas de boucles et pas d'état mutable. Bon, d'accord, pas de boucles explicites ni de compteurs de boucles.

Le code est devenu beaucoup plus court, beaucoup plus simple, et ressemble beaucoup plus à une description de ce qu’il est censé faire (en particulier dans l’affaire Ruby, il est dit directement "grouper les choses par type"), et beaucoup moins sujet aux erreurs. Il n'y a pas de risque de fuite à la fin du tableau, d'erreurs poteau clôturé ou d'erreurs décalées avec les indices de boucle et les conditions de terminaison, car il n'y a pas d' indices de boucle et de conditions de terminaison.

Railleur. Cela introduit trop d'exigences artificielles pour un découplage excessif dans votre code, conduit à un code de raviolis trop sophistiqué et oblige une conception de style OO dans votre gorge alors qu'une conception plus procédurale ou fonctionnelle pourrait être une solution plus simple à votre problème.

Les programmeurs Delphi du monde entier ont découvert au cours des deux dernières années à quel point il est difficile d’utiliser des tableaux de caractères pour stocker des octets en raison de la conversion Unicode totale

Et, "bientôt", nous verrons combien il est difficile de stocker des entiers dans des listes lorsque nous souhaitons passer à la version 64 bits.

Propriétés. Je sais que cela suscite la controverse, mais j’estime que les propriétés sont beaucoup trop utilisées dans .net.

Quelle est la différence entre ces deux lignes?

public string Property { get; set; }

public string Field;

Pour le développeur, la différence est la suivante: absolument rien. La forme compilée est un petit différent peu, donc si vous écrivez une bibliothèque, et que la bibliothèque va être mis à jour dans les programmes, et vous ne pouvez pas recompiler les programmes eux - mêmes (par exemple , si vous écrivez une interface pour plug - ins devrait fonctionner avec toutes les versions de votre logiciel), vous ne devriez pas utiliser de champs publics, car vous ne pouvez pas les remplacer par des propriétés. Dans les autres cas, il n'y a absolument aucune différence entre utiliser un champ ou une propriété automatique sans modificateurs.