Quali sono i vantaggi e gli svantaggi di una lingua che utilizza spazi bianchi rispetto a {} per indicare l'ambito? [chiuso]

Sembra esserci un conflitto sul fatto che sia meglio usare spazi bianchi o token come parentesi quadre per indicare l'ambito. Ho visto molti elogiare la soluzione di Python al problema del rientro incoerente, ma molti non sono d'accordo:

Qualsiasi lingua che abbia spazi bianchi come token deve morire.

postato più tardi sulla stessa risposta:

Ero una specie di anti-spazio-come-token, fino a quando non l'ho provato. Probabilmente mi ha aiutato il fatto che il mio layout personale di spazi bianchi corrisponda praticamente a quello che usano tutti in pitone-terra. Forse è che sono un po 'minimalista, ma se intendi comunque rientrare, perché preoccuparsi dei {} s?

Vedo alcuni argomenti chiari per ciascuna parte:

usando gli spazi bianchi:

• aiuta a ridurre il rientro incoerente nel codice
• cancella lo schermo sostituendo i token visibili con spazi bianchi per servire allo stesso scopo

usando i token:

• molto più facile tagliare e incollare il codice su diversi livelli (non è necessario correggere il rientro)
• più coerente. Alcuni editor di testo visualizzano gli spazi in modo diverso.
• più popolare attualmente.

Ci sono dei punti che ho perso? Quale preferisci? Qualche parola di saggezza dopo aver lavorato con l'uno o l'altro per molto tempo?

PS. Lo odio quando le lingue non usano lo stesso token per ciascuna struttura di controllo. VB è davvero fastidioso con le sue End Ife le sue End Whiledichiarazioni, la maggior parte delle altre lingue usa {} per tutto. Ma forse questo è un argomento per una domanda diversa ...

Penso che molti di noi programmatori (me compreso) abbiano la tendenza a "logizzare" ogni decisione. Va bene, ma non tutte le domande hanno una risposta logica. Ad esempio, dubito che gli chef postino domande sul chefoverflow (se esiste una cosa del genere) chiedendo i pro ei contro della torta di mele contro la torta di ciliegie. È una domanda di cui ti piace di più.

Con questo in mente, penso che la risposta più semplice sia dire "Ad alcune persone piacciono le parentesi graffe, ad altre persone piacciono gli spazi bianchi" e lasciarlo.

A rischio di sembrare un fanboy assoluto, penso che tutti coloro che sostengono che gli spazi bianchi "aiutano a ridurre il rientro incoerente nel codice" non abbiano mai usato Visual Studio. Con un singolo comando (penso che il collegamento predefinito sia Ctrl + K, D), tutta la rientranza è istantaneamente coerente¹. Inoltre, quando si incolla il codice, il rientro viene istantaneamente corretto senza dover fare nulla, e lo stesso vale quando si scrive un nuovo codice o si avvolge qualcosa in uno ifo qualche altro blocco (il riformattazione avviene mentre }viene digitato). Inoltre, premendo Invio dopo un'istruzione completata posiziona sempre il cursore sul livello di rientro corretto per l'istruzione successiva, anche se l'istruzione precedente è stata indentata ulteriormente a causa di unifo simili, rendendo molto difficile pensare accidentalmente che un'affermazione sia ancora sotto un ifquando non lo è.

Il punto che sto cercando di sottolineare non è che Visual Studio sia eccezionale. Il punto che sto cercando di sottolineare è che l'IDE può automatizzare la correzione del rientro (e altri problemi di formattazione), ma solo se il significato del programma non dipende dalla sua formattazione. Ciò offre al programmatore una maggiore opportunità di concentrarsi sull'attività di programmazione effettiva. Una sintassi come quella di Python è controproducente: non è possibile scrivere un IDE in grado di "correggere" l'indentazione del codice Python perché l'indentazione stessa specifica parte della semantica.

¹ _{(So ​​che esiste un caso speciale in cui VS rifiuta di riformattare, vale a dire letterali array che si estendono su più righe, ma non è questo il punto.)}

Personalmente trovo che ho bisogno della linea vuota introdotta da un token sulla sua stessa linea per farmi capire che il codice è in un altro ambito.

Lo odio quando in Python la gente va:

if something
    do something
    do somethingelse

    cleanup
else
    do the other thing

mentre in terra simbolica odio quando le persone copiano e incollano e non puliscono il rientro ,

if something
{
I have been too lazy
      {
            to clean up
            }
what I pasted
}

o non utilizzare una linea separata per il token .

if something {
    I find this confusing
}
else {
especially when combined with the previous 
do something
}

Riesco a leggere tutti e tre, ma non sono come mi aspetto e devo fare uno sforzo per analizzarli e come dice Joel quando le cose non funzionano come ti aspetti ti rendono frustrato.

Pro: Non ci sono guerre sante di indentazione / collocazione di parentesi graffe nel mondo Python per quanto ne so. Prendere questa decisione per conto degli sviluppatori ha probabilmente risparmiato un po 'di dolore.

Contro: le funzioni anonime sono limitate a una riga. Suona bene, ma mi trovo spesso a scrivere più righe lambdain Scheme (principalmente per alimentare mapo applyesattamente in un posto, quindi non avrebbe senso dichiararlo separatamente).

{} aggiunge ridondanza. Troppa ridondanza è male, troppo pochi è male. E entrare manualmente è male, esp. se è difficile usarlo.

Quindi, in tempi di IDE scadente / assente, lo stile degli spazi bianchi potrebbe essere leggermente migliore. Ma con l'IDE potente, le parentesi graffe sono migliori.

Il problema che ho riscontrato con un linguaggio di spazi bianchi era con espressioni condizionali multipagina. L'aggiunta di una riga nel mezzo della pagina due e la rimozione di uno spazio nel mezzo di ogni pasticcio, possono alterare drasticamente la logica del codice. E anche se il codice di qualcuno è "corretto", provare a leggerlo rende un gioco d'ipotesi terribile. A quale "if" serve questo 'altro'? Riesco a contare le parentesi graffe molto più facilmente di quanto riesca a contare caratteri vuoti invisibili. E i macchinari di pubblicazione su questo sito continuano a frantumarli in un unico spazio.

IMHO "{{{{{" is more reliable than "     ".

Non penso sia davvero un versetto .
I pitoni spesso criticano i programmatori di parentesi graffe come se volessero facilmente violare il rientro perché possono.
In effetti, ho sempre usato un rientro coerente al 100% ancor prima di conoscere Python e il suo ambito di rientro.

Il fatto è che le parentesi graffe potrebbero anche imporre il rientro corretto nel compilatore e avremmo il meglio di entrambi i mondi. Vedere? nessun rispetto a tutti.

I pitoni sostengono che le parentesi graffe sono inutili quando il rientro fa parte della sintassi, ma non lo sono, le parentesi graffe migliorano la leggibilità. Ho provato a programmare Python ed è un linguaggio molto interessante per me, ma hai provato ad avere if-elifcatene con più di 2 o 3 livelli di rientro? non sembrano più così ordinati.

PS: ho scritto parentesi graffe, ma in modo più generale intendo i token delimitatori. Il tutore iniziale può essere visto come ridondante, ma una lingua potrebbe andare così (in effetti sono sicuro che ci sono lingue esattamente come questa ma non le conosco bene):

if condition:
    statement
    other_statement()
end

PS2: 2019, 4 anni dopo questa risposta. Ho imparato Python e mi sono completamente abituato alla sua rientranza semantica e non trovo affatto difficile leggere. Soprattutto con l'aiuto di moderni IDE che disegnano barre verticali per identificare blocchi di rientro.