La dénomination non intentionnelle est mauvaise

** Extrêmement important. ** Mène directement à la lisibilité. Le code écrit en tant que livrable dans les affaires est essentiellement lu par n'importe qui d'autre que vous-même. Je vais le réparer. Si vous donnez un nom que vous ne comprenez pas à ce moment-là, il reste généralement bloqué. ~~ Je ne peux pas le lire! Je suis sur le point de manquer. ~~

Une dénomination appropriée améliore la lisibilité

Par exemple, supposons que vous déclariez trois variables String. Puis str1, str2, str3 ... dans l'ordre d'utilisation Qu'est-ce que str1 à première vue! ?? Ce sera. Je ne connais que le type. ~~ Si vous regardez la déclaration du type, vous pouvez la voir d'un seul coup. ~~ C'est la même chose que de n'avoir aucune information. Avec un tel nom, vous ne vous connaissez peut-être même pas une semaine plus tard, et encore moins un mois plus tard. Un ingénieur qui ne peut même pas lire le code qu'il a écrit n'est-il pas trop cool? ?? Donnez-lui un nom qui a du sens.

Pratiques de dénomination Java

Fondamentalement, en Java, il est nommé comme suit. ** Suivez les conventions de codage, si spécifié. ** ** Je le vois souvent, mais ce n'est pas bon que les noms de variables soient un mélange d'étuis de serpent et d'étuis de chameau. Au moins, unissons-nous au sein de la classe. Ce n'est pas bon de mélanger l'anglais et le romaji. Comme "créer Chohyo". Vous pouvez utiliser "créer un rapport". Pourquoi faites-vous des «formes» en caractères romains? Googler des mots anglais que vous ne comprenez pas. Sauf pour les cas tels que les définitions de table DB mélangées avec des caractères romains, qui sont des variables qui stockent des éléments DB.

--Le nom de la classe est en majuscules camel (cas camel avec majuscules au début) (également appelé format Pascal) --Ex: StringBuilder, IndexOutOfBoundsException, etc.

• Le nom de la méthode et le nom de la variable sont en cas de chameau (commençant en minuscule, les mots connectés commencent en bas) --Ex: isEmpty, compareToIgnoreCase, etc. --Le nom de la constante est la majuscule du serpent (connectez les mots avec un trait de soulignement en majuscule) --Ex: WEEK_OF_YEAR, DAY_OF_WEEK_IN_MONTH, etc.

Dénomination exceptionnelle

