La brevità nello scrivere codice è vantaggiosa quando richiede l'uso di costrutti del linguaggio in modo strano [duplicato]

0

In C #, con i metodi di estensione, puoi sostituire questa riga di codice:

TimeSpan interval = TimeSpan.FromMinutes(4);

con questo:

TimeSpan interval = 4.Minutes();

Il metodo di estensione è:

public static TimeSpan Minutes(this int minutes)
{
    return TimeSpan.FromMinutes(minutes);
}

Il secondo esempio è interessante a causa del metodo di estensione sul letterale intero, che è valido, ma sembra strano (ancor più perché l'aggiunta di un punto dopo un letterale intero ha due significati diversi: diventare letterale doppio e accesso membro). Anche il secondo esempio si legge quasi come inglese (anche se il primo lo fa anche se in un modo diverso).

È una cattiva pratica usare le caratteristiche del linguaggio in modo tale da aumentare la brevità e la leggibilità, ma "abusare" della lingua? ( Preferisco le risposte che trattano PERCHÉ tu consideri una migliore dell'altra e non solo QUELLO CHE preferisci. )

Personalmente trovo il secondo modo più come il solito modo di pensare orientato agli oggetti in cui dichiari prima l'oggetto e poi accedi alla sua operazione membro per eseguire.

Analogamente a come facciamo con ToString :

StringBuilder str = new StringBuilder();

// ... append something to the builder

String result = str.ToString(); 

e non lo facciamo

Strong result = String.From(str);

Naturalmente, si potrebbe sostenere che questo è semplicemente il modo in cui è stata progettata l'API / Framework.

Nota aggiuntiva:

Questo può anche essere esteso ad altri esempi di conseguimento della brevità:

String str = String.Format("{0} + {1} = {2}", op1, op2, op3);

modificato in:

String str = "{0} + {1} = {2}".FormatWith(op1, op2, op3);
    
posta Kornelije Petak 26.01.2015 - 15:44
fonte

1 risposta

14

Is brevity in writing code beneficial when it requires using language constructs in a strange way?

Inferno no

La brevità non è un tratto desiderabile. Il tempo necessario per digitare il codice non è una cosa significativa da ottimizzare, dal momento che scriviamo il codice in modo non frequente rispetto a quello letto / debug / modificandolo. Il tempo impiegato dal parser per leggere il tuo codice (o la dimensione che prende sul disco) è banale.

Readability è un tratto desiderabile, ma non necessariamente segue che la brevità porta alla leggibilità. Dopotutto, il tempo dedicato alla comprensione di ciò che leggiamo non è principalmente dedicato alla visione di personaggi, ma alla loro analisi di significato. Fare cose strane richiederà lontano più a lungo per capire in generale. Questo è ben noto come Principio di almeno stupore (o Sorpresa) nei circoli di progettazione.

Ora a volte, l'uso di costrutti strani rende le cose più leggibili / efficienti / solide quando le persone le imparano e si abituano a loro. Questo è un compromesso come qualsiasi altro valore da valutare. Ma i tuoi esempi rendono tutte le cose difficili da leggere per non fare altro che salvare alcuni caratteri.

    
risposta data 26.01.2015 - 15:52
fonte

Leggi altre domande sui tag