Quali sono i lati negativi della combinazione di tabulazioni e spazi? [duplicare]

1. Il primo lato negativo è che diventa rapidamente un disastro.

Una delle estensioni di Visual Studio più utilizzate è Productivity Power Tools. Questa estensione ha un'opzione che avvisa una persona quando il file utilizza sia le schede che gli spazi e suggerisce di sostituire le schede per spazi o spazi per schede.

Questo perché quando apri un file non hai alcun indizio visivo se usa spazi o tabulazioni. Uno sviluppatore utilizzerà solo schede, un altro sviluppatore - solo spazi, incluso per il rientro e un altro utilizzerà entrambi, come suggerito.

Quando quei tre sviluppatori lavoreranno insieme, dato che usano tutti uno stile diverso, un quarto sviluppatore non avrebbe alcun indizio se si dovessero usare tab o spazi e quando.

2. Il secondo lato negativo è che gli IDE di oggi non sono fatti per quello.

Invece di risolvere, come credi, il problema reale, lo aumenterà solo.

Immagina il pezzo di codice ben indentato / allineato usando la tua convenzione:

 →  Some code here(firstArgument,
 →  ···············secondOne,
 →  ···············andTheLast);

In realtà, in pratica, ciò che può accadere è:

 →  Some code here(firstArgument,
 →   →   →   →  ···secondOne,
 →   →   →   →  ···andTheLast);

perché, onestamente, riesco a malapena a vedermi mentre leggo ripetutamente il tasto Spazio, così come determinare esattamente il momento in cui dovrei smettere di mettere le schede e iniziare a usare gli spazi (cioè una scheda, quindi spazi).

Dopo alcune modifiche, lo stesso codice potrebbe diventare rapidamente:

 →  Some code here(firstArgument,
 →   →   →   →  ···secondOne,
 →   →   →  ·······modified);

Ora, quando qualcuno aprirà il file in un IDE in cui una scheda è uguale a due spazi anziché quattro, è ciò che vedrà:

→ Some code here(firstArgument,
→ → → → ···secondOne,
→ → → ·······modified);

in altre parole:

  Some code here(firstArgument,
           secondOne,
             modified);

3. Infine, il problema non esiste in primo luogo.

Si presume che il primo argomento dovrebbe essere sulla stessa linea del metodo stesso. Ma il modo più semplice sarebbe semplicemente mettere tutti gli argomenti su una nuova riga quando sono troppo lunghi. Il codice sopra può semplicemente essere scritto in questo modo:

 →  Some code here(
 →   →  firstArgument,
 →   →  secondOne,
 →   →  andTheLast);

Vedi? È tutto allineato e non importa quanti spazi misura la tabulazione.

Conclusione:

La formattazione dovrebbe essere il compito dell'IDE. Gli sviluppatori hanno già abbastanza lavoro per preoccuparsi della dimensione delle schede, di quanto spazio inserirà un IDE, ecc. Il codice dovrebbe essere formattato correttamente e visualizzato correttamente su altre configurazioni, senza costringere gli sviluppatori a pensare a esso.

Introducendo la convenzione in cui le schede vengono utilizzate per il rientro e gli spazi, per l'allineamento, si riduce il compito di occuparsi degli spazi delle schede / degli spazi dagli IDE agli sviluppatori. È sbagliato.

In linea di principio, non c'è niente di sbagliato nell'usare tabulazioni per il rientro del blocco e spazi per un ulteriore allineamento.

Tuttavia, ci sono alcuni problemi pratici:

• Credo che ci siano editor che cercano di essere utili e sostituiranno gli spazi X con una scheda se sanno che vuoi usare le schede per i rientri.
• Hai bisogno di una sola persona nel team con un editor configurato in modo improprio per far finire tutto in un grande casino

per questi motivi, è praticamente impossibile creare un layout coerente in un code-base che utilizzi schede per il rientro e spazi per il layout, quindi la maggior parte dei team si limita a uscire e richiede solo spazi. La maggior parte degli editor di programmazione può essere configurata per inserire un numero di spazi se si preme il tasto < Tab > chiave, quindi come programmatore puoi ancora usare quella chiave per ottenere il rientro richiesto.

what is wrong with

...using tabs for indentation where everyone can set their own preferred width ...using spaces for aligning multi-line code where the width does matter

Non c'è niente di sbagliato in questo; in effetti, è la soluzione migliore per la guerra "tabs vs. spaces", perché, come hai già scoperto, consente una profondità variabile del rientro del blocco per le persone che lo desiderano (tramite l'impostazione della larghezza della tabulazione), mantenendo costante la coerenza formattazione all'interno del blocco (come è sempre più richiesto o almeno strongmente raccomandato dalle guide di stile del linguaggio, ad esempio PEP8 per Python).