S'il s'agit d'une variable très temporaire avec une courte portée, il peut s'agir de str de String ou de num de int. Extension pour les variables de boucle. Cependant, il s'agit d'une histoire qui n'est autorisée que lorsque l'intention de la variable est facile à comprendre dans une courte portée, et après tout, il est préférable de la nommer correctement. Cependant, ** ne donne pas d'originalité aux noms de variables usuels à utilisations limitées **. Plus précisément, ʻe et ʻex de l'exception dans la clause try-catch, ʻietj` de la variable compteur de la boucle for, etc. S'ils vous donnent de l'originalité, la lisibilité diminuera. Vous pouvez le laisser tel quel. Évitez également d'utiliser des noms de variables habituels pour des variables d'autres utilisations et types.

Il existe de nombreux articles dans Qiita sur des méthodes de dénomination spécifiques et des astuces. Essayez de rechercher quelque chose comme "Nom Java". Veuillez lire plusieurs articles en parallèle. ** C'est mal de sentir que vous comprenez simplement en lisant un seul article. ** **

Le code redondant ou illisible est incorrect

Essayez de réduire le nombre de branches et de nommer en fonction du contenu. Même s'il est omis, les simples qui ne nécessitent pas de commentaires sont omis. Comme vous le voyez souvent, déclarer une variable pour n'importe quoi est moins lisible. Si vous stockez une valeur qui ne nécessite qu'une brève description qui n'est référencée qu'une seule fois dans une variable, la description qui doit être lue augmente en conséquence. Surtout si la portée est large. Si elle est stockée dans une variable, on pense souvent que la valeur est nécessaire car elle sera référencée dans le traitement ultérieur. Dans le cas des chaînes de méthodes, de l'imbrication de méthodes, de la concaténation de chaînes, etc., où la description peut être trop longue ou compliquée, je pense qu'il est préférable de la stocker dans une variable compte tenu de la facilité de débogage.

Exemples courants dans le code débutant

Même dans une classe, ou même dans une unité de méthode, plus il y a de lignes, plus il est probable que des bogues se produisent. De plus, la quantité de tests simples augmente et le nombre d'étapes augmente. Le code hautement lisible est souvent organisé de manière concise. En d'autres termes, ce n'est pas un long code. D'autres ne peuvent pas lire ~~ Illisible ~~ Le code difficile à lire est un foyer de bogues. Il y a une forte probabilité que le responsable voit l'enfer lors d'une enquête ou d'une réparation (vrai visage).

Jugement de valeur booléen

Cela fonctionne comme prévu, mais il n'est pas correct d'écrire "== true" et "== false" dans l'instruction ** if **. L'instruction if de Java n'évalue que les valeurs booléennes, le mauvais exemple ci-dessous est donc simplement mis dans la corbeille. Que faire avec l'imbrication des jugements booléens.

//Jugement conditionnel de la déclaration if redondante
//Mauvais exemple
if (Condition A== true &&Condition B== false) {
}
//Bon exemple
if (Condition A&& !Condition B) {
}

Déclaration de variable

Vous trouverez ci-dessous quelques mauvais exemples courants de déclarations de variables et d'initialisations de valeurs. Faire de l'affectation un simple écrasement de l'initialisation une étape distincte est également un code inutile et redondant.

//Déclaration de variable redondante Il ne sert à rien d'écraser simplement la valeur au moment de la déclaration
//Mauvais exemple # 1 Il n'est pas toujours nécessaire d'initialiser avec null
List<String> list = null;
list = new ArrayList<String>(Arrays.asList(new String[]{"ABC", "123"}));

//Mauvais exemple # 2 L'initialisation n'a pas besoin d'être nouvelle
List<String> list = new ArrayList<String>(0);
list = new ArrayList<String>(Arrays.asList(new String[]{"ABC", "123"}));

//Mauvais exemple n ° 3: il n'est pas nécessaire de séparer la déclaration et l'initialisation
List<String> list;
list = new ArrayList<String>(Arrays.asList(new String[]{"ABC", "123"}));

//Bon exemple: si vous remplacez, n'initialisez pas inutilement en même temps que la déclaration
List<String> list = new ArrayList<String>(Arrays.asList(new String[]{"ABC", "123"}));

si optimisation de branche

Prenons le cas où l'affectation à la variable elle-même se ramifie en relation avec la déclaration et l'initialisation de la variable ci-dessus. Dans ce cas, il est logique de faire de la déclaration et de l'affectation une étape distincte, mais s'il n'y a que deux modèles, vous ne pouvez écrire que «if» au lieu de «if ~ else». Même s'il existe au moins 3 modèles de branche, envisagez d'optimiser l'instruction if. Pour le branchement par type d'énumération, il est également utile de faire une instruction switch.

//Lorsque la mission elle-même se ramifie(Seulement 2 modèles de ramification)
//Exemple redondant
String str = null;
if (Condition A) {
  str = "ABC";
} else {
  str = "123";
}

//Exemple de suppression de branches inutiles
String str = "123";
if (Condition A) {
  str = "ABC";
}

//Lors de l'utilisation de l'opérateur ternaire
String str =Condition A? "ABC" : "123";

Si la dérivation de la valeur à affecter à la condition A ou str n'est pas simple, le code ci-dessus peut être défini sur une ligne de String str = call another method;, donc la valeur de retour sera une autre méthode avec la valeur de str. Je pense que c'est bien de le faire. Les avantages et les inconvénients de l'utilisation d'un seul processus moins compliqué comme méthode distincte peuvent dépendre du réviseur de code. ** Sauf interdiction par les conventions de codage, ** recommande également l'utilisation d'opérateurs ternaires lors du changement de valeurs dans des conditions simples. Cependant, l'utilisation d'opérateurs ternaires doit être limitée à de simples branches. S'il y a plusieurs conditions ou si les conditions ou les branches sont imbriquées, la lisibilité sera réduite, alors arrêtez-la.

Le réaménagement des roues est mauvais

N'implémentez pas vous-même les fonctionnalités existantes. Sa fabrication et ses tests sont un coût inutile que vous n'auriez pas à payer autrement. Loin d'être dénué de sens, c'est un moins.

Exemples courants

Je le vois très souvent, mais la bibliothèque apache.commons est disponible, mais seule l'API standard est utilisée. Vous pouvez voir que la méthode est créée par la combinaison d'API standard même si la classe commune est mal coupée. Bien sûr, je sais qu'il y a des cas où la version de la bibliothèque commune est faible et il n'y a pas de méthode appropriée, ou la bibliothèque commune ne peut pas être utilisée en premier lieu, et si c'est le cas, cela ne peut pas être aidé. Il n'est pas bon de réaménager volontairement des roues qui peuvent être utilisées mais non utilisées. C'est aussi une mauvaise idée d'avoir une classe commune dans votre projet et de la déclarer ici, mais ne l'utilisez pas.

//Vérifiez si la chaîne est nulle ou vide
//Mauvais exemple
if (str == null || str.isEmpty()) {
}
//Bon exemple
if (StringUtils.isEmpty(str)) {
}

//Si la chaîne est nulle ou tronquée et est vide, convertissez-la en chaîne spécifiée
//Mauvais exemple
String str = value;
if (StringUtils.isBlank(str)) {
    str = "Pas encore défini";
}
//Bon exemple
String str = StringUtils.defaultIfBlank(value, "Pas encore défini");

//Contrôle nul de l'objet
//Mauvais exemple
if (obj == null) {
}
//Bon exemple
if (Objects.isNull(obj)) {
}

Ne t'embête pas

Cela coûte cher de rechercher sur le Web et de vérifier si la fonction existe dans la bibliothèque que vous utilisez. Cependant, le réaménagement des roues qui en prend soin est un moins plutôt qu'un plus. Ne fais pas ça. Une fois que vous avez écrit le code, vous devez tester autant que vous écrivez. Avec les fonctionnalités existantes, vous n'avez pas besoin de faire des tests détaillés sur cette partie. S'il s'agit d'une bibliothèque commune, elle est utilisée partout dans le monde et elle est presque garantie de fonctionner lorsqu'il n'y a pas de bogues. Ce serait plutôt une grande réussite de découvrir qu'il a été utilisé correctement et de provoquer un bogue et de le signaler à la communauté OSS. C'est un niveau dont vous pouvez être fier. Mais si vous l'écrivez vous-même, vous devez tout tester. Personne ne garantit l'opération. Mais ce test est inutile. Si vous avez un smartphone, vous pouvez le rechercher sur votre smartphone pour connaître le numéro de téléphone du magasin où vous souhaitez vous rendre lors de vos déplacements, n'est-ce pas? Vous n'allez pas dans la cabine téléphonique et tirez la page de la ville, non? Vous n'appelez même pas le guide des numéros de téléphone, non? C'est tout.

** Ne pas savoir n'est pas une mauvaise chose. Ce qui est mauvais, c'est cette attitude négligente que vous ne connaissez même pas. ** ** Regardons au moins à l'intérieur du projet. ** Examinez-vous, puis consultez un expert. (N'omettez pas le processus de vérification par vous-même) Si la fonctionnalité dont vous avez besoin n'existe pas, vous savez qu'elle n'existe pas. Si tel est le cas, demandez à un expert de le fabriquer en tant que fonction commune ou de le décrire uniquement dans la pièce dont vous êtes responsable. La bibliothèque commune montrée dans l'exemple concret peut ne pas exister selon la version. Même si un exemple d'utilisation est trouvé par recherche WEB, il peut y avoir une méthode qui n'existe pas dans la version utilisée dans le projet en charge. Mais cela vous donne plus d'informations.

Les documents en anglais ne font pas peur

Si vous avez essayé de le savoir mais que Javadoc est difficile à lire en anglais, lisez le code directement. Dans de nombreux cas, c'est plus rapide. La classe StringUtils des communs ne dit rien de difficile. La plupart des méthodes peuvent être lues même par les débutants. La plupart des noms de méthodes sont faciles à comprendre. Ouvrons le code du jar utilisé dans la matière en charge directement dans l'IDE. Si vous utilisez Eclipse, il peut être plus facile de trouver la fonctionnalité que vous recherchez en organisant les méthodes dans l'ordre ABC à l'aide de la vue en plan.

Ce n'est pas un examen scolaire, vous n'avez donc pas à le traduire en japonais. Ce serait bien si nous pouvions à peu près traduire et traduire directement. Je compte également sur la traduction de Google. Mais si cela a du sens, ça va. Utilisez ce que vous pouvez utiliser. Vous pouvez obtenir le sens simplement en parcourant les mots comme ça dans la phrase. Cela est particulièrement vrai pour diverses exceptions. Il n'est pas bon de le lancer avant de le faire.

Il est mauvais de négliger de mettre à jour les connaissances

Si vous souhaitez continuer ce travail, la mise à jour de vos connaissances est essentielle. Si vous souhaitez travailler uniquement avec les connaissances que vous avez acquises, ce poste ne vous convient pas.

Obtenez les connaissances dont vous avez besoin pour «maintenant»

Les bibliothèques qui peuvent être utilisées varient selon le sujet. Vous n'avez pas à vous en souvenir à chaque fois, mais vous devez le rechercher. Certaines personnes le font à cause de la mort cérébrale, mais arrêtez-le car ce n'est rien d'autre que l'accumulation de dettes techniques. N'empilez pas de code qui ne doit pas être écrit. C'est un mot difficile, mais je veux que vous puissiez refactoriser beaucoup de code chaque fois que vous avez du mal à l'analyser. (Il existe de nombreux postes de ce type)

La gestion de la date et de l'heure de Java est passée de Date et calendrier à LocalDateTime, non? Les opérations sur les fichiers sont devenues beaucoup plus faciles avec l'avènement du package java.nio.file, non?

Récemment, j'ai réalisé un nouveau projet de construction après Java 8 où je ne vois aucun essai avec ressource, expression lambda, API de flux ou facultatif. … La connaissance des membres s'est arrêtée. Je pense que ce modèle est souvent utilisé dans les bureaux gouvernementaux et les contrats d'infrastructure. Mais il devrait y avoir de nouveaux diplômés en tant que membres. Puisque le code environnant est hérité, j'écris du code hérité. C'est une mauvaise tendance. Jusqu'à récemment, je ne pouvais pas lire le code de type Java 8. Parce qu'il n'y avait qu'un cas de code hérité jusqu'à Java6. Je ne pouvais pas rattraper la compréhension même après avoir lu les documents ... Je ne pourrais pas le faire sans réellement écrire et bouger ... Je ne me souviens pas des connaissances que je n'ai pas besoin d'utiliser ... Cependant, j'ai été affecté à un projet Java 8, donc j'étais conscient de m'en souvenir. Grâce à cela, au bout d'un demi-mois, je me suis habitué à l'API Stream au point que j'ai presque arrêté d'écrire pour les déclarations. C'est un professeur de Google. Maintenant que je peux lire le code Java 8, je peux faire plus. N'ayez plus peur de voir un exemple de code de style lambda dans vos résultats de recherche. Je n'ai pas à tourner à droite. (Lol) Je suis heureux de mon âge pour savoir ce que je ne sais pas et pour pouvoir en faire plus.

Le code qui est difficile à effectuer des tests unitaires est mauvais

Par exemple, les cas de test JUnit sont difficiles à écrire du code. Les méthodes longues et complexes augmentent le coût de réflexion et d'écriture de cas de test. Il est difficile à entretenir et à réparer. Pensons à une autre méthode de description pour le même contenu de traitement, telle que la division du traitement de la méthode principale en petites parties et la division du traitement divisé en méthodes distinctes. J'ai vu qu'une méthode publique d'une classe complètement nouvelle a dépassé 300 lignes en raison de la rénovation, mais j'ai entendu dire que c'était une plainte d'un client. Il s'agit de Java en 2019. Ce n'est pas un vieux C. Bien sûr, le traitement était profondément imbriqué et la lisibilité était très faible. Un niveau où seule la personne qui l'a écrit peut écrire JUnit. J'ai été aidé, mais je ne pouvais pas le faire sans ses commentaires. Cependant, vous devez absolument arrêter la stupidité de supprimer le ** modificateur d'accès de la méthode split comme privé pour l'appeler dans JUnit **. Rendre la cible de test incorrecte pour le test. Une telle chose n'est rien d'autre qu'une chute. Je le vois très souvent.

Utilisez la réflexion si elle ne peut pas être appelée à partir de la classe de test en raison des restrictions du modificateur d'accès. Protégez la méthode cible de test et appelez-la à partir de la classe de test qui hérite de la classe cible de test. protected n'est pas un modificateur d'accès à des fins de test. Même les méthodes statiques privées peuvent être appelées et testées par réflexion ...

** Addendum 1 ** J'ai écrit un article sur une classe de test JUnit qui appelle un champ de méthode privée. Tester la méthode privée dans JUnit Référez / définissez des variables privées en réflexion

** Addendum 2 ** Les qualificatifs d'accès sont une matière obligatoire en Java, donc si vous n'êtes pas sûr, vérifiez-les. Certains langages, tels que JavaScript et Python, n'ont pas de modificateurs d'accès, mais Java est un langage qui a des modificateurs d'accès. J'ai réfléchi à la raison pour laquelle Python et JavaScript n'ont pas de modificateurs d'accès - Qiita

Une nidification trop profonde est mauvaise

Comme je l'ai écrit ci-dessus, le code avec une imbrication profonde (le branchement conditionnel et les blocs de boucle ont une structure imbriquée en plusieurs étapes) est compliqué et illisible, et JUnit est également difficile à écrire. Un tel code profondément imbriqué est également un signe qui divise le processus en méthodes distinctes. Le code qui ne tient pas compte de la lisibilité est difficile à tester.

Retour anticipé, utilisation de la clause de garde

Par exemple, simple si l'imbrication peut être réduite en inversant la condition. Dans un modèle courant, si l'argument n'est pas vide, il sera traité, mais s'il est vide, une valeur fixe sera renvoyée. Dans ce cas, inversez la condition et décrivez-la de sorte que le motif qui n'est pas traité quitte le traitement en premier.

//mauvais exemple
boolean result = false;
if (Condition A) {
  //Traitement en cas de condition A
  // ………
} else {
  return result;
}
return result;

//Bon exemple
if (!Condition A) {
  return false;
}
boolean result = false;
//Traitement en cas de condition A
//Après cela, la valeur de retour sera renvoyée lorsqu'un retour anticipé est possible.
// ………
return result;

Le résultat ci-dessus est le même. Cependant, cela seul réduit de un le nombre de nids dans le traitement effectué dans le bloc de la condition A. Si le bloc de la condition A comporte plusieurs lignes, il est également moins lisible que vous ne savez pas quoi faire autre que la condition A jusqu'à ce que vous ayez fini de lire le bloc de la condition A. Même lorsque le branchement conditionnel est effectué dans l'instruction for, l'imbrication peut être réduite en continuant / interrompant ce modèle. De plus, dans le mauvais cas, la valeur de retour de else est une variable, vous ne pouvez donc pas dire en un coup d'œil quelle est la valeur de retour. Il n'y a pas de modèle autre que false, donc return false; est très bien. Puisqu'il n'y a pas de traitement après retour, il n'est pas nécessaire de le stocker dans une variable. Il réduit également la portée des variables en éliminant le besoin de les déclarer avant l'instruction if.

Le même processus décrit individuellement à plusieurs endroits est mauvais

Quel est le problème avec l'écriture du même processus individuellement à plusieurs endroits? C'est parce que l'entretien et les réparations sont difficiles. Par exemple, supposons qu'un processus soit effectué à plusieurs endroits, mais que tous soient décrits individuellement. Il a été décidé de réparer le processus. Il est nécessaire de confirmer, réparer et tester avec le même contenu pour toutes les pièces. Dans le cas d'une même description, elle peut être corrigée par copie. Si le nombre de corrections augmente, la copie-pemis se produira certainement. C'est souvent le cas avec les commentaires et les changements de nom de variable manquants. En outre, il est nécessaire de vérifier tout le code pour un excès ou une carence dans l'emplacement d'exécution du processus. Vous pouvez le faire dans la classe, mais si vous ne le rendez pas commun, vous pouvez finir par vérifier l'ensemble du projet. Tous les coûts répétitifs sont un gaspillage que vous pourriez autrement économiser.

Découpons la description qui effectue le même traitement en une seule méthode. Les valeurs qui diffèrent à l'emplacement de l'appel peuvent être transmises comme arguments. Nous vous recommandons d'écrire du code qui fonctionne rapidement, puis de le refactoriser. Il est plus sûr et plus sûr d'écrire JUnit et de confirmer que le contenu de traitement est correct avant de refactoriser. Une fois que vous l'avez écrit, il est facile de remarquer: "J'ai l'impression d'avoir écrit ce processus avant ...?"

Cependant, ce qui précède est le cas de la nouvelle production, et à titre exceptionnel, il peut être inévitable de réparer le système existant. Par exemple, dans un système existant dans lequel le même processus est décrit individuellement dans plusieurs classes, certaines des classes qui doivent être partagées incluent la classe à réparer. Lors de la modification d'un système existant, il arrive souvent que les pièces qui n'ont pas besoin d'être changées ne soient pas modifiées autant que possible. En effet, la classe modifiée nécessite une sorte de test supplémentaire en dehors de la granularité et de la phase, ce qui augmente l'effort. Dans un tel cas, même si la politique consiste à effectuer un refactoring qui n'est pas lié au contenu de la réparation, dans la plupart des cas, seul le refactoring au sein de la classe à réparer sera effectué et le refactoring qui supprime une méthode commune à une autre classe ne sera pas effectué. est. Lors de la remise à neuf d'un système existant, vérifiez auprès de votre supérieur ou d'un expert la disponibilité et l'étendue de la refactorisation.

Il est préférable de ne pas publier (autant que possible) du code qui nécessite une refactorisation qui serait une responsabilité technique.

Les variables et méthodes qui n'ont pas de sens et dont la portée est large sont mauvaises

Java est Java, pas C, C # ou JavaScript

Tout d'abord, les apprenants du langage C doivent oublier le langage C lorsqu'ils écrivent ** Java. Le langage C et Java sont différents. ** ** Java et C peuvent avoir une apparence un peu similaire (style de codage). Cependant, le langage C et Java sont différents. La seule différence est que les noms de Java et JavaScript sont similaires. Le contenu est complètement différent. Veuillez ne pas adhérer. ** Vous ne pouvez pas écrire Java simplement parce que vous pouvez écrire C. ** Vraiment ne plaisante pas avec moi. Le langage C n'est pas orienté objet. C'est une chose différente. La seule chose qu'ils ont en commun est leur apparence. ** Si un combattant actif et Kanna Hashimoto portent les mêmes vêtements, les jugez-vous comme étant la même personne? Pas toi? C'est la même chose. ** **

Si vous déclarez une variable, où vous l'utilisez

Ne déclarez pas les variables ensemble au début d'une méthode. Même si vous utilisez l'EDI, les variables locales ordinaires n'apparaîtront que dans la mesure du type. Si la déclaration est loin du lieu où elle est effectivement utilisée, ce sera une perte de temps d'aller voir la déclaration. ** Comme c'est souvent le cas pour les personnes venant de C (ou VBA), c'est une mauvaise pratique en Java. ** ** Déclarez les variables en gardant à l'esprit la portée d'utilisation. Il ne sert à rien d'écrire des variables qui ne sont utilisées qu'à l'intérieur du bloc en dehors du bloc. Écrivez-le plutôt.

Parfois, c'est un projet qui utilise toujours les anciennes conventions de codage, et il est écrit dans une déclaration tête-à-tête. Mais c'est une putain de règle en Java aujourd'hui, donc dans certains cas, vous devriez soulever des questions.

Soyez conscient de la portée

Considérez une lunette de visée comme une plage utilisable. En Java, les variables déclarées à l'intérieur d'un bloc ne peuvent pas être utilisées en dehors du bloc. (Bloquer la portée) Par exemple, une instruction for telle que for (int i = 0; i <array.length; i ++) {, le compteur de boucle "i" déclaré ici provoquera une erreur de compilation en dehors de l'instruction for. Il ne peut pas être réutilisé pour les blocs. Il vous suffit de connaître cette variable dans le bloc. Simplement en réduisant la plage à prendre en compte, la lisibilité sera grandement améliorée. Les variables déclarées en dehors du bloc peuvent être référencées et affectées même après avoir quitté le bloc. ça peut. Oui c'est possible. Vous devez être conscient de tous les endroits où la variable est utilisée car il y a une possibilité. L'utilisation efficace de la portée de bloc est de préciser qu'elle n'est utilisée que là-bas. Il sauvegarde la mémoire du cerveau du lecteur et la mémoire de JavaVM. Réduisons donc la portée des variables.

Ne réutilisez pas les variables

La réutilisation des variables réduit la lisibilité et crée des bogues. Vous devez savoir où la variable est utilisée. La raison pour laquelle l'utilisation intensive des variables globales est mal dite est la difficulté de les gérer. Où remplacer et où se référer. Il est difficile de tout suivre. De plus, il est possible que la valeur doive être initialisée lorsqu'elle est réutilisée, mais cela augmente également la possibilité de créer un bogue en oubliant de l'initialiser. Lors de la réutilisation, le nom de la variable a tendance à être générique, mais ce n'est pas bon non plus. En d'autres termes, ** la réutilisation des variables est nuisible et n'a aucun avantage. ** C'est une abréviation qui ne doit pas être omise.

Oubliez l'ancien style de codage

Dans l'ancien temps, il y avait une tendance à déclarer les variables utilisées dans une boucle en dehors de la boucle pour économiser de la mémoire. Mais maintenant, je n'ai plus à m'inquiéter de ça. Si vous ne l'utilisez que dans une boucle, déclarez-la dans une boucle. Si vous le déclarez en dehors de la boucle, vous oublierez que vous devez l'initialiser à chaque fois au début de la boucle, et vous serez bogué! Eh bien, au contraire, il y a des compteurs de boucles et d'autres variables qui devraient être déclarées en dehors de la boucle.

Soyez conscient des modificateurs d'accès

La même chose peut être dite pour les modificateurs d'accès et pour les variables. Ne rendez rien public ou sans modificateurs d'accès, que ce soit une méthode ou une variable **. Toucher de n'importe où n'est pas un avantage. Dans la plupart des cas, c'est un inconvénient.

Un simple copier-coller de code est mauvais

** N'écrivez pas de code que vous ne comprenez pas **. Il est facile de créer une situation où vous ne savez pas, mais cela fonctionne ... ** Je ne sais pas, alors ne le copiez pas **. Même lors de la copie, il est essentiel de le lire correctement, de comprendre le contenu et de refactoriser le code source de la copie en fonction de la destination du collage.

N'écrivez pas de code qui ne peut être expliqué aux autres!

S'il vous plaît gardez en tête. Lorsqu'on vous le demande lors d'une révision de code, ** vous ne devez pas écrire de code que vous ne pouvez pas vous expliquer **. "Parce que je l'ai trouvé en cherchant" "Parce qu'il y avait un endroit écrit comme ça" etc ... Ce ne sont pas les raisons. Pas de réponse non plus. C'est juste une excuse. Ne copiez pas et ne collez pas à cause de la mort cérébrale, mais au moins, lisez et comprenez ce que vous faites. ** Prenez l'habitude de lire Javadoc pour les API que vous ne comprenez pas **. Même s'il s'agit d'une méthode, veuillez lire quel type de traitement est effectué dans cette méthode. Vous ne pouvez pas obtenir de valeur d'expérience sans lire.

Les références et les réponses ne sont pas égales

Parfois (même si je ne suis pas un nouveau venu), je demande «Dites-moi le code de référence», et quand je l'enseigne, je copie le code tel quel. Vous devriez rechercher la signification de «référence» une fois dans le dictionnaire. ** Si seulement ces gens ne travaillent pas, ils blâmeront la personne qui leur a enseigné! !! !! !! !! !! !! !! !! ** ** Votre tête est-elle une décoration? Ah? ** Prenez la responsabilité de votre code, merde! !! !! !! !! ** C'est une action qui ne peut être aidée même si elle est maudite.

Une méthode surchargée de traitement est mauvaise

Surtout les méthodes publiques. L'écriture de classes de test pour de longues méthodes publiques peut être extrêmement difficile. Soyons conscients de la fonction 1 méthode 1. La classe de test est également facile à écrire. Il est également facile de donner un nom à une méthode. Vous pouvez appeler la méthode privée à partir de la méthode privée, essayez donc de ne pas la rendre aussi compliquée que possible. Moins vous avez de fonctionnalités, plus votre code est court. Je pense qu'il est préférable de l'inclure dans environ 100 lignes / méthode au maximum. Personnellement, j'utilise le nombre de lignes qui peuvent être affichées sur un écran comme guide sans défilement.

La modification d'une méthode surchargée de traitement élargira inutilement la portée des tests. Si les trois fonctions des processus A, B et C sont traitées par une seule méthode, un test est nécessaire pour confirmer que les processus B et C ne sont pas affectés même si seul le processus A est modifié. Probablement. Java est orienté objet, c'est donc une bonne idée de garder à l'esprit le principe de responsabilité unique. [Principe de responsabilité unique | 97 choses que les programmeurs doivent savoir](https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82 % A4 /% E5% 8D% 98% E4% B8% 80% E8% B2% AC% E4% BB% BB% E5% 8E% 9F% E5% 89% 87 /)

C'est facile à lire si c'est comme appeler la méthode privée qui exécute chaque processus dans l'ordre dans la méthode publique. Si les méthodes sont séparées pour chaque processus, la facilité de test sera grandement améliorée. Considérez-le comme un modèle en plastique. Si vous souhaitez peindre uniquement les parties du bras, il est plus facile de travailler si vous pouvez retirer les parties du bras. S'il s'agit d'une figurine en vinyle souple d'une seule pièce, vous devez faire attention à ne pas laisser la couleur ressortir à l'exception du bras.

Les littéraux laissés avec des nombres magiques sont mauvais

Déclarez le même littéral avec une intention similaire en tant que constante pour consolider et donner un sens en un seul endroit. Il n'y a aucune raison de laisser une valeur qui est utilisée avec la même intention encore et encore comme un nombre magique. Si elle est nommée comme constante, «quelle est cette valeur?» Et «pourquoi cette valeur?» Est définitivement réduite. De plus, si vous la déclarez comme constante et que vous l'utilisez, lorsque la valeur change, il vous suffit de changer la valeur de la constante. Si vous l'utilisez à plusieurs endroits, c'est un grand avantage. Fondamentalement, il n'est pas bon de laisser le nombre magique tel qu'il est dans le codage en dur.

Cependant, il existe également des cas au cas par cas, car la création d'un trop grand nombre de constantes privées pour les littéraux qui ne sont utilisés qu'à un seul endroit à la fois réduit la lisibilité. Par exemple, si le nom de la variable est zipCd et qu'il s'agit de «substring (0, 3)» ou «substring (3)». Vous pouvez voir en regardant simplement le fait que le code postal est divisé à la position du trait d'union. Cependant, s'il s'agit d'une valeur métier, elle doit être déclarée comme constante et utilisée, ou elle doit être une méthode pour la traiter.

S'il est sujet à changement, il est judicieux d'accéder à un fichier de propriétés externe au lieu d'une constante. Vous pouvez le rendre significatif par le nom de la clé lorsque vous l'obtenez à partir de la propriété, et vous n'avez pas à modifier le code.

** Ajouté à partir de la section des commentaires ** Si les valeurs sont identiques mais ont des utilisations et des intentions différentes, n'utilisez pas de constantes communes. C'est un pas vers les bugs. Si le but ou l'intention est différent, déclarez-le avec une constante différente. Il est important de penser à ce que vous appelez cela comme une constante.

Méthodes sans Javadoc, Javadoc qui ne correspond pas au code est incorrect

Au minimum, Javadoc avec @param, @return et @throws correspondant à la source est requis. Java est une prémisse IDE, et ce serait bien s'il y avait suffisamment d'explications pour appeler cette méthode après avoir vérifié uniquement Javadoc. Sinon, vous devrez lire toutes les fonctions de l'appelé pendant la maintenance et la réparation.

Le coût de lecture d'un code étrange écrit par d'autres est assez élevé

Par exemple, la balise @ param qui explique le contenu de l'argument et la balise @ return qui explique la valeur de retour. Il est hors de question qu'il n'y ait pas de balise elle-même même s'il s'agit d'une méthode avec des arguments et des valeurs de retour, il existe des modèles tels que @param str qui ne sont pas expliqués uniquement par le nom de la variable (est-il simplement généré automatiquement et laissé?) Cependant, je m'excuse et je veux que vous corrigiez immédiatement.

Pourtant, c'est toujours bon si vous pouvez dire à partir de la dénomination que le type est caractéristique. Avec ʻint update (Connection con, String sql, Map <String, Object> params) , vous pouvez voir en un coup d'œil que la connexion, l'instruction SQL et les paramètres à intégrer dans l'instruction SQL sont passés pour mettre à jour la base de données et renvoyer le numéro. .. (** La description Javadoc est toujours requise, mais **) Mais je ne peux pas deviner quoi passer, quoi faire et quoi renvoyer, une méthode comme String edit (String str, String value, boolean flg)`. Peut-être que la personne qui l'a écrit ne le comprendra pas avec le temps. Cependant, si Javadoc est écrit, le coût de lecture du contenu est presque inutile.

