Vide la nouvelle ligne à la fin des fichiers source Java

Dans mon projet actuel, nous insérons toujours une nouvelle ligne vide à la fin des fichiers source Java. Nous imposons également ceci avec CheckStyle (avec le niveau d’erreur).

Je cherchais ce sujet depuis longtemps, mais malheureusement je ne trouve aucune raison convaincante à cela. Semble que les autres développeurs sont assez indifférents à ce sujet car ils ont juste coché une case à cocher dans eclipse formatter et c’est fait automatiquement. Mais je ne sais toujours pas pourquoi il est nécessaire et pourquoi cela peut être important. Donc ma question est:

Pourquoi les lignes vides à la fin des fichiers sources Java sont-elles nécessaires? Est-ce un besoin actuel ou une relique du passé et indésirable dans les bases de code actuelles?

Je pense qu’ils essaient de s’assurer que chaque fichier se termine par un caractère de nouvelle ligne. C’est différent de se terminer par une ligne vide, autrement dit une nouvelle ligne vide.

Edit: Comme @Easy Angel l’a clarifié de manière succincte dans les commentaires: trailing newline = “\ n” et ligne vide = “\ n \ n”

Je pense soit:

  1. Votre rôle principal est soit de forcer chaque fichier à se terminer par un caractère de nouvelle ligne, mais il est interprété à tort comme obligeant chaque fichier à se terminer par une ligne vide (une ligne vide se terminant par une nouvelle ligne).

  2. ils essaient de s’assurer que chaque fichier se termine par un caractère de nouvelle ligne en imposant à chaque extrémité de fichier une ligne vide (ligne vide qui se termine par une nouvelle ligne), garantissant ainsi que les fichiers se terminent par une nouvelle ligne (et éventuellement nouvelle ligne supplémentaire). ?).

A moins que l’éditeur ne montre des symboles de nouvelle ligne, il n’est pas toujours clair dans certains éditeurs qu’un fichier:

  1. NE TERMINE PAS une nouvelle ligne,
  2. FIN avec une seule nouvelle ligne de suivi, ou
  3. FIN avec une nouvelle ligne vierge, soit 2 nouvelles lignes

Je pense que la plupart des éditeurs de code source modernes insèrent une nouvelle ligne. Cependant, en utilisant des éditeurs plus anciens, j’essayais toujours de m’assurer que mes fichiers de code source (et les fichiers texte en général) se terminaient toujours par une nouvelle ligne (qui apparaissait parfois comme une ligne vide / ligne vide selon l’éditeur). en utilisant) parce que:

  1. Si vous utilisez cat pour afficher le fichier sur la ligne de commande, si le fichier ne contient pas de nouvelle ligne, la sortie suivante (comme l’invite du shell ou un délimiteur visuel généré par un script entre deux fichiers) apparaîtra juste après la dernière ligne personnage plutôt que de commencer sur une nouvelle ligne. En général, la nouvelle ligne de suivi rendait les fichiers plus conviviaux pour les utilisateurs et les scripts.

  2. Je crois que certains éditeurs (je ne me souviens d’aucun détail) insèrent automatiquement une nouvelle ligne si le fichier texte en manque. Cela donnerait l’impression que le fichier a été modifié. Si vous ouvrez un tas de fichiers dans différentes fenêtres et que vous les fermez tous, cela devient déroutant – l’éditeur vous invite à enregistrer, mais vous n’êtes pas sûr d’avoir apporté de “véritables changements” au fichier ou seulement nouvelle ligne insérée.

  3. Certains outils comme diff et certains compilateurs vont se plaindre d’une nouvelle ligne manquante. C’est plus de bruit que les utilisateurs et les outils peuvent avoir à traiter.


Modifier:

A propos des éditeurs qui ajoutent des nouvelles lignes et ne peuvent pas voir s’il y a une nouvelle ligne ou une nouvelle ligne vide à la fin du fichier, je viens de tester Vim, Eclipse et Emacs (sur mon système Windows avec Cygwin): h ” e ” l ” o ‘et enregistré sans appuyer sur [ENTER]. J’ai examiné chaque fichier avec od -c -t x1 .

  1. Vim a ajouté une nouvelle ligne.
  2. Emacs a ajouté une nouvelle ligne de suivi.
  3. Eclipse n’a PAS ajouté de nouvelle ligne.

Mais

  1. Vim ne m’a pas permis de descendre vers une ligne blanche sous “bonjour”.
  2. Emacs m’a permis de descendre à une ligne vide sous “salut”.
  3. Eclipse ne m’a pas permis de descendre vers une ligne vide sous “hello”.

Interprète comme tu veux.


Ma pratique personnelle est d’essayer de s’assurer que les fichiers texte se terminent par une nouvelle ligne. Je pense qu’il y a la moindre surprise pour les gens et les outils avec ceci est le cas. Je ne traiterais pas les fichiers sources différemment des fichiers texte à cet égard.

Google lance ceci :

