Cutting Edge

Suggerimenti sulla leggibilità del codice sorgente

Dino Esposito Avete mai sentito del concorso internazionale di Obfuscated C codice? In poche parole, è un concorso aperto che seleziona un vincitore da una manciata di programmi in C che risolve un problema — qualsiasi problema — con un codice C estremamente oscuro e offuscato. Potete trovare il codice sorgente di vincere i programmi negli anni precedenti al ioccc.org/years.html.

Concorso codice C offuscato è un modo spensierato per dimostrare l'importanza dello stile e leggibilità nella programmazione. Questa colonna vuole riassumere alcune delle pratiche più importanti ti consigliamo di seguire per avere il codice che è facile da leggere e capire — sia per il tuo amor e quella dei tuoi colleghi.

Leggibilità come attributo

Nello sviluppo di software, la gestibilità è l'attributo che si riferisce alla facilità con cui è possibile modificare il codice esistente per raggiungere obiettivi come correggere un bug, pulizie, implementa una nuova funzionalità o solo per alcuni modelli di refactoring. Manutenibilità è uno degli attributi fondamentali del software, secondo la norma ISO/IEC 9126 carta. Per ulteriori informazioni sugli attributi del software, consultare il documento al bit.ly/VCpe9q.

Gestibilità del codice deriva da una varietà di fattori, uno dei quali è la leggibilità. Il codice che è difficile da leggere è anche difficile da capire. Gli sviluppatori che hanno messo le mani sul codice non chiaramente conoscere e capire rischiano di rendere il codice ancora peggio.

Purtroppo, la leggibilità è una questione estremamente soggettiva. Lo sviluppo di uno strumento automatico per controllare e segnalare il livello di leggibilità del codice è praticamente impossibile. Tuttavia, anche se la misurazione automatica leggibilità erano possibili, qualsiasi tali strumenti probabilmente sarebbe considerati altamente inaffidabili e non essere considerato attendibile da qualcuno. Alla fine, la leggibilità è un attributo manuale che singoli sviluppatori dovrebbero controllare insieme al resto del loro codice. La possibilità di scrivere codice che è facile da leggere dovrebbe essere parte della responsabilità culturale di singoli sviluppatori, estendendo il loro set di abilità.

In generale, la leggibilità è un attributo di codice può e deve imparare ad adottare proprio all'inizio della tua carriera di programmazione e di sviluppare e migliorare nel tempo. Come stile e buon design, leggibilità non dovrebbe essere riservata per esperti. Più importante, esso non dovrebbe essere rinviata al quando hai appena abbastanza tempo per esso.

Un approccio pragmatico per leggibilità

Produrre codice leggibile è una questione di rispetto per gli altri sviluppatori. Come utente StackOverflow una volta pubblicato, "dovrebbe sempre codice come se la persona che finisce per mantenere il vostro codice è uno psicopatico violento chissà dove si vive." Si deve anche considerare lo sviluppatore che finisce per mantenere che il codice, un giorno, potrebbe in realtà essere si.

Durante la lettura codice di altre persone, ci sono un paio di cose che si può impazzire. Un aspetto che rende difficile leggere il codice è strutture dati e algoritmi con nessun gol chiaro. Un altro aspetto è poco chiare strategie utilizzate in codice che sono difficili da determinare e non ben annotata attraverso i commenti. Ecco un esempio:

// Find the smallest number in a list of integers
private int mininList(params int[] numbers)
{
  var min = Int32.MaxValue;
  for (var i = 0; i < numbers.length; i++) {
    int number = numbers[i];
    if (number < min)
      min = number;
  }
  return min;
}

Anche se portato l'esempio in c# per chiarezza, devo ammettere che questo non è un pezzo di codice che ogni sviluppatore c# mai avrebbe considerato la scrittura. Il motivo è che con c# e Microsoft .NET Framework, si possono raggiungere molti degli stessi risultati utilizzando LINQ. Ho incontrato un codice simile a un progetto, tranne che è stato scritto in Java. Ad un certo punto, sono stato assunto a porta il codebase per il Framework .NET e c#.

Potrebbe anche venire attraverso codice come quello in un vero progetto di .NET. È possibile applicare alcune considerazioni di leggibilità senza perdere il vostro intento. La prima cosa che non funziona in quella funzione è il nome. La convenzione è discutibile. Il nome manca un verbo e utilizza una logica mista involucro. Qualcosa come GetMinFromList sarebbe stato probabilmente un nome migliore. Tuttavia, il punto più discutibile del codice è la qualificazione privato utilizzato nel nome.

