Ci sono delle tecniche di programmazione che ritieni siano state abusate (IE ha usato in modo più eccessivo di quello che dovrebbero essere) o abusate, o usate un po 'per tutto, pur non essendo una soluzione davvero buona a molti dei problemi che le persone tentano di risolvi con esso.

Potrebbero essere espressioni regolari, una sorta di modello di progettazione o forse un algoritmo o qualcosa di completamente diverso. Forse pensi che le persone abusino di eredità multipla ecc.

Commenti nel codice

Vorrei solo che i professori universitari capissero che non avevano bisogno di insegnare ai loro studenti a scrivere 10 righe di commenti dicendo che il seguente codice è un ciclo for, che scorre da 1 a numero di x. Lo vedo nel codice!

Insegnate loro a scrivere prima il codice autodocumentante, quindi commentando adeguatamente ciò che non può essere adeguatamente autodocumentato secondo. Il mondo del software sarebbe un posto migliore.

Il modello di design singleton.

Certo, è un modello utile ma ogni volta che un nuovo programmatore viene a conoscenza di questo modello, inizia a provare ad applicarlo su ogni singola classe che crea.

La cosa più cattiva per proteggere la programmazione stupida. mettere tutto in una presa e non fare nulla con la presa

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

        }

Rabbrividisco quando vedo un tentativo di cattura che non fa nulla ed è progettato per gestire una logica stupida. In generale, le catture di prova sono troppo utilizzate, tuttavia in alcuni casi sono molto utili.

Affidati a StackOverflow per risolvere i tuoi problemi invece di capirlo nel modo più duro.

Nuovi programmatori che trovano la ricchezza di conoscenze sui post SO (troppo spesso) prima di pensare e provare cose.

Ai miei tempi dovevamo programmare da libri, niente internet, niente SO. Adesso vattene dal mio prato.

OOP evidentemente. È molto prezioso, ma se usato in modo improprio può oscurare il codice altrimenti abbastanza facilmente (mi vengono in mente alcuni esempi di programmazione S4 in R) e può dare un enorme sovraccarico che non è necessario e può costare molto tempo per le prestazioni.

Un'altra cosa è che (ad esempio Perl) OOP spesso si riduce a scrivere la stessa cosa al contrario: result = $object ->function(pars)invece di result = function(object, pars)Questo a volte ha senso, ma se combinato con la programmazione procedurale può rendere la lettura del codice piuttosto confusa. E a parte questo, si introduce solo un overhead in cui non migliora il design. Dipende anche da ciò che viene detto sul modello singleton: dovrebbe essere usato, ma non su tutto.

Uso OOP da solo, ma nel mio campo (calcolo scientifico) le prestazioni sono un grosso problema, e OOP è spesso abusato lì come tutti gli studenti ottengono Java al giorno d'oggi. È ottimo per affrontare problemi più grandi, per concettualizzare e così via. Ma se lavori con sequenze di DNA ad esempio in BioPerl, usare gli oggetti ogni volta e lavorare in modo coerente con getter e setter può aumentare di dieci volte il tempo di calcolo. Quando il codice viene eseguito per alcuni giorni anziché per alcune ore, questa differenza conta davvero.

Avendo trascorso diversi anni nei moduli Web ASP.NET, dovrei dire inequivocabilmente:

L'interfaccia utente intelligente

Mentre è del tutto possibile creare applicazioni stratificate e testabili in moduli web, Visual Studio rende troppo facile per gli sviluppatori fare un clic per ottenere moduli strettamente legati alla loro origine dati, con la logica dell'applicazione disseminata su tutto il codice dell'interfaccia utente.

Steve Sanderson spiega questo anti-pattern molto meglio di quanto potrei nel suo libro Pro ASP.NET MVC:

Per creare un'applicazione Smart UI, uno sviluppatore prima costruisce un'interfaccia utente, in genere trascinando una serie di widget dell'interfaccia utente su un'area di disegno, quindi riempie il codice del gestore eventi per ogni possibile clic sul pulsante o altro evento dell'interfaccia utente. Tutta la logica dell'applicazione risiede in questi gestori di eventi: logica per accettare e convalidare l'input dell'utente, eseguire l'accesso e la memorizzazione dei dati e fornire feedback aggiornando l'interfaccia utente. L'intera applicazione è composta da questi gestori di eventi. In sostanza, questo è ciò che tende a venire fuori per impostazione predefinita quando metti un principiante davanti a Visual Studio. In questo progetto, non vi è alcuna separazione delle preoccupazioni. Tutto viene fuso insieme, organizzato solo in base ai diversi eventi dell'interfaccia utente che possono verificarsi. Quando le regole logiche o aziendali devono essere applicate in più di un gestore, il codice viene generalmente copiato e incollato, o alcuni segmenti scelti a caso vengono fattorizzati in classi di utilità statiche. Per tanti ovvi motivi, questo tipo di motivo di design è spesso chiamato anti-pattern.

Lo vedo di tanto in tanto e di solito deriva dal non comprendere appieno le espressioni booleane.

if (someCondition == true)

Reimplementazione della funzionalità di base (o altrimenti fornita), a causa dell'ignoranza della sua esistenza o a causa di un bisogno percepito di personalizzazioni.

Eredità.

Non forzare is-a dove non ha senso.

Personalizzazione del software standard.