Javadoc doit être mis à jour de temps en temps

Javadoc est plus que juste écrit au moment de la fabrication. Les arguments et les valeurs de retour peuvent augmenter, diminuer ou changer pendant la rénovation. Dans ce cas, assurez-vous de mettre à jour. ** Les Javadocs qui ne correspondent pas au code sont moins ** au lieu de zéro. Ce sont des ordures. ~~ Devrait être jeté au feu de l'enfer. ~~ Au moins un aperçu, des arguments et une valeur de retour. Faites correspondre ces trois avec le code à ce moment-là. C'est une bonne idée de prendre l'habitude de revoir Javadoc chaque fois que vous écrivez ou modifiez du code.

Les commentaires sur la prémisse qui correspondent exactement au document de conception sont mauvais

** Ne liez pas les commentaires avec le document de conception, par exemple en incluant le numéro de chapitre du document de conception **. Lors de la modification du document de conception, il est nécessaire de synchroniser les commentaires du code autre que la cible de modification simplement parce que le numéro d'article a changé. Il existe de nombreux projets qui ne maintiennent pas le document de conception (bien qu'il soit étrange que ce soit normal), et le code et le document de conception divergent régulièrement.

~~ Et au moment de la rénovation, on dit que "le document de conception n'est pas fiable, alors mettez à jour le document de conception en fonction du code" et le nombre d'étapes augmente inutilement ...

