Nouvelle ligne vide à la fin des fichiers source Java

Question

Dans mon projet actuel, nous insérons toujours une nouvelle ligne vide à la fin des fichiers source Java. Nous appliquons également cette règle avec CheckStyle (avec un niveau d'erreur).

J'ai cherché ce sujet pendant un long moment, mais malheureusement je ne trouve aucune raison convaincante pour cela. Il semble que d'autres développeurs soient plutôt indifférents à cela car ils ont simplement coché une case dans le formateur Eclipse et c'est fait automatiquement. Mais je ne sais toujours pas pourquoi cela est nécessaire et pourquoi cela peut être important. Donc ma question est :

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

Answer 1

Je pense qu'ils essaient de s'assurer que chaque fichier se termine par un caractère de nouvelle ligne. Cela diffère de se terminer par une ligne vide, c'est-à-dire une nouvelle ligne vide.

Édit : Comme l'a succinctement clarifié @Easy Angel dans les commentaires : nouvelle ligne finale = "\n" et ligne vide = "\n\n"

Je pense que soit :

1. votre éditeur exige que chaque fichier se termine par un caractère de nouvelle ligne, mais cela est mal interprété comme exigeant que chaque fichier se termine par une ligne vide (c'est-à-dire une ligne vide se terminant par une nouvelle ligne), ou bien

2. ils essaient de s'assurer que chaque fichier se termine par un caractère de nouvelle ligne en exigeant en réalité que chaque fichier se termine par une ligne vide (c'est-à-dire une ligne vide se terminant par une nouvelle ligne), garantissant ainsi que les fichiers se terminent par au moins une nouvelle ligne (et éventuellement par une nouvelle ligne redondante supplémentaire - exagération ?).

Sauf si l'éditeur montre réellement les symboles de nouvelles lignes, il n'est pas toujours clair dans certains éditeurs qu'un fichier :

1. NE SE TERMINE PAS par une nouvelle ligne du tout,
2. SE TERMINE par une seule nouvelle ligne finale, ou
3. SE TERMINE par une ligne vide, c'est-à-dire 2 nouvelles lignes finales

Je pense que la plupart des éditeurs de code source modernes insèrent une nouvelle ligne finale. Cependant, lorsque j'utilisais des éditeurs plus anciens et plus généraux, 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 finale (ce qui pouvait parfois se traduire par une ligne vide/nouvelle ligne vide selon l'éditeur que j'utilisais) car :

1. lorsqu'on utilise cat pour afficher le fichier en ligne de commande, si le fichier n'avait pas de nouvelle ligne finale, la sortie suivante (comme l'invite de commande de l'interpréteur de commandes ou un délimiteur visuel qu'un script peut afficher entre les fichiers) se retrouvait juste après le dernier caractère non-nouvelle ligne plutôt que de commencer sur une nouvelle ligne. En général, la nouvelle ligne finale rendait les fichiers plus conviviaux pour les utilisateurs et les scripts.

2. Je crois que certains éditeurs (je ne me souviens pas des détails) inséraient automatiquement une nouvelle ligne finale si le fichier texte n'en avait pas. Cela donnait l'impression que le fichier avait été modifié. Cela devenait confus si vous aviez plusieurs fichiers ouverts dans différentes fenêtres et que vous vouliez les fermer tous - l'éditeur vous demande de sauvegarder mais vous êtes incertain si vous avez apporté de "vrais changements" au fichier ou s'il s'agit simplement de la nouvelle ligne insérée automatiquement.

3. Certains outils comme diff et certains compilateurs se plaindront d'une absence de nouvelle ligne finale. Il s'agit de bruit supplémentaire que les utilisateurs et les outils peuvent être amenés à gérer.

---

Édit :

Concernant les éditeurs qui ajoutent des nouvelles lignes et le fait de ne pas pouvoir voir s'il y a une nouvelle ligne ou une nouvelle ligne vide à la fin du fichier, j'ai testé Vim, Eclipse et Emacs (sur mon système Windows avec Cygwin) : j'ai ouvert un nouveau fichier, tapé 'h' 'e' 'l' 'l' 'o' et enregistré sans appuyer sur [ENTRÉE]. J'ai examiné chaque fichier avec od -c -t x1.

1. Vim a ajouté une nouvelle ligne finale.
2. Emacs a ajouté une nouvelle ligne finale.
3. Eclipse N'A PAS ajouté de nouvelle ligne finale.

Mais

1. Vim NE M'A PAS permis de descendre jusqu'à une ligne vide sous "hello".
2. Emacs m'a permis de descendre jusqu'à une ligne vide sous "hello".
3. Eclipse NE M'A PAS permis de descendre jusqu'à une ligne vide sous "hello".

Interprétez comme bon vous semble.

---

Ma pratique personnelle est d'essayer de m'assurer que les fichiers texte se terminent par une nouvelle ligne finale. Je pense simplement que c'est la moins surprenante pour les utilisateurs et les outils. Je ne traiterais pas les fichiers source différemment des fichiers texte à cet égard.

Google renvoie à ceci :

qui, à la date de cet édit, montre des résultats qui parlent d'avertissements sur une nouvelle ligne finale manquante provenant de compilateurs C, svn (en raison de diff), diff, etc. J'ai l'impression qu'il y a une attente générale que les fichiers texte (y compris les fichiers source) se terminent par une nouvelle ligne finale et que cela est moins surprenant (et moins bruyant) lorsqu'ils sont présents.

Enfin cela est intéressant :

Assainir les fichiers sans nouvelle ligne finale
Les fichiers texte doivent avoir toutes leurs lignes terminées par des caractères de nouvelle ligne (c'est-à-dire, \n). C'est ce que précise POSIX, qui dit qu'un fichier texte est

Un fichier contenant 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 caractères qui ne sont pas des sauf un caractère de terminaison.

---

CELA DIT, tout cela ne relève que de ma pratique personnelle. Je suis heureux de partager mon avis avec quiconque le demande, mais je ne veux pas l'imposer à quiconque. Je ne pense pas que cela vaille la peine de le rendre obligatoire, comme je le dis ici :

Alors que je suis favorable à la cohérence, je suis également contre la gestion micrométrique de chaque aspect du style. Avoir une longue liste de conventions de codage, en particulier lorsque certaines semblent arbitraires, est ce qui décourage les gens de les suivre. Je pense que les directives de codage devraient être rationalisées vers les pratiques les plus utiles qui améliorent les -ilités. Dans quelle mesure la lisibilité, la maintenabilité, les performances, etc. s'améliorent-elles en rendant cette pratique obligatoire ?

Answer 2

Voici une bonne raison d'avoir une ligne supplémentaire à la fin :

Si vous avez un fichier sans saut de ligne à la fin, la prochaine fois que le fichier est édité pour ajouter une autre ligne, la plupart des outils de fusion penseront que la ligne existante a changé (je suis à 90% sûr que SVN le fait aussi).

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

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

Bien que cela puisse ne pas sembler être un gros problème, disons qu'un développeur (A) voulait en fait changer le contenu de la dernière ligne et un autre développeur (B) a ajouté une nouvelle ligne. Si vous n'utilisez pas de saut de ligne avant EOF, alors vous avez un conflit de fusion car le développeur B a été contraint d'éditer également l'ancienne dernière ligne pour y ajouter un saut de ligne. Et... qui aime les conflits CVS/SVN ?

Answer 3

Jetez un coup d'œil à cette question SO..

La réponse honteusement volée à Ralph Rickenbach :

De nombreux outils plus anciens se comportent mal si la dernière ligne de données dans un fichier texte n'est pas terminée par un retour à la ligne ou un saut de ligne retour / nouvelle ligne. Ils ignorent cette ligne car elle se termine par ^Z (eof) à la place.

Je suppose que c'est surtout un vestige du passé. Malheureusement, de tels fantômes peuvent vous mordre si vous ne les exorcisez pas correctement. (Votre serveur de compilation est-il ancien et utilise-t-il d'anciens scripts shell pour les résumés et autres choses).

Answer 4

Essayez de couper/coller tout le fichier. Un bug dans checkstyle ou eclipse : )

Answer 5

Parfois, votre compilateur ne l'analyse pas correctement :

Erreur : Fin de fichier atteinte pendant l'analyse