Il valore di un codice più semplice rispetto alle prestazioni dovrebbe restituire più valori?

Question

Il valore di un codice più semplice rispetto alle prestazioni dovrebbe restituire più valori?

#1 da (10 voti)
#2 da (9 voti)
#3 da (9 voti)

2

Troppo spesso mi trovo ad affrontare situazioni in cui ho bisogno di ottenere diversi tipi di informazioni da un metodo. Di solito penso a lungo e duramente per aggirare queste situazioni, ma penso che sia un lavoro inutile che sto facendo. La mia domanda: dovrei preferire un leggero calo di prestazioni in queste situazioni, ad esempio ripetere due volte su un array per esempio (ottenendo un codice più lento ma più pulito) o provare a restituire tutto in una volta con un'istanza di una classe helper personalizzata?

Ecco un esempio di caso per il gusto di

char[] arr = {'a', 'b', 'a', 'c', 'a'};
int count = 0;  // 'a' and 'b' count
String word= "";  // 'a's and 'b's glued together in their occurring order
for (int i = 0; i < arr.length; ++i) {
    for (int j = 0; j <= arr[0].length; ++j) {
        if (arr[i][j] == 'a' || arr[i][j] == 'b') {
            ++count;
            word += Character.toString(arr[i][j]);
        }
    }
}
// return both 'count' and 'word' inside a new object or iterate twice?

coding-style design java coding-standards

posta Wiener Boat 29.10.2014 - 22:39

fonte

3 risposte

10

"L'ottimizzazione prematura è la radice di tutti i mali" cosa è carina e carina, ma è spesso male interpretata e non dovrebbe essere usato come scusa per scrivere codice scadente : se riesci a scrivere facilmente codice che ovviamente funziona meglio, dovresti (ad esempio scegliendo la giusta struttura dati o evitando di eseguire il ciclo due volte quando un ciclo può eseguire il lavoro).

Nel semplice esempio che hai mostrato, puoi creare una classe che gestisce il lavoro specifico. Qualcosa come:

class FindAGoodName {

    FindAGoodName(char[] array, char... retain letters) {
        //your loop here
    }

    int getCount() {}

    String getWord() {}

}

Il codice sarà leggibile (possibilmente più leggibile) e si effettuerà un ciclo solo una volta. Tutti felici.

risposta data 29.10.2014 - 23:33

fonte

9

Se la modifica del codice risulta in un ...

miglioramento misurabile delle prestazioni che
soddisfa un requisito software non funzionale e
non puoi soddisfare il requisito utilizzando il codice più semplice

... quindi modificare il codice. Altrimenti, è quasi sempre meglio scrivere codice che sia più facile da capire e più gestibile.

risposta data 29.10.2014 - 22:46

fonte

Leggi altre domande sui tag coding-style design java coding-standards

Complessità nei cicli nidificati Domanda di progetto open source nell'intervista [chiusa]

score 9 · Accepted Answer

L'ottimizzazione prematura è la radice di tutto il male.

Come Donald Knuth ha detto,

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Indipendentemente dal linguaggio, scrivi il tuo codice per essere il più chiaro possibile. Se il ciclo due volte produce effettivamente un codice più chiaro, procedi e scrivilo. Un compilatore di discendenza può rifattorizzare il secondo ciclo o il sovraccarico può essere strozzato da altre aree del programma. A meno che il tuo software non sia ampiamente utilizzato, è probabile che il tempo che il tuo successore spende cercando di decifrare un blocco di codice rapido ma complicato sarà più costoso rispetto al runtime aumentato in modo frazionale.

Se, dopo aver provato, si scopre che un determinato programma è in esecuzione in modo inaccettabile lento, un refactoring per i mezzi più complessi potrebbe essere appropriato. Ma queste situazioni sono spesso difficili da identificare in anticipo, a causa di questa incertezza più di ogni altra cosa, dovresti sbagliare sul lato della chiarezza sulle "prestazioni" ogni volta che sono in conflitto.