Les commentaires trop détaillés sont mauvais

Le traitement simple et les ** commentaires écrits un par un pour chaque branche conditionnelle simple sont moins lisibles **. N'écrivez pas de code qui divise par deux le nombre de lignes si vous supprimez un commentaire. Il s'agit de java.lang.String de l'API standard qui est souvent utilisée, mais veuillez le lire une fois. Avec Eclipse, vous pouvez accéder à la source simplement en appuyant sur F3. Je ne pense pas qu'il y ait d'autres commentaires détaillés que Javadoc.

Commentaires obligatoires, commentaires inutiles

Par exemple, avez-vous besoin d'une condition ou d'un commentaire tel que "lorsque le nombre d'éléments dans la liste est de 0" qui peut être compris simplement en regardant le code? Lorsque vous rédigez un commentaire, demandez-vous si vous en avez besoin en premier lieu. Même pour un jugement de condition compliqué, si vous optez pour une autre méthode avec un nom descriptif, ne serait-il pas inutile de commenter? Le code qui ne nécessite pas de commentaires est facile à lire.

Ressources pour rédiger des commentaires

Un grand nombre de commentaires peuvent être ridiculement modifiés lorsque le code est modifié. En outre, à mesure que le nombre de commentaires augmente, le nombre de commentaires erronés qui s'écartent du traitement en raison d'une omission de correction ou d'erreurs de copie augmentera. vous devez. Je peux affirmer. Les mauvais commentaires sont moins lisibles que l'absence de commentaires. C'est un foyer de bugs.

