Nouvelle ligne vide à 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 appliquons également cela avec CheckStyle (avec niveau d'erreur).
Je cherchais ce sujet depuis longtemps, mais malheureusement je ne trouve aucune raison convaincante à cela. Il semble que les autres développeurs soient assez indifférents à ce sujet car ils viennent de cocher une case dans le formateur Eclipse et cela se fait automatiquement. Mais je ne sais toujours pas pourquoi cela est nécessaire et pourquoi il peut être important). Ma question est donc:
Pourquoi les lignes vides à la fin de Java fichiers source ont-elles besoin? 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 fin de ligne. C'est différent de se terminer par une ligne vierge, c'est-à-dire une nouvelle ligne vide.
Edit: Comme @Easy Angel l'a expliqué succinctement dans les commentaires: newline = "\ n" et ligne vide = "\ n\n"
Je pense que non plus:
votre prospect exige soit que chaque fichier se termine par un caractère de nouvelle ligne, mais il est interprété à tort comme exigeant que chaque fichier se termine par une ligne vierge (c'est-à-dire une ligne vide qui se termine par une nouvelle ligne), ou bien
ils essaient de s'assurer que chaque fichier se termine par un caractère de nouvelle ligne en obligeant en fait chaque fin de fichier avec une ligne vierge (alias ligne vide qui se termine par une nouvelle ligne), garantissant ainsi que les fichiers se terminent par au moins une nouvelle ligne (et éventuellement une nouvelle ligne supplémentaire redondante - overkill ?).
Sauf si l'éditeur affiche réellement des symboles de nouvelle ligne, il n'est pas toujours clair dans certains éditeurs qu'un fichier:
- NE SE TERMINE PAS une nouvelle ligne du tout,
- [~ # ~] se termine [~ # ~] avec un seul saut de ligne, ou
- [~ # ~] se termine [~ # ~] avec une nouvelle ligne vierge, soit 2 nouvelles lignes de fin
Je pense que la plupart des éditeurs de code source modernes insèrent une nouvelle ligne de fin. Cependant, lorsque vous utilisez des éditeurs plus anciens et plus généraux, J'essayerais toujours de m'assurer que mes fichiers de code source (et les fichiers texte en général) se terminent toujours par un retour à la ligne de fin (qui est parfois apparu comme une ligne vierge/un retour à la ligne vide selon l'éditeur que j'utilisais) parce que:
lors de l'utilisation de
catpour afficher le fichier sur la ligne de commande, si le fichier n'avait pas de retour à la ligne de fin, la sortie suivante (comme l'invite du shell ou un délimiteur visuel qu'un script peut sortir entre les fichiers) finirait par apparaître 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 de fin rend les fichiers plus conviviaux pour les utilisateurs et les scripts.Je crois que certains éditeurs (je ne me souviens d'aucun détail) insèreraient automatiquement une nouvelle ligne de fin si le fichier texte en manquait. Cela donnerait l'impression que le fichier a été modifié. Cela pourrait devenir déroutant si vous avez un tas de fichiers ouverts dans différentes fenêtres, puis allez tous les fermer - l'éditeur vous invite à enregistrer mais vous ne savez pas si vous avez apporté de "vraies modifications" au fichier ou si c'est juste l'auto- nouvelle ligne insérée.
Certains outils comme
diffet certains compilateurs se plaindront d'un saut de ligne manquant. C'est plus de bruit que les utilisateurs et les outils peuvent avoir à gérer.
Modifier:
À propos des éditeurs ajoutant des nouvelles lignes et ne pouvant pas voir s'il y a une nouvelle ligne vs une nouvelle ligne vide à la fin du fichier, je viens de tester 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 [ENTER]. J'ai examiné chaque fichier avec od -c -t x1.
- Vim did ajoutez une nouvelle ligne de fin.
- Emacs did ajoutez une nouvelle ligne de fin.
- Eclipse ne l'a PAS fait ajouter une nouvelle ligne de fin.
Mais
- Vim ne l'a PAS fait permettez-moi de faire descendre le curseur sur une ligne vierge sous "bonjour".
- Emacs did me permet de descendre le curseur sur une ligne vierge sous "bonjour".
- Eclipse ne l'a PAS fait permettez-moi de faire descendre le curseur sur une ligne vierge sous "bonjour".
Interprétez comme vous le souhaitez.
Ma pratique personnelle est d'essayer de garantir que les fichiers texte se terminent par une nouvelle ligne de fin. J'ai juste l'impression qu'il y a moins de surprise aux gens et aux outils avec c'est le cas. Je ne traiterais pas les fichiers source différemment des fichiers texte à cet égard.
Google se présente this :
qui, à partir de cette modification, affichent des hits qui parlent d'avertissements concernant un saut de ligne manquant venant des compilateurs C, svn (à cause de diff), diff, etc. Je pense qu'il y a une attente générale que les fichiers texte (fichiers source inclus) se terminent par un retour à la ligne et moins surprenant (et moins bruyant) quand ils ont tendance à être là.
Enfin this est intéressant:
Désinfection des fichiers sans retour à la ligne
Les fichiers texte doivent avoir toutes leurs lignes terminées par des caractères de nouvelle ligne (par exemple,\n). Cela est indiqué par POSIX, qui dit qu'un fichier texte estUn 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 étant dit, ce n'est que ma pratique personnelle. Je suis heureux de partager mon opinion avec tous ceux qui le demandent, mais je n'impose cela à personne. Je ne pense pas que ce soit quelque chose qui mérite d'être mandaté, comme je le dis ici :
Bien que je sois un pour la cohérence, je suis également contre la microgestion de chaque style. Le fait d'avoir une énorme liste de conventions de codage, en particulier lorsque certaines d'entre elles semblent arbitraires, fait partie des facteurs qui découragent les gens de les suivre. Je pense que les lignes directrices de codage devraient être rationalisées aux pratiques les plus précieuses qui améliorent les fonctionnalités. Dans quelle mesure la lisibilité, la maintenabilité, les performances, 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 sera modifié pour ajouter une autre ligne, la plupart des outils de fusion penseront que la ligne existante a changé (je suis sûr à 90% que SVN le fait également).
Dans l'exemple ci-dessous, la ligne contenant "dernière ligne avant modification" n'a pas de saut de ligne. Si nous essayons d'ajouter une nouvelle ligne "dernière ligne après modification", 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, ce serait le résultat (seule la ligne 6 diffère du fichier d'origine). Cela évite également les malentendus lors des fusions.
Bien que cela ne puisse pas sembler être un gros problème, disons qu'un développeur (A) voulait réellement changer le contenu de la dernière ligne et qu'un autre développeur (B) a ajouté une nouvelle ligne. Si vous n'utilisez pas de saut de ligne avant EOF, vous avez un conflit de fusion car le développeur B a été forcé de modifier également l'ancienne dernière ligne pour ajouter un saut de ligne. Et ... qui aime les conflits CVS/SVN?
Jetez un oeil à cette SO question. .
La réponse impudemment volée à 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 une combinaison retour chariot/nouvelle ligne. Ils ignorent cette ligne car 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 la queue si vous ne les exorcisez pas correctement. (Votre serveur de build est-il ancien et utilise des scripts Shell plus anciens pour les résumés et autres choses).
Essayez de couper/coller le fichier entier. Quelque chose de bug dans checkstyle ou Eclipse:)
Parfois, votre compilateur ne l'analyse pas correctement:
Error: Reached end of file while parsing
Mis à part les raisons valides déjà mentionnées pour avoir un caractère de fin de ligne (problèmes possibles avec les anciens outils et diff), voici une autre façon de voir les choses:
Pourquoi cas spécial la dernière ligne en pas en ajoutant un caractère de nouvelle ligne quand toutes les autres lignes dans le fichier en a un?
Nous avons dû le faire pour du code C++ car le compilateur a généré un avertissement à ce sujet, et nous avions une politique "pas d'erreur ou d'avertissement". Peut-être que le problème se situe ailleurs ... avez-vous un outil différent qui a mal tourné ou un outil de fusion qui ne peut pas le gérer?
Ce n'est pas vraiment un gros problème.
C'est juste un style de codage. Ne fait pas de mal ou n'aide rien. Je ne vous laisserais pas déranger, il semble que ce soit la préférence de vos équipes pour inclure et ligne vide. Il n'y a pas vraiment de bon argument contre cela, sinon pourquoi quelqu'un se soucie-t-il suffisamment de l'ajouter au style de contrôle?
Je n'ai jamais entendu parler d'une telle exigence.
En fait, je viens de confirmer qu'un programme Java fonctionnera sans aucune erreur ou avertissement du compilateur/d'exécution lorsqu'il n'y a pas de ligne vierge à la fin du fichier.
Comme certains commentateurs l'ont dit, 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