Crea una nuova variabile per abbreviare il codice

Naviga le tue risposte
5

Mi sono spesso chiesto quali sono le implicazioni dell'accorciamento del codice assegnando variabili temporanee con nomi più brevi agli accessi ai dati con nomi lunghi. È meglio illustrato da un esempio (in Ruby, ma non che importi):

Questo lungo codice è brutto, IMO: 

# Trim the description to MAX_LENGTH characters followed by "..."
# if the description is MAX_LENGTH characters or longer
def shorthand_description
    return (some_object.nested_hash.description.length >= MAX_LENGTH)
           ? "#{some_object.nested_hash.description[0..MAX_LENGTH]}..."
           : some_object.nested_hash.description
end

Questo sembra essere molto più leggibile: 

def shorthand_description
    desc = some_object.nested_hash.description
    return (desc.length >= MAX_LENGTH)
           ? "#{desc[0..MAX_LENGTH]}..."
           : desc
end

Personalmente ho quasi sempre delle variabili di stenografia se la catena di accesso lunga è più di 20 caratteri e viene ripetuta. Sta creando una variabile solo per rendere il codice più leggibile accettabile? Dipende dalle linee guida di stile per la lingua o è un concetto indipendente dalla lingua?

    
posta Chris Cirefice 23.06.2016 - 05:15
fonte

2 risposte

4

(La mia risposta ignora gli effetti dell'ottimizzazione - presumo che ci sia una macchina che elabora il codice che può fare un'ottimizzazione decente in modo che la variabile extra creata per la leggibilità non faccia la differenza nelle prestazioni.)

Nella mia esperienza, scrivi il tuo codice per essere compreso. Un nome breve e significativo è decisamente più accettabile che ripetere una stringa di caratteri troppo lunga, qualunque sia la lingua. Quando ritorni al codice di nuovo in una settimana / mese / anno, apprezzerai quel piccolo tocco di chiarezza che hai aggiunto per aiutarti a capirlo meglio.

Detto questo, se stai migliorando il codice esistente, segui le convenzioni già in uso. Se il tuo codice sembra troppo "diverso" senza una buona ragione, sarà difficile per la persona che lo guarda accanto capire perché. E se le convenzioni sono davvero terribili e inquietanti, rifatta il codice (assicurati che ci siano test) o almeno aggiungi un commento davvero buono che spiega cosa sta succedendo. Questo non è il 1960 quando lo storage era troppo costoso per permettersi di chiarire i commenti nel codice sorgente.

La regola migliore: scrivi il tuo codice come se il prossimo sviluppatore assegnato a lavorare su di esso fosse veramente meschino e arrabbiato e conoscesse il tuo indirizzo di casa.

    
risposta data 23.06.2016 - 06:58
fonte
4

When you see a good move, look for a better one.
—Emanuel Lasker, 27-year world chess champion

È un ottimo miglioramento della leggibilità, ma cerca sempre la mossa migliore. In questo caso, è probabile che si coprano i problemi con le responsabilità che si trovano fuori luogo. Il principio di cercare di evitare quelle catene di identificatori ha il suo nome: la Legge di Demetra .

Forse questo si adatterebbe meglio come description.shorthand() , o come truncate_to_length(string, length) . Sì, ci sono eccezioni ad ogni regola, come quella pagina C2 che ho linkato a spiegare, ma se questo è un evento normale, probabilmente stai introducendo un sacco di accoppiamento non necessario nella tua architettura.

    
risposta data 23.06.2016 - 08:44
fonte

Leggi altre domande sui tag

Quanto è aggressivo cambiare il puntatore intelligente interno a unique_ptr? Che cosa viene prima: il diagramma di attività o il diagramma di sequenza?