Siamo costretti a utilizzare Spartan programmazione su un progetto, con sgomento per tutti. Così ho capito, rende i metodi veramente brevi e gestisce prima i casi semplici. Ma vale davvero la pena che il prezzo del codice assomigli a qualcosa del concorso Obfuscated C Code?
Riesci a vedere che è utile per qualcosa?
Molti degli inquilini della programmazione Spartan mi sembrano un'ottima pratica. Ad esempio, mantenendo i metodi brevi, riducendo al minimo l'ambito delle variabili, riducendo al minimo il numero di parametri di un metodo o i metodi di una classe, ecc. Queste sono tutte cose buone e esattamente ciò che dovresti sforzarti.
Ma poi ci sono cose come riduzione del numero di caratteri , minimizzazione dei conteggi di token , ternarization (seriamente?), ecc. che non ha alcun senso.
Penso che il mio problema principale con esso sia esemplificato da questa citazione :
But, spartan programming is more than just a technical coding style, in that is has a single underlying, unifying principle---minimalism and simplicity taken to extremes.
Qualunque cosa "presa agli estremi" mi suona un campanello d'allarme.
Ora sembrava inquietantemente familiare. Anche la minimizzazione sui token, anche se non portata all'estremo. Io preferisco usare fname che filename, ad esempio, out per output, x per l'input di dati, n per conteggi, l per lunghezze e così via. lx sarebbe la lunghezza di x, la lunghezza di y, ... si ottiene la deriva.
Inoltre, poiché gestisco spesso serie di dati di grandi dimensioni in applicazioni scientifiche, utilizzo le strutture di indice in R molto. Quando scrivo tutti quegli indici, il codice mi fa male agli occhi. Quindi l'indice diventa id, o anche solo io.
Ancor più, le strutture di loop specifiche in R (la famiglia applicabile) richiedono spesso una dichiarazione di funzione all'interno della chiamata apply. In questi casi uso sempre x, y, z, ... Queste funzioni sono spesso una o due righe, quindi è chiaro da dove proviene e non ingombra lo schermo.
Non è una brutta cosa, se hai alcune convenzioni di denominazione coerenti con il codice completo e fornisci commenti per spiegare i nomi delle variabili più oscuri. Alla fine, mi rende più leggibile il codice di una lunga fila di cammelli che arrancano sullo schermo.
Questa è un'accentuazione della compattezza della C.
A nessuno interessa il tuo codice se non è corretto.
Se il tuo codice non è completo (gestisce ogni caso), allora ci sono sono bug.
Se non è compatto di quanto stai sprecando cicli di memoria o di clock (ottimizzazioni del compilatore a parte)
Nota che l'ordine qui è fondamentale. Il programma più compatto è raramente corretto. PER ESEMPIO.
void main() {
return 1;
}
Wow, in realtà programma in questo modo, non sapevo che avesse un nome. Direi che ne giova la leggibilità ma più in modo spaziale ... nel senso che non ti perdi in una zuppa di codice anche se hai poche righe che sono difficili da leggere.
Tuttavia, direi che quando ti abitui a certi costrutti trovi la tua strada più facile in meno tempo che all'inizio.
Leggi altre domande sui tag programming-practices methodology