Mentre posso riconoscere che questo può essere utile, mi chiedo quanti soldi vengono spesi per fare piccole cose per guadagni discutibili. È qui che un'azienda può spendere centinaia di migliaia se non milioni di dollari in licenze per alcuni software che vengono quindi personalizzati perché è così configurabile, modificabile e flessibile che in realtà non fa molto per impostazione predefinita. Alla fine si tratta di un'applicazione personalizzata a causa di tutto il nuovo codice aggiunto ciò che è stato inizialmente acquistato.

Utilizzo del compilatore come debugger.

Ignorando gli avvisi del compilatore o spegnendoli completamente.

Variabili globali.

Tutti i modelli di design.

Sono come sale o zucchero. Alcuni sul tuo cibo lo rendono fantastico, molti altri fanno schifo il tuo cibo.

Non fraintendetemi. I modelli di progettazione sono tecniche meravigliose. Li ho usati molto. Ma a volte trovo programmatori, (alcuni dei quali sono i miei ex capi), che avevano questi "devi usare un modello di progettazione", anche se non corrisponde al problema !!!

Un esempio è il "modello di visitatore" che è più diretto per "Collezioni lineari / sequenziali". Una volta ho dovuto lavorare con una struttura di dati ad albero. Per "visitare" ogni articolo, codifico un metodo di modello non di progettazione e un ex capo insiste per usare o adattare il "Modello di visitatore". Quindi, navigo in rete, per un secondo parere. Bene, altri programmatori avevano la stessa situazione e la stessa soluzione. E chiamalo "Tree / Hierarchical Visitor Pattern"., Come un NUOVO Design Pattern

Spero che sia aggiunto come nuovo modello a quelli esistenti, in una nuova versione del libro "Design Patterns".

Utilizzo delle eccezioni come controllo del flusso. Un po 'simile a questa risposta , ma diverso.

Ingoiare eccezioni è una cattiva forma perché introduce nel codice bug misteriosi e difficili da trovare. L'uso delle eccezioni come controllo di flusso, d'altra parte, è negativo perché rende il codice molto più inefficiente di quanto potrebbe essere ed è concettualmente sciatto.

La gestione delle eccezioni dovrebbe essere utilizzata solo per gestire scenari davvero eccezionali (duh) e imprevisti, non cose come un utente che digita un carattere alfabetico in cui è previsto un numero. Questo tipo di abuso delle eccezioni è estremamente comune tra i programmatori inadeguati nel mondo Java.

Vado con inflessibilità attraverso un eccessivo nascondimento dei dati.

Sappiamo tutti che l'astrazione e nascondere l'implementazione sono buone, ma di più non è sempre meglio. Esagerato, è possibile ottenere un risultato non flessibile che non è in grado di far fronte alle modifiche dei requisiti. Per gestire la modifica, non è necessario solo modificare la classe che deve gestire tale modifica, ma è anche necessario creare un modo per rendere accessibili le informazioni che non sono mai state necessarie prima nonostante i livelli di occultamento dei dati.

Il problema è che, come per tutte le questioni relative al trovare il giusto equilibrio per ogni contesto, ci vuole esperienza.

Esposizione di matrici interne

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

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

copiare oggetti mutabili prima di tornare, a meno che non si desideri condividere lo stato.

Stato mutevole e loop. Non hai quasi mai bisogno di loro e quasi sempre ottieni un codice migliore senza di loro.

Ad esempio, questo viene preso direttamente da 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

Stanno entrambi facendo la stessa cosa. Ma non ho idea di cosa stiano facendo. Fortunatamente, la domanda in realtà spiega cosa stanno facendo, quindi sono stato in grado di riscriverli come segue:

// 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);

Non ci sono anelli e nessuno stato mutabile. Bene, ok, nessun loop esplicito e nessun contatore di loop.

Il codice è diventato molto più breve, molto più semplice, molto più simile a una descrizione di ciò che il codice dovrebbe fare (specialmente nel caso di Ruby dice praticamente direttamente "raggruppa le cose per tipo") e molto meno soggetto a errori. Non c'è pericolo di scappare dalla fine dell'array, errori di fencepost o errori off-by-one con gli indici di loop e le condizioni di terminazione, perché non ci sono indici di loop e condizioni di terminazione.

Beffardo. Presenta troppi requisiti artificiali per l'eccessivo disaccoppiamento nel codice, porta a ravioli troppo ingegnerizzati e ti costringe a progettare in stile OO in gola quando un design più procedurale o funzionale potrebbe essere una soluzione più semplice al tuo problema.

I programmatori Delphi di tutto il mondo hanno scoperto negli ultimi due anni quanto sia male usare gli array di caratteri per memorizzare byte a causa della conversione Unicode wholescale

E "presto" impareremo quanto è male archiviare numeri interi negli elenchi quando vogliamo apportare la modifica a 64 bit.

Proprietà. So che questo è controverso, ma sento che le proprietà sono ampiamente abusate in .net.

Qual è la differenza tra queste due linee?

public string Property { get; set; }

public string Field;

Per lo sviluppatore, la differenza è: assolutamente niente. Il modulo compilato è leggermente diverso, quindi se stai scrivendo una libreria e quella libreria verrà aggiornata nei programmi e non puoi ricompilare i programmi stessi (ad esempio se stai scrivendo un'interfaccia per plugin che dovrebbe funzionare su più versioni del software), quindi non utilizzare campi pubblici perché non è possibile sostituirli con proprietà. In ogni altro caso, non c'è assolutamente alcuna differenza tra l'utilizzo di un campo o una proprietà automatica senza modificatori.