Pourquoi est-il recommandé d'avoir une ligne vide à la fin d'un fichier source?

232

Certains outils de style de code le recommandent et je me souviens avoir vu des outils de ligne de commande unix avertir d'une ligne vide manquante.

Quel est le raisonnement pour avoir une ligne vide supplémentaire?

language-agnostic coding-style eof

— Petteri Hietavirta
source

7

Certains outils ne fonctionnent pas si le fichier ne se termine pas par une nouvelle ligne. C'est différent d'avoir une ligne vide à la fin (ce qui serait 2 nouvelles lignes).

— William Pursell

2

Voulez-vous dire une ligne vide ( \n\n) ou une nouvelle ligne \n?

— Ciro Santilli 郝海东冠状病六四事件法轮功

13

catle fichier sur un shell et vous saurez pourquoi. Si votre fichier fait apparaître l'invite de mon shell dans un autre endroit que celui qu'il devrait être (au début de la ligne), je vous détesterai probablement. ;)

— ThiefMaster

2

Je suis tombé sur cette vieille question et je ne peux tout simplement pas croire que chaque réponse unique tente de justifier les échecs et les lacunes d'autres outils et systèmes en disant que les codeurs modernes devraient ajouter un caractère qui n'a aucune valeur dans le code lui-même. Parlez de 5 singes dans une cage! :-D

— Amos M. Carpenter

1

Meilleures réponses (plus générales) concernant les fichiers texte en général :: stackoverflow.com/questions/729692/…

— Ruben Bartelink

188

De nombreux outils plus anciens se comportent mal si la dernière ligne de données d'un fichier texte ne se termine pas par une nouvelle ligne ou une combinaison retour chariot / nouvelle ligne. Ils ignorent cette ligne car elle se termine par ^ Z (eof) à la place.

— Ralph M. Rickenbach
source

1

Merci d'avoir répondu! Des exemples d'outils populaires qui pourraient présenter ce comportement?

— Nick Merrill

8

@NickM Presque tous les outils de ligne de commande POSIX / Unix qui prennent la saisie de texte ou lisent un fichier texte supposent une fin de ligne ( \n) à la fin du fichier. Plusieurs éditeurs de texte, comme Vim, et plusieurs compilateurs (notamment C ++ et Python) émettront des avertissements. (Dans le cas de C ++, la norme l'exige explicitement.)

— greyfade

5

Donc ce que vous dites c'est ... c'est un culte du cargo

— Jaykul

Pourtant, vous pourriez avoir du texte sur la dernière ligne, la question mentionne une ligne vide \n\n.

— jinawee

57

Si vous essayez de concaténer deux fichiers texte ensemble, vous serez beaucoup plus heureux si le premier se termine par un caractère de nouvelle ligne.

— user1809090
source

Quand avez-vous déjà concaténé des fichiers et n'avez pas la possibilité d'ajouter des sauts de ligne entre les deux pendant la concaténation?

— Rudey Il y a

38

Outre le fait qu'il s'agit d'une position de curseur plus agréable lorsque vous passez à la fin d'un fichier dans un éditeur de texte.

La présence d'une nouvelle ligne à la fin du fichier permet de vérifier simplement que le fichier n'a pas été tronqué.

— rsp
source

221

Le fichier pourrait être tronqué et vous ne le sauriez même jamais

— Simon Nickerson

Rien n'empêche un fichier d'avoir des sauts de ligne quelque part au milieu, et le fichier pourrait facilement être tronqué là.

— Rudey Il y a

26

Un argument peut également être fait pour les différences de nettoyage si vous ajoutez au fichier en suivant le même raisonnement que Pourquoi les virgules de fin sont-elles autorisées dans une liste?

Ce qui suit est copié (et coupé un peu) à partir de la ressource liée:

En changeant:

s = [
  'manny',
  'jack',
]

à:

s = [
  'manny',
  'jack',
  'roger',
]

implique seulement un changement d'une ligne dans le diff:

  s = [
    'manny',
    'jack',
+   'roger',
  ]

Cela bat le diff multiligne plus déroutant lorsque la virgule de fin a été omise:

  s = [
    'manny',
-   'jack'
+   'jack',
+   'roger'
  ]

— Mathias Bak
source

Les réponses de lien uniquement ne sont pas considérées comme utiles sur SO. Veuillez copier les informations pertinentes ici tout en conservant l'attribution.

— isherwood

17

La ligne vide à la fin du fichier apparaît pour que la lecture standard du flux d'entrée sache quand terminer la lecture, renvoie généralement EOF pour indiquer que vous avez atteint la fin. La majorité des langues peuvent gérer le marqueur EOF. Il est là pour cette raison d'autrefois, sous DOS, le marqueur EOF était la touche F6 ou Ctrl-Z, pour les systèmes * nix, c'était Ctrl-D.

La plupart, sinon la totalité, liront jusqu'au marqueur EOF afin que la fonction de lecture à partir de l'entrée de la bibliothèque d'exécution sache quand arrêter la lecture. Lorsque vous ouvrez le flux pour le mode Ajout, il effacera le marqueur EOF et l'écrira jusqu'à ce qu'une fermeture soit explicitement appelée dans laquelle il insérera le marqueur EOF à ce point.

Les outils plus anciens s'attendaient à une ligne vide suivie d'un marqueur EOF. De nos jours, les outils peuvent gérer la ligne vide et l'ignorer.

— t0mm13b
source

6

^ D n'était pas "le marqueur EOF". En appuyant sur ^ D, le shell fermait le côté écriture du tuyau à partir duquel le groupe de processus de premier plan lisait, de sorte qu'une lecture de ce tuyau renvoyait EOF. Il n'y a pas de "marqueur EOF".

— William Pursell

@William Pursell Vous avez confondu par erreur * NIX et Windows. Windows / DOS hérité utilisait absolument un marqueur EOF (26, 0x1a) incorporé généralement à la fin de la plupart des fichiers pour conserver la compatibilité avec l'ancien CP / M (Qui diable utilisait CP / M après 1983?). Autre "fun": \r\nau lieu de \n, les appels DOS utilisent un mélange de ASCIIZ et ASCII $. Pire encore, plus tard sous Windows, insérez généralement une marque d'ordre d'octet Unicode (BOM) au début de la plupart des fichiers texte. Belle "unicité".

9

De plus, lorsque vous modifiez un fichier et ajoutez du code à la fin du fichier - diff (au moins git diff dans la configuration standard) montrera que vous avez changé la dernière ligne, tandis que la seule chose que vous avez réellement fait - a ajouté un symbole de nouvelle ligne. Les rapports cvs deviennent donc moins pratiques.

— prijutme4ty
source

5

Certaines langues définissent leur fichier d'entrée en termes de lignes d'entrée, où chaque ligne d'entrée est une série de caractères terminée par un retour chariot. Si leur grammaire est ainsi définie, la dernière ligne valide du fichier doit également se terminer par un retour chariot.

— Damien_The_Unbeliever
source

3

C'est à cause de la définition de ce qu'est un fichier texte. Lorsque vous créez un nouveau fichier texte dans n'importe quel environnement Unix, le contenu de ce fichier est le nouveau caractère de ligne '\ n'

Sans cela, le fichier n'est pas vraiment identifié comme un fichier texte. Maintenant, une fois que nous avons ajouté du code à ce fichier texte, il s'agit de ne pas supprimer cette nouvelle ligne initiale qui définit un fichier texte lui-même .

— Victor Fernandes
source