Qualsiasi lettore occasionale di tale codice può vedere che la funzione serve come utilità. In altre parole, esso rappresenta un pezzo potenzialmente riutilizzabile del codice che è possibile chiamare da una varietà di posti all'interno del resto del codice. Pertanto, contrassegnandolo come privato non sempre ha senso. Tuttavia, gli sviluppatori sanno la potenza della regola YAGNI — Ain't intenzione bisogno esso — e, ragionevolmente, tendono a non esporre il codice che non è strettamente necessario.

L'autore di quel codice potrebbe aver previsto la funzione come potenzialmente riutilizzabili, ma non quando è stato scritto. È per questo che la funzione è stata scritta per essere facilmente trasformato in una funzione di supporto riutilizzabile, ma è stata contrassegnata privata per essere visibile solo all'interno della classe dell'host. Questa strategia di codifica potrebbe essere difficile da capire immediatamente per lettori esterni. Tuttavia, è solo una decisione che richiede poche righe di commenti per spiegare la sua motivazione. Se non Aggiungi commenti appropriati, non essere un buon cittadino del mondo di codificazione. Lettori, infine, dare un senso, ma spreca un paio di minuti e, peggio ancora, fa lettori alquanto ostile all'autore.

Regole pratiche di leggibilità

La leggibilità del codice è uno di quei soggetti cui importanza è ampiamente riconosciuto, ma non necessariamente formalizzato. Allo stesso tempo, senza alcuni formalizzazione, la leggibilità del codice è quasi un concetto vuoto. Nel complesso, si può avvicinare la leggibilità con la regola del tre di C: una funzione combinata di commenti, coerenza e chiarezza.

IDE strumenti sono molto più intelligenti oggi rispetto a pochi anni fa. Gli sviluppatori non hanno rigoroso bisogno di scrivere i file della guida e integrare la loro documentazione personalizzata nei progetti di Visual Studio . Descrizioni comandi vengono create automaticamente e ovunque da commenti. IDI moderni rendono così facile definire istituzionali commenti, tutto quello che dovete pensare è il testo e l'IDE farà il resto. Un commento istituzionale è il classico commento che aggiungerai a metodi e classi per fornire una descrizione sintetica degli obiettivi. Si dovrebbero scrivere questi commenti seguendo gli standard di piattaforma o linguaggio. Si devono anche considerare questi commenti obbligatorio per qualsiasi pubblico pezzo di codice creato.

Vietando commenti ovvi è un altro passo fondamentale sulla strada per una migliore leggibilità. Commenti ovvi basta aggiungere rumore e nessuna informazione rilevante. Per definizione, un commento è un testo esplicativo per ogni decisione che prendete nel codice che non è immediatamente evidente. Un commento dovrebbe essere solo una perspicace osservazione su un particolare aspetto del codice.

La seconda "C" è la coerenza. Ogni squadra ha bisogno di utilizzare le stesse linee guida per la scrittura di codice. È anche meglio se tali orientamenti sono utilizzati su base aziendale. Quando si tratta di linee guida, molti stop al punto di definire quali orientamenti dovrebbero essere e smettere di cercare di rendere il senso di ciò che è giusto e cosa è sbagliato. Oserei dire che giusto o sbagliato è un punto secondario rispetto all'importanza di fare sempre la stessa cosa nello stesso modo in tutto il codice.

Supponiamo per un momento che stai scrivendo una libreria di manipolazione di stringa. In diversi luoghi all'interno di questa biblioteca, sarà probabilmente necessario controllare se una stringa contiene una data sottostringa. Come sarebbe? In .NET Framework, così come il Java SDK, vi sono almeno due modi di raggiungere lo stesso risultato. È possibile utilizzare il metodo Contains o IndexOf. Questi due metodi, però, servono per scopi diversi.

Il metodo Contains restituisce una risposta booleana e appena ti dice se la sottostringa è contenuta all'interno di una data stringa. Il metodo IndexOf restituisce l'indice in base 0, dove si trova la stringa cercata. Se non vi è alcuna sottostringa, IndexOf restituisce -1. Dal punto di vista puramente funzionale, pertanto, è possibile utilizzare Contains e IndexOf per raggiungere gli stessi obiettivi.

Tuttavia, danno un messaggio diverso qualcuno leggendo il codice e le forze il lettore a prendere un secondo passa sul codice per vedere se c'è un motivo speciale per utilizzare IndexOf invece Contains. Un secondo singolo passaggio leggendo su una riga di codice non è un problema, naturalmente. Ma quando succede su un intero codebase di migliaia di righe di codice, hanno un impatto sul tempo e, successivamente, i costi. Che è il costo diretto di non avere codice altamente leggibile.

