creativo e complesso vs semplice e leggibile

La tua seconda versione è molto più semplice e leggibile e molto meglio sotto ogni aspetto. Non è un codice creativo o complesso, ma perfettamente normale e diretto.

L'unico modo in cui potrebbe confondere i principianti è che richiede loro di capire che le espressioni booleane complesse sono A) le espressioni ancora come tutte le altre e B) possono essere utilizzate ovunque sia richiesto un valore booleano, piuttosto che solo all'interno di un if clausola.

Ma questo è qualcosa che i neofiti hanno davvero bisogno di capire, quindi non dovresti mai lasciare che la possibilità che qualcuno ancora non la capisca influenza il tuo codice.

Non vedo che cosa sia creativo riguardo ad entrambi gli esempi, stai solo cambiando spazio. Se ritieni che sia (potenzialmente) poco chiaro, prova a chiarire il tuo intento , ad esempio:

bool sameForEvery(int begin, int end)
{
  for (int i = begin; i <= end; ++i)
  {
    if (object1(i) != object2(i)) return false;
  }
  return true;
}

bool allthesame = sameForEvery(0, 3);

in generale, capire l'implementazione è più facile se sai cosa sta cercando di ottenere il codice, e se la funzione (e le variabili) sono ben definite, non bisogno per leggere il implementazione per avere un'idea ragionevole di ciò che sta facendo il chiamante.

Modifica : torna indietro e leggi la versione originale della domanda.

Stai suggerendo che lo srotolamento manuale di questo ciclo sia una ottimizzazione complessa che potrebbe confondere le persone?

including simple code everywhere might sometime hamper my performance.

Non ottimizzarlo prematuramente. Il codice leggibile è probabilmente un codice gestibile. È più facile ottimizzare il codice gestibile, piuttosto che mantenere il codice illeggibile (ma veloce).

Detto questo, entrambi i tuoi esempi sono meno leggibili. iterare attraverso la risposta (come in @ Useless), potrebbe aiutare.

Penso che entrambi i tuoi esempi siano semplici e leggibili. In generale, seguo il il rasoio di Occam o KISS : non usare un concetto è più difficile da capire a meno che tu non ne abbia un reale vantaggio.

In altre parole, il problema che stai cercando di risolvere è probabilmente abbastanza complesso, non rendere la tua soluzione ancora più complessa. Vorrei aggiungere che a volte una soluzione semplice richiede un'analisi più approfondita e molta più creatività di una complessa.

Penso che questi principi siano particolarmente importanti se

1. Stai lavorando in una squadra: altri programmatori dovranno leggere il tuo codice. Tutti sanno che sei già un buon programmatore, non c'è bisogno di mettersi in mostra, basta renderlo semplice e leggibile.
2. Stai sviluppando qualcosa che devi consegnare in tempo e in base ad alcuni requisiti di qualità: non aggiungere ulteriore complessità che dovrai gestire prima o poi. I clienti non leggeranno il tuo codice sorgente.

D'altra parte, se stai programmando per il tuo divertimento e vuoi provare nuove cose, quindi fai ciò che ti piace di più.

Solo i miei 2 centesimi.

Rispetto all'esempio sopra citato, entrambi sono perfettamente leggibili e comprensibili. In generale dovremmo bilanciare entrambi.

Modifica: La prima revisione della domanda per cui ho fornito la risposta di seguito è stata modificata. Poiché la domanda è già stata ben fornita, non aggiornerò questa risposta.

Il tuo primo approccio è estensibile per ospitare più occorrenze. Se in futuro la tua attività richiederebbe di ospitare 50 oggetti, ad esempio, devi seguire il primo approccio e persino astrarre il conteggio fornendo un limite variabile per il ciclo. Se questo non è il caso, l'opzione 2 è migliore perché è molto più semplice, contiene meno variabili e più concisa.

Note a margine:

1-Cosa succede se uno degli oggetti è nullo? È possibile? Si dovrebbe considerare questo caso.

2-Perché non hai inizializzato il risultato prima del ciclo nel metodo 1? È una buona pratica farlo. *

Quando fai qualsiasi tipo di ottimizzazione - se provi a scrivere tutto in una riga (ottimizzando il mio tempo), o usi un collegamento per fare il lavoro (ottimizzando il compilatore tempo, o forse tempo dell'utente finale) - Cerco di bilanciare il guadagno con la perdita di tempo da parte del lettore che verrà dopo e cercherà di capire il mio codice.

Un modo per provare a valutare il rapporto costi / benefici è aggiungere un commento al codice ottimizzato che lo renderà chiaro come versione leggibile. Se è troppo difficile spiegarlo bene in un commento, potrebbe essere troppo costoso.

Altri hanno coperto il "ciò che è buono / cattivo" - ecco un ulteriore punto che potrebbe essere stato perso:

I neofiti che grattano la testa sono buoni.

Per "novizio", intendo un nuovo programmatore. Non "nuova aggiunta alla squadra".

Ogni volta che un principiante si gratta la testa, impara qualcosa. Potrebbe dover chiedere a qualcun altro, ma alla fine lo imparerà. L'esempio che hai dato è leggibile da qualsiasi programmatore intermedio e insegnerà il fatto che "le condizioni all'interno di ifs possono essere usate direttamente per fare bool - quindi le dichiarazioni condizionali sono bool". Cosa abbastanza utile da sapere - ma AFAIK non ha mai veramente spiegato nei libri / corsi.