Le format de style de codage incohérent est mauvais

(Minimum) Unifier dans le fichier

Mettre en retrait les tabulations et les espaces, les sauts de ligne avant et après la parenthèse ondulée {}, les espaces avant et après l'opérateur et les parenthèses (), etc. Même si vous effectuez une recherche grep dans l'enquête, elle ne sera pas interceptée sauf si vous considérez le nombre d'espaces comme une expression régulière, et il n'y a rien de bon. Si vous utilisez un IDE, je pense qu'il a une fonction de formatage automatique, c'est donc une bonne idée de le configurer pour qu'il soit formaté lorsque vous l'enregistrez. Si vous partagez les paramètres qui correspondent aux normes de codage dans le projet, tous les membres auront le même format. Étant donné que les différences individuelles sont moins susceptibles de se produire, la maintenance est plus facile.

Personnellement, je préfère que le format soit défini pour chaque projet. Même si le format n'est pas votre préférence. C'est mieux que d'avoir à maintenir ou modifier le code dans différents formats pour chaque fichier. À mesure que vos yeux s'y habituent, la recherche et la lecture prennent moins de temps. Parce que les formats sont complets.

Le traitement laissé dans le commentaire est incorrect

Il s'agit généralement d'un ancien projet qui n'inclut pas la gestion des versions. La culture de commenter et de laisser du code non réparé n'est que nuisible, alors ne le faites pas. Veuillez mettre en gestion de version pour un tel projet.