C'è davvero solo una risposta giusta qui, e questo è che se sei un programmatore devi usare un IDE appropriato o un editor che deve essere usato dai programmatori per modificare il codice. Le persone che utilizzano Blocco note o Nano e rientrano a mano sono un caso limite. Eclipse, Emacs, Vim e XCode possono essere impostati automaticamente sul codice di rientro tramite il metodo "tabulazioni per blocchi, spazi per allineamento di istruzioni multilinea". Funziona praticamente per tutte le lingue tranne Python, dove PEP8 dice che "tutti gli spazi e nessuna tabulazione" sono preferiti (quindi non c'è bisogno di discuterne neanche lì).

Preferisco Emacs, ma non lo forzerei su altri sviluppatori che hanno già uno strumento con cui sono a loro agio, purché lo strumento possa svolgere il lavoro . Le persone che trasformano le schede e gli spazi "discutono" in un editore di guerra santa, mancano il punto. Se stai indentando a mano, stai facendo male. Periodo. Se altre persone non riescono ad aprire il tuo codice nel loro editor senza che la formattazione sia rovinata, lo stai facendo anche tu. Questo dovrebbe essere semplice, e è se usi gli strumenti giusti per il lavoro. Siamo programmatori, dopo tutto - la configurazione di un editor dovrebbe essere un gioco da ragazzi rispetto ad alcuni dei cerchi mentali che dobbiamo affrontare ogni giorno sul lavoro.

"Il vantaggio dell'utilizzo delle schede per il rientro è che le persone possono configurare il proprio editor in modo da utilizzare la larghezza del tab con cui si trovano a proprio agio."

Questo non è necessariamente vero. Ad esempio, prova a configurare l'editor di domande e risposte Stack Exchange (che viene spesso utilizzato come editor di codice, invece di copiare codice nell'editor di codice reale, modificarlo, quindi incollarlo in SE) per una larghezza specifica della tabulazione ... Ci sono modi troppe (newbie) domande soprattutto su SO, dove il codice sorgente incollato contiene schede e spesso risulta un pasticcio.

Questo è un esempio di cosa c'è di sbagliato nell'usare le schede in generale. Più spesso c'è una situazione in cui sarà una seccatura, quando il codice sorgente diventa un disastro. Di conseguenza, l'intera questione sulla combinazione di spazi e schede è in qualche modo discutibile, IMO. Usa gli spazi e la vita è più facile per tutti .

Questo è davvero un peccato. Sarebbe così elegante se "una tabulazione indica un livello di indentazione, la larghezza della tabulazione non è specificata" la regola è stata universalmente rispettata. Ma ci sono degli stili di indentazione "denominati" comuni che lo hanno? Esistono editor in cui è possibile fare esplicitamente questo, invece di dover specificare il passo di indentazione negli spazi e quindi la larghezza delle tabulazioni negli spazi, separatamente?

Ho imparato EMACS nel 1983 e ho liberamente mescolato tab e spazi fino a LAST YEAR, quando un giovane programmatore mi ha spiegato gli errori dei miei modi. Abbiamo avuto una riunione di gruppo e abbiamo cambiato la nostra politica per eliminare le schede nel nostro codice sorgente.

Ecco perché:

• Sì, puoi mescolare liberamente schede e spazi e editor di alta qualità come EMACS gestiscono perfettamente. EMACS ha correttamente uno spazio di hacking-back che uccide una scheda e la trasforma in 7 spazi. La modalità di rientro EMACS comprende che è opportuno utilizzare 4 spazi per indentare un po ', quindi una scheda, quindi una scheda e 4 spazi, quindi 2 schede, ecc.
• Tuttavia, c'erano un gran numero di programmatori WINDOWS che non avevano il vantaggio di EMACS negli anni '90. Il loro unico strumento con Visual Studio e rientrato in TABS. L'indentazione di C con 8 spazi è stupida, quindi hanno cambiato il loro tabstop in 4. Questo funziona, ma quando si porta il codice in un editor in formato tab, sembra orribile.
• Anche se gli spazi sono uniformemente 1 spazio, la discusione sopra rende chiaro che non si può dipendere dal sistema dell'altro programmatore per essere configurato correttamente.

Quindi abbiamo esaminato tutto il nostro codice e IMPOSTABILE. Oh, l'orrore. Oh, vergogna.

Ora abbiamo questa piccola riga nella parte superiore di ciascuno dei nostri file C:

/* -*- mode: C++; c-basic-offset: 4; indent-tabs-mode: nil -*- */