qui, à la date de cette édition, montre des alertes sur des nouvelles lignes manquantes provenant des compilateurs C, svn (à cause de diff), diff, etc. Je pense que les fichiers texte (fichiers sources inclus) se terminent par une nouvelle ligne traînant et moins surprenante (et moins bruyante) quand ils ont tendance à être là.

Finalement c’est intéressant:

Désinfection des fichiers sans nouvelle ligne de fin
Toutes les lignes des fichiers texte doivent être terminées par des caractères de nouvelle ligne (c.-à-d. \ N). Ceci est indiqué par POSIX, qui dit qu’un fichier texte est

Un fichier qui contient des caractères organisés en zéro ou plusieurs lignes.
Une ligne, à son tour, est définie comme
* Une séquence de zéro ou plusieurs non-caractères plus un caractère de fin.


Cependant , tout cela dit, ceci est juste ma pratique personnelle. Je suis heureux de partager mon opinion avec tous ceux qui le demandent, mais je ne mets cela sur rien. Je ne pense pas que ce soit quelque chose qui mérite d’être obligé, comme je le dis ici :

Bien que je sois l’un de tous pour la cohérence, je suis aussi contre la microgestion de chaque style. Avoir une liste énorme de conventions de codage, en particulier lorsque certaines d’entre elles semblent arbitraires, fait partie de ce qui décourage les gens de les suivre. Je pense que les directives de codage devraient être rationalisées pour les pratiques les plus précieuses qui améliorent les services. Dans quelle mesure la lisibilité, la maintenabilité, la performance, etc. sont-elles améliorées en imposant cette pratique?

Voici une bonne raison d’avoir un saut de ligne supplémentaire à la fin:

Si vous avez un fichier sans saut de ligne à la fin, la prochaine fois que le fichier est modifié pour append une autre ligne, la plupart des outils de fusion penseront que la ligne existante a été modifiée (je suis sûr à 90%).

Dans l’exemple ci-dessous, la ligne contenant «dernière ligne avant édition» n’a pas le saut de ligne. Si nous essayons d’append une nouvelle ligne «dernière ligne après l’édition», comme nous pouvons le voir, les deux lignes 5 et 6 sont marquées comme modifiées, mais le contenu réel de la ligne 5 dans les deux versions est identique.

Sans saut de ligne avant EOF

Si tout le monde suit votre suggestion de chef de projet, ce sera le résultat (seule la ligne 6 diffère du fichier original). Cela évite également les malentendus lors des fusions.

Avec saut de ligne avant EOF

Bien que cela puisse ne pas sembler une grosse affaire, supposons qu’un développeur (A) ait réellement l’intention de modifier le contenu de la dernière ligne et qu’un autre développeur (B) ait ajouté une nouvelle ligne. Si vous n’utilisez pas le saut de ligne avant EOF, alors vous avez un conflit de fusion car le développeur B a également été contraint de modifier l’ancienne dernière ligne pour append un saut de ligne. Et … qui aime les conflits CVS / SVN?

Regardez cette question SO. .

La réponse volée sans vergogne à Ralph Rickenbach:

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 un retour chariot / nouvelle ligne. Ils ignorent cette ligne quand elle se termine par ^ Z (eof) à la place.

Donc, je pense que c’est surtout un fantôme du passé. Malheureusement, ces fantômes peuvent vous mordre dans la queue si vous ne les exorcisez pas correctement. (Votre serveur de génération est-il ancien et utilise-t-il des scripts shell plus anciens pour les résumés et autres)?

Essayez de couper / coller le fichier entier. Quelque chose de bug dans checkstyle ou eclipse:)

Parfois, votre compilateur ne l’parsing pas correctement:

Error: Reached end of file while parsing

Mis à part les raisons valables déjà mentionnées pour avoir un caractère de nouvelle ligne (problèmes possibles avec les anciens outils et diff), voici une autre façon de voir:

Pourquoi spécial-case la dernière ligne en ne pas append un caractère de nouvelle ligne lorsque toutes les autres lignes du fichier en ont une?

C’est juste un style de codage. Ne fait pas mal ou aide rien. Je ne voudrais pas que cela vous dérange, il semble que ce soit la préférence de vos équipes d’inclure et de vider la ligne. Il n’y a pas vraiment de bon argument contre cela, sinon pourquoi quelqu’un a-t-il assez à faire pour l’append au style checkstyle?

Je n’ai jamais entendu parler d’une telle exigence.

En fait, je viens de confirmer qu’un programme Java s’exécutera sans erreur ou avertissement du compilateur / runtime lorsqu’il n’y a pas de ligne vide à la fin du fichier.

Comme l’ont dit certains commentateurs, cela doit être un problème de style de codage. Malheureusement, je ne peux pas suggérer pourquoi il peut être important qu’il y ait une ligne vierge à la fin d’un fichier en Java. En fait, cela me semble totalement inutile

Nous avons dû faire cela pour du code C ++ car le compilateur a généré un avertissement à ce sujet, et nous avions une politique «sans erreur ni avertissements». Peut-être que le problème se situe ailleurs … avez-vous un outil de différenciation qui a un fil de fer ou un outil de fusion qui ne peut pas le gérer?

Ce n’est pas vraiment grave.