Ne laissez aucune poubelle

Les subtilités du code commenté et non commenté peuvent réduire considérablement la lisibilité. Parfois, c'était trop compliqué et je ne savais pas où décommenter à cause de la réparation du genre "Décommentez ensuite la partie qui a été commentée au moment de XX".

Ne laissez pas de code qui ne fonctionne pas pour le moment. Si vous souhaitez le conserver, laissez-le dans l'historique de gestion des versions. Parce que vous pouvez vérifier la différence. À quoi sert la gestion des versions ...

L'alignement des déclarations et des affectations est mauvais

Les styles et les formats de codage sont comme les religions, alors j'ai pensé que je voulais seulement dire que je voulais qu'ils soient unifiés, mais laissez-moi juste dire ceci. Je pense que c'est un mauvais code qui n'a pas à l'esprit la maintenance ou la rénovation.

Par exemple, si vous l'écrivez concrètement, c'est comme ça.

String name      = null;
String zip       = null;
String address   = null;
String telephone = null;
int    sex       = 0;

Si vous essayez d'ajouter une variable appelée «emailAddress» avec une chaîne et essayez de l'aligner avec un espace pour correspondre au format existant, le nom de la variable «emailAddress» à ajouter sera le plus long, vous devez donc aligner d'autres lignes également. .. Ou, si le type de "sexe" est changé de int à BigDecimal, le nom du type est plus long que String, vous devez donc mettre un espace après le nom du type sur l'autre ligne pour aligner les chiffres. Non, ce n'est peut-être pas "à faire", mais les formats non unifiés ne sont pas bons. Pourquoi les personnes qui aiment l'alignement des chiffres posent-elles délibérément des problèmes même si elles prennent la peine?

Si vous ne justifiez pas, il vous suffit d'ajouter une ligne avec String emailAddress = null; et changer le nom du type et la valeur initiale avec BigDecimal sex = null;. Lorsque vous effectuez une recherche grep, vous n'avez pas à l'écrire dans une expression régulière étant donné que le nombre d'espaces est variable et que vous ne pouvez pas trouver l'avantage de la justification.

Améliore-t-il la lisibilité? Améliorons la lisibilité ailleurs. Quelqu'un n'alignera jamais les chiffres tout en étant maintenu. Si vous n'alignez pas les chiffres, vous ne pouvez pas le forcer sauf si vous obtenez une erreur de compilation. La personne qui l'a écrit peut l'avoir écrite dans un éditeur de police de largeur uniforme, tandis que d'autres peuvent l'afficher dans une police proportionnelle. Par exemple, il existe de nombreux cas où le code est collé dans Excel pour créer le matériau de la pièce réparée, mais le MS P Gothic par défaut n'a pas la même largeur. C'est difficile à voir car les chiffres sont disposés de manière irrégulière plutôt que dénués de sens. C'est étrange d'écrire le code qui spécifie même la police d'affichage. Ne spécifiez pas le format même s'il ne s'agit pas de texte enrichi.

** Seuls les retraits qui représentent la structure logique ** doivent être alignés. (** Retrait = retrait au début de la ligne. Non inclus dans la ligne **)

• Bien qu'il apparaisse souvent dans l'onglet de retrait ou dans la controverse d'espace, ** la justification dans une ligne n'est pas appelée retrait **.

Eh bien, s'il est spécifié dans la norme de codage, il sera aligné en crachant du sang. ** Normes de codage absolues. ** ** Cependant, personnellement, je n'aime pas ça. Décrivez-le au moins dans le fichier de paramètres du formateur commun au projet. Ne forcez pas un projet qui n'a même pas de fichier de configuration.

Bonus 1 (principalement sur les commentaires dans les déclarations if)

Je l'aime personnellement. À propos des commentaires dans les instructions if. Veuillez arrêter de mettre un commentaire après la parenthèse fermante dans la section précédente de if-else ou else. ** Java n'est pas C #. ** ** J'ai en fait créé un bug dans le passé en modifiant le code dans le deuxième exemple que je déteste ci-dessous. On m'a demandé de voter pour les personnes handicapées. C'est plus un traumatisme. Si vous le voyez, je veux m'en débarrasser de toutes mes forces. Je déteste vraiment ça parce qu'il est difficile de dire combien vaut une déclaration. Avez-vous besoin de ce commentaire en premier lieu? C'est vrai. De plus, s'il existe de nombreuses branches conditionnelles, je pense qu'il vaut mieux envisager d'en faire un type d'énumération et de l'écrire avec une instruction switch.

Eh bien, ** si les conventions de codage le sont, vous devez les suivre **. .. ..

//Exemple préféré
if (Condition A) {
  //En cas de condition A
} else if (Condition B) {
  //En cas de condition B
} else {
  //Autre que ce qui précède
}

//Je n'ai pas aimé l'exemple 1
//En cas de condition A
if (Condition A) {
}
//En cas de condition B
else if (Condition B) {
}
//Autre que ce qui précède
else {
}

//Je n'ai pas aimé l'exemple 2
//En cas de condition A
if (Condition A) {

//En cas de condition B
} else if (Condition B) {

//Autre que ce qui précède
} else {
}

Bonus 2 (références et matériel de lecture)

Articles auxquels vous souhaitez vous référer, articles intéressants, articles intéressants, etc. S'il vous plaît dans votre temps libre.

■ Programmation Java incroyable (arrêtons-nous) J'ai beaucoup ri. Il y a de nombreux cas que je vois souvent dans les revues de code des nouveaux arrivants.

■ Trois vertus majeures des programmeurs Je suis paresseux et impatient, donc je ne veux pas faire de tâches simples et je ne peux pas faire confiance à mes yeux. J'ai donc appris les fonctions Excel, VBA, les expressions régulières et SQL pour que je puisse laisser mon PC le faire. Il est largement utilisé sur le terrain. Le sentiment de s'amuser est très important.

■ Terminologie SE au pays des merveilles Mon article préféré. Je me demande pourquoi c'est. Quand je le remarque, je parle de ça.