2010-02-18 5 views
137

Alcuni strumenti di stile del codice lo raccomandano e ricordo di aver visto alcuni strumenti della riga di comando di Unix che avvertivano della mancanza di una linea vuota.Perché è consigliabile avere una riga vuota alla fine del file?

Qual è il ragionamento per avere una linea in più?

+5

Alcuni strumenti non riescono a lavorare se il file non termina con un ritorno a capo. È diverso dall'avere una linea vuota alla fine (che sarebbe 2 newline). –

+0

Gli editor di testo Gedit e Nano (e riferito a Vim) aggiungeranno una riga vuota ai documenti salvati. –

+1

Intendi riga vuota ('\ n \ n') o nuova riga' \ n'? –

risposta

110

Molti strumenti precedenti si comportano in modo anomalo se l'ultima riga di dati in un file di testo non viene terminata con una combinazione di ritorno a capo o nuova riga. Ignorano quella linea poiché viene terminata con^Z (eof).

+0

Grazie per la risposta! Qualche esempio di strumenti popolari che potrebbero mostrare questo comportamento? – cloudrave

+2

@NickM Quasi tutti gli strumenti da riga di comando POSIX/Unix che accettano l'input di testo o leggono un file di testo assumono una fine di riga ('\ n') alla fine del file. Diversi editor di testo, come Vim, e diversi compilatori (in particolare C++ e Python) emetteranno avvertimenti. (Nel caso di C++, lo standard richiede esplicitamente questo.) – greyfade

28

A parte il fatto che si tratta di una posizione del cursore migliore quando ci si sposta alla fine di un file in un editor di testo.

Avere una nuova riga alla fine del file fornisce un semplice controllo che il file non è stato troncato.

+151

Il file potrebbe essere troncato e non lo si potrebbe nemmeno annotare –

+1

La prima parte è corretta, la seconda parte non lo è. –

10

La riga vuota alla fine del file viene visualizzata in modo che la lettura standard dal flusso di input saprà quando terminare la lettura, in genere restituisce EOF per indicare che è stata raggiunta la fine. La maggior parte delle lingue può gestire il marcatore EOF. È lì per quel motivo dai vecchi tempi, sotto DOS, il marcatore EOF era F6 o Ctrl-Z, per i sistemi * nix, era Ctrl-D.

La maggior parte, se non tutti, leggerà effettivamente fino al marcatore EOF in modo che la funzione di lettura della libreria di runtime dall'input saprà quando smettere di leggere oltre. Quando apri lo stream per la modalità Append, cancellerà il marker EOF e lo scriverà, finché non verrà chiamata esplicitamente una chiamata in cui inserirà il marker EOF in quel punto.

Gli strumenti precedenti si aspettavano una linea vuota seguita dal contrassegno EOF. Oggigiorno, gli strumenti possono gestire la linea vuota e ignorarla.

+5

^D non era "l'indicatore EOF". Premendo^D, la shell chiudeva il lato di scrittura della pipa da cui stava leggendo il gruppo di processi in foreground, in modo che una lettura da quella pipe restituisse EOF. Non esiste un "indicatore EOF". –

+0

@William Pursell Hai confuso erroneamente * NIX e Windows. Legacy Windows/DOS utilizzava in modo assoluto un marcatore EOF (26, 0x1a) incorporato di solito alla fine della maggior parte dei file come mantenimento per compatibilità con CP/M (chi ha mai usato CP/M dopo il 1983?). Altro "divertimento": '\ r \ n' invece di' \ n', chiamate DOS che utilizzano un mix di ASCIIZ e $ ASCII. Ancor peggio, in seguito, in genere, Windows inserisce un byte order mark (BOM) Unicode all'inizio della maggior parte dei file di testo. Bella "unicità". – Barry

2

Alcune lingue definiscono il loro file di input in termini di righe di input, in cui ogni riga di input è una serie di caratteri terminata da un ritorno a capo. Se la loro grammatica è così definita, allora anche l'ultima riga valida del file deve essere terminata da un ritorno a capo.

7

Anche quando si modifica il file e si aggiunge del codice alla fine del file - diff (almeno git diff in configurazione standard) mostrerà che hai cambiato l'ultima riga, mentre l'unica cosa che hai effettivamente fatto - ha aggiunto un simbolo di nuova linea. Quindi i rapporti sui CV diventano meno convenienti.

21

Se si tenta di concatenare due file di testo insieme, si sarà più felici se il primo termina con un carattere di fine riga.