Un senso di coerenza del codice dovrebbe essere parte della vostra responsabilità innata. Come sviluppatore, si dovrebbe mirare a scrivere codice pulito la prima volta senza sperando di avere abbastanza tempo per ripulire più tardi. Come leader della squadra, si dovrebbero applicare orientamenti di consistenza codice attraverso criteri di archiviazione. Idealmente, si non dovrebbe consentire il check-in codice che non passa un test di coerenza.

L'ultima versione di ReSharper può essere un notevole aiuto nel rendere concreta questa idea. È possibile utilizzare questi strumenti da riga di comando gratis — un insieme autonomo di strumenti — per integrare i moduli di analisi della qualità del codice direttamente nel tuo integrazione continua (CI) o sistema di controllo di versione. Questi strumenti da riga di comando possono eseguire ispezioni codice in linea. Questo è lo stesso set di codice ispezioni è possibile eseguire vivono all'interno di Visual Studio con ReSharper installati per rilevare duplicati nel tuo codice. A seconda delle vostre caratteristiche di personalizzazione CI, potrebbe essere necessario avvolgere gli strumenti della riga di comando in un componente ad hoc. Per ulteriori informazioni su ReSharper, check out bit.ly/1avsZ2R.

La terza e ultima "C" della leggibilità del codice è chiarezza. Il codice è chiaro, se tu lo stile in modo che si legge bene e facilmente. Questo include annidamento e raggruppamento appropriato. In generale, istruzioni IF aggiungono un sacco di rumore al codice. A volte non si possono evitare istruzioni condizionali — un pilastro di linguaggi di programmazione — ma cercando di limitare il numero di istruzioni IF tiene sotto controllo l'annidamento e rende il codice più facile da leggere. Si potrebbe anche usare un se... ALTRO... SE... ALTRA struttura anziché istruzioni IF nidificate.

Alcune attività possono richiedere poche righe di codice e potrebbe essere difficile o solo inopportuno fare un refactoring del "Metodo di estrarre". In questo caso, è bene tenere queste linee in blocchi separati da righe vuote. Esso non cambia la sostanza del codice, ma mantiene il più facile da leggere. Infine, se stai cercando ispirazione su come stile di codice sorgente, date un'occhiata ad alcuni progetti open source.

Breve è meglio

Linee più lunghe rendono difficile per gli occhi umani di leggere. Ecco perché loro testo in colonne di stampa di giornali e riviste. Quando si tratta di codice, si dovrebbe fare lo stesso e limitare la lunghezza orizzontale delle linee sia lo scorrimento verticale dei metodi. Qual è la lunghezza ideale del corpo di un metodo? Generalmente, 30 linee dovrebbero essere un livello massimo che fa scattare un campanello d'allarme e suggerisce che si considera di refactoring. Infine, una buona organizzazione di cartelle di progetto e di corrispondenza tra le cartelle e gli spazi dei nomi spesso riflette una buona organizzazione degli elementi di codice individuale.

Quando si sollevano il tema della leggibilità e codice pulito, tu stai spesso esposti a un'obiezione comune — scrivendo codice pulito è difficile e richiede un sacco di tempo. Si dovrebbe cercare di neutralizzare questo punto di vista e ci sono due modi che è possibile. Uno è quello di utilizzare uno strumento di assistente di codice che consente di scrivere codice pulito suggerendo refactoring, ispezionando il codice per modelli cattivi e controllando per codice duplicato o morto. Se tutte queste caratteristiche può rendere accessibile, non hai davvero ci sono più scuse per non scrivere codice più pulito e leggibile. Codice assistente strumenti sono offerti dai fornitori principali. Raccogliere qualsiasi, ma sceglierne uno.

L'altro è dare risalto automiglioramento e l'atteggiamento dei vostri singoli sviluppatori di scrivere codice più pulito come una questione di pratica generale. Gli sviluppatori esperti di farlo bene. La capacità di sapere all'incirca quanto lontano sei dalla versione finale del codice e quindi veramente ripulirlo, è una caratteristica chiave che separa gli sviluppatori esperti dai meno esperti.

Dino Esposito ' co-autore di "Microsoft .NET: Architecting Applications for the Enterprise"(Microsoft Press, 2014) e" programmazione ASP.NET MVC 5"(Microsoft Press, 2014). Technical evangelist per .NET Framework e piattaforme Android a JetBrains e relatore a eventi del settore in tutto il mondo, Esposito condivide la sua visione del software presso software2cents.wordpress.com e su Twitter a /despos..

Grazie al seguente Microsoft esperto tecnico per la revisione di questo articolo: James McCaffrey