Perché una lingua dovrebbe preferire l'indentazione rispetto ai marcatori espliciti per i blocchi?

Guido Von Rossum

Da un colloquio con Guido Van Rossum , che può essere visto in documento con books.google.com (sottolineatura mia):

The choice of indentation for grouping was not a novel concept in Python; I inherited this from ABC, but it also occurred in occam, an older language. I don't know if the ABC authors got the idea from occam, or invented it independently, or if there was a common ancestor. Of course, I could have chose not to follow ABC’s lead, as I did in other areas (e.g., ABC used uppercase for language keywords and procedure names, an idea I did not copy), but I had come to like the feature quite a bit while using ABC, as it seemed to do away with a certain type of pointless debate common amongst C users at the time, about where to place the curly braces.

Von Rossum è stato strongmente ispirato da ABC , e anche se lui non ha dovuto copiare tutto questo , l'uso di indentazione è stato mantenuto perché potrebbe essere utile per evitare guerre di religione.

I also was well aware that readable code uses indentation voluntarily anyway to indicate grouping, and I had come across subtle bugs in code where the indentation disagreed with the syntactic grouping using curly braces—the programmer and any reviewers had assumed that the indentation matched the grouping and therefore not noticed the bug. Again, a long debugging session taught a valuable lesson.

Rossum anche assistito bug a causa di incoerenza tra raggruppamento e trattino, ea quanto pare però che basandosi su rientro solo per strutturare il codice sarebbe stato più sicuro da errori di programmazione ¹ .

Donald E. Knuth & Peter J. Landin

Nell'intervista referenziata, Guido menziona l'idea di Don Knuth di usare l'indentazione. Questo è dettagliato nella Il Knuth rientro Citazione ritrovata , che cita Programmazione strutturata con istruzioni goto . Knuth fa riferimento anche a dei prossimi 700 linguaggi di programmazione di Peter John Landin (vedere la sezione Discussione riguardo all'indentazione). Landin ha progettato ISWIM che sembra la prima lingua con indentazione al posto dei blocchi inizio / fine. Questi articoli riguardano più la possibilità di utilizzare il rientro per strutturare i programmi piuttosto che gli argomenti reali a favore di farlo.

_{1. Penso che questo sia in effetti un argomento in favore di avere entrambi i costrutti di raggruppamento e la formattazione automatica, al fine di catturare e recuperare da errori di programmazione, che sono tenuti ad accadere. Se rovini il tuo rientro in Python, la persona che esegue il debug del tuo codice dovrà indovinare quale sia corretta:}

if (test(x)):
  foo(x)
  bar(x)

_{Shall bar viene sempre chiamato o solo se il test ha esito positivo?}

_{I costrutti di raggruppamento aggiungono un livello di ridondanza che consente di individuare un errore durante l'indentazione automatica del codice. In C, il codice equivalente può essere autoindentato come segue:}

if (test(x))
  foo(x);
bar(x); 

_{Oops, voglio che bar sia allo stesso livello di foo , aggiungiamo le parentesi .}

Questo è molto soggettivo e causa di molte fiamme. Tuttavia:

Avere simboli che delimitano i blocchi e indentazione viola il principio DRY , poiché esprimi le stesse informazioni in due modi diversi. L'esistenza di strumenti di indentazione automatica è un sintomo di questa violazione DRY: che è possibile generare automaticamente il rientro mostra che si tratta di informazioni ridondanti e significa che il rientro e i simboli possono uscire dalla sincronizzazione che portano a codice fuorviante.

Le Domande frequenti su Design e Cronologia di Python lo dicono molto chiaramente:

Why does Python use indentation for grouping of statements?

Guido van Rossum believes that using indentation for grouping is extremely elegant and contributes a lot to the clarity of the average Python program. Most people learn to love this feature after a while.

Since there are no begin/end brackets there cannot be a disagreement between grouping perceived by the parser and the human reader.

È vero che non è possibile creare uno strumento di indentazione automatica per Python, ma questa è una buona cosa: significa che non si dispone di ridondanze nella sintassi per cui è necessario riconciliare gli strumenti automatici.

Le tabulazioni e gli spazi sono una preoccupazione legittima in Python e si consiglia di non mischiare mai tabulazioni e spazi (per i rientri) nella stessa base di codice.

Python ha ereditato l'indentazione significativa dal linguaggio predecessore (ora obsoleto) ABC. ABC è uno dei pochissimi linguaggi di programmazione che hanno utilizzato test di usabilità per dirigere il design. Quindi, mentre le discussioni sulla sintassi di solito si riducono a opinioni soggettive e preferenze personali, la scelta di indentazione significativa ha in realtà una base più solida.

I designer di lingua scelgono spazi bianchi sintatticamente significativi perché credono (o almeno pensano che i loro potenziali utenti credano) che il punto e virgola aggiungono rumore durante la lettura del codice, danneggiando la produttività. Un altro motivo comune è che uno stile di codifica errato / incoerente nuoce alla leggibilità: forzando uno schema di indentazione comune, il linguaggio ha una migliore leggibilità complessiva. Quella successiva è meno importante ora che gli IDE di formattazione automatica sono più comuni, ma possono ancora essere applicati.