Commenti nel codice

Spero solo che i professori universitari comprendano che non hanno bisogno di insegnare ai loro studenti a scrivere 10 righe di commenti dicendo che il codice seguente è un ciclo for, che va da 1 a numero di x. Posso vederlo nel codice!

Insegnagli a scrivere il codice di auto-documentazione prima di commentare in modo appropriato ciò che non può essere adeguatamente auto-documentato in secondo luogo. 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ù malvagia 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 la logica stupida. In generale i tentativi di cattura sono troppo usati, tuttavia in alcuni casi sono molto utili.

Affidarsi a StackOverflow per risolvere i tuoi problemi invece di capirlo a fondo.

Nuovi programmatori che trovano la ricchezza di conoscenza su post SO (troppo spesso) prima di pensare e provare cose nuove.

Ai miei tempi dovevamo codificare i libri, niente internet, niente SO. Ora scendi dal mio prato.

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

Un'altra cosa è che (in es. Perl) spesso l'OOP arriva a scrivere la stessa cosa al contrario: result = $object ->function(pars) invece di result = function(object, pars) Questo a volte ha senso, ma se mescolato con la programmazione procedurale può rendere la lettura codice piuttosto confuso. E a parte questo, si introduce solo un sovraccarico in cui non migliora il design. Si tratta di ciò che viene detto a proposito del modello singleton: dovrebbe essere usato, ma non su tutto.

Io uso OOP da solo, ma nel mio campo (calcolo scientifico) le prestazioni sono un grosso problema, e OOP è spesso abusato lì mentre tutti gli studenti ottengono Java oggigiorno. È 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 tuo codice è in esecuzione alcuni giorni invece di poche ore, questa differenza conta davvero.

Dopo aver trascorso diversi anni in Webforms ASP.NET, dovrei dire inequivocabilmente:

L'interfaccia utente intelligente

Sebbene sia completamente possibile creare applicazioni testabili su più livelli in webform, Visual Studio rende troppo facile agli sviluppatori fare clic con un solo clic verso forme strettamente legate 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 MVC Pro ASP.NET:

To build a Smart UI application, a developer first constructs a UI,usually by dragging a series of UI widgets onto a canvas, and then fills in event handler code for each possible button click or other UI event. All application logic resides in these event handlers: logic to accept and validate user input, to perform data access and storage, and to provide feedback by updating the UI. The whole application consists of these event handlers. Essentially, this is what tends to come out by default when you put a novice in front of Visual Studio. In this design, there’s no separation of concerns whatsoever. Everything is fused together, arranged only in terms of the different UI events that may occur. When logic or business rules need to be applied in more than one handler, the code is usually copied and pasted, or certain randomly chosen segments are factored out into static utility classes. For so many obvious reasons, this kind of design pattern is often called an anti-pattern.

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

if (someCondition == true)

Reimplementing funzionalità core (o altrimenti fornita), a causa dell'ignoranza della sua esistenza o a causa di una percezione della necessità di personalizzazioni.

Inheritance.

Non applicare è-a dove non ha senso.

Personalizzazione del software off-the-shelf.

Anche se posso riconoscere che questo può essere utile, mi chiedo quanti soldi vengono spesi per ottenere piccole cose da ottenere per guadagni discutibili. È qui che un'azienda può spendere centinaia di migliaia se non milioni di dollari sulle licenze per alcuni software che vengono personalizzati perché è così configurabile, modificabile e flessibile che in realtà non fa molto di default. Alla fine è un'applicazione personalizzata perché tutto il nuovo codice ha aggiunto quello che è stato inizialmente acquistato.

Utilizzo del compilatore come debugger.

Ignorare gli avvisi del compilatore o disattivarli completamente.

Variabili globali.

Tutti i modelli di progettazione.

Sono come il sale o lo zucchero. Alcuni di loro sul tuo cibo lo rendono ottimo, molti di loro, fanno schifo il tuo cibo.

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

Un esempio è il "Visitor Pattern" che è più diretto per "Lineal / Sequential Collections". Ho dovuto lavorare con una struttura dati ad albero, una volta. Per "visitare" ogni elemento, codifico un metodo di pattern non di design, e un ex capo insiste a usare o adattare il "Visitor Pattern". Quindi, sfoglio la rete, per un secondo parere. Bene, altri programmatori avevano la stessa situazione e la stessa soluzione. E chiamalo "Albero / modello gerarchico dei visitatori"., come un NUOVO design pattern

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

Utilizzo delle eccezioni come controllo del flusso. Una sorta di simile a questa risposta , ma diversa.

Ingerire le eccezioni è una cattiva forma perché introduce dei bug misteriosi e difficili da trovare nel codice. D'altro canto, l'utilizzo di eccezioni come controllo del flusso è 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 eccezionali (duh), imprevisti, non cose come un utente che digita un carattere alfabetico in cui è previsto un numero. Questo tipo di abuso di eccezioni è estremamente comune tra i cattivi programmatori nel mondo Java.

Ho intenzione di andare con inflessibilità attraverso l'eccessivo nascondimento dei dati.

Sappiamo tutti che l'astrazione e nascondere l'implementazione sono buone, ma non sempre è meglio. Overdone, è possibile ottenere un risultato inflessibile che non può far fronte alle variazioni dei requisiti. Per gestire la modifica, non solo devi modificare la classe che deve gestire tale modifica, ma devi anche creare un modo per le informazioni che non è mai stato necessario prima di essere accessibile nonostante i livelli di occultamento dei dati.

Il problema è che, come con tutti i problemi di ricerca del 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;
    }
}

In base al link

copy mutable objects before returning, unless the intention is to share state.

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

Ad esempio, questo è 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

Entrambi stanno facendo la stessa cosa. Ma non ho idea di ciò che fanno . Fortunatamente, la domanda spiega in realtà 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 loop e nessuno stato mutabile. Bene, okay, nessun ciclo 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 Ruby dice direttamente "raggruppa le cose per tipo") e molto meno errore -prone. 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. Introduce troppi requisiti artificiali per il disaccoppiamento eccessivo nel codice, porta a un codice ravioli sovraingegnato e costringe il design in stile OO in gola quando un progetto 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 pessimo utilizzare gli array di caratteri per memorizzare i byte a causa della conversione Unicode di whladale

E, "presto" scopriremo quanto è grave memorizzare i numeri interi negli elenchi quando vogliamo apporta la modifica a 64-bit.

Proprietà. So che questo è controverso, ma ritengo che le proprietà siano ampiamente sfruttate in .net.

Qual è la differenza tra queste due linee?

public string Property { get; set; }

public string Field;

Per lo sviluppatore, la differenza è: assolutamente nulla. La forma compilata è un po 'diversa, quindi se stai scrivendo una libreria, e quella libreria verrà aggiornata nei programmi, e non puoi ricompilare i programmi se stessi (ad esempio se stai scrivendo un'interfaccia per plugin che dovrebbe funzionare su versioni del tuo software), allora non dovresti utilizzare i campi pubblici perché non puoi sostituirli con le proprietà. In ogni altro caso, c'è assolutamente nessuna differenza tra l'uso di un campo o una proprietà auto senza modificatori.