[JAVA] [Session d'étude interne] Introduction du "Code lisible"
0. Introduction
Personne cible
- Programmeur (C ++, Python, Java, JavaScript)
Qu'est-ce que "Code lisible"?
-
Un livre avec "des techniques simples et pratiques pour un bon code"
-
On dit que c'est un chef-d'œuvre et un bon livre Résumé des tweets de réponse après la sortie du livre Togetter "Readable Code"
-
Je veux que les ingénieurs informatiques le lisent! Grand prix du livre technique 2014
Ce que je veux dire
- Ramassez les cas des points de vue suivants à partir de "Code lisible"
- Éléments souvent soulignés dans la revue
- Des éléments faciles à expliquer
- Veuillez utiliser ceci comme une opportunité pour lire le "Code lisible". Les livres sont plus systématiques et plus faciles à comprendre. Tout ce qui est écrit est important.
Remarques
- Fondamentalement, seul le titre est publié et l'exemple de code n'est pas publié. Vous devez lire un livre pour bien comprendre.
- Le contenu écrit comme [Supplément] n'est pas répertorié dans le "Code lisible".
Contenu du "Code lisible"
Chapitre 1 Code facile à comprendre
Partie I Améliorations superficielles Chapitre 2 Informations d'emballage dans le nom Chapitre 3 Noms qui ne sont pas mal compris Chapitre 4 Beauté Chapitre 5 Sachez quoi commenter Chapitre 6 Les commentaires sont précis et concis
Partie II: Simplification de la boucle et de la logique Chapitre 7 Faciliter la lecture du flux de contrôle Chapitre 8 Diviser une énorme formule Chapitre 9 Variables et lisibilité
- Le chapitre 10 et au-delà ne sera pas introduit, donc omis
Introduction du «code lisible»
Chapitre 1 Code facile à comprendre
- Le code doit être facile à comprendre.
- Le principe le plus important dans l'écriture de code
- Le code doit être écrit afin que les autres puissent le comprendre dans les plus brefs délais.
- "Théorème de base de la lisibilité"
- "Le temps de comprendre" n'est pas du tout en conflit avec d'autres objectifs
- Un code facile à comprendre conduit souvent à une bonne conception et à une facilité de test.
Chapitre 2 Informations d'emballage dans le nom
2.2 Évitez les noms génériques tels que tmp et retval
- Il n'y a aucune information dans le nom retval. Utilisez un nom qui représente la valeur de la variable. Utilisez le nom * tmp uniquement pour les variables qui ont une durée de vie courte et pour lesquelles la complétion temporaire est la plus importante.
2.5 Déterminer la longueur du nom
- Les noms courts sont acceptables tant que la portée est petite
2.6 Communiquer les informations sous forme de nom
-
Vous pouvez remplir le nom avec des informations en utilisant des traits de soulignement, des tirets et des lettres majuscules.
-
[Supplément] Voir ci-dessous pour le format Java
Chapitre 3 Nom indubitable
- Demandez-vous plusieurs fois que le nom est "N'est-il pas confondu avec un autre sens?"
- Utilisez min et max pour indiquer les limites
- Utilisez le premier et le dernier pour indiquer la plage
- Utilisez le début et la fin pour les plages inclusives / exclusives
Supplément
- Notez les synonymes. Le synonyme de début est stop au lieu de fin. http://webspace.jugem.jp/?eid=947
3.6 Nom booléen
Le sens du vrai et du faux doit être clarifié.
Les variables suivantes peuvent être interprétées de deux manières.
bool read_password = true;
- Le mot de passe doit être lu ** à partir de maintenant **.
- Le mot de passe a été ** déjà ** lu
Il est préférable d'utiliser need_password ou ʻuser_is_authenticate`.
- Les noms de variables booléennes sont souvent préfixés par «is, has, can, should», etc. pour les rendre plus faciles à comprendre.
Chapitre 4 Beauté
Trois principes
- Utilisez une mise en page cohérente avec les modèles auxquels le lecteur est habitué.
- Un code similaire donne un aspect similaire
- Bloquer le code associé ensemble.
Chapitre 5 Sachez quoi commenter
5.2 Ce qui ne doit pas être commenté
- Ne commentez pas ce que vous pouvez dire à partir du code
- Renommez les noms terribles sans commentaire
- "Bon code> Code terrible + Bon commentaire"
5.3 Enregistrez vos pensées
- Pourquoi le code ressemble à ceci au lieu de l'inverse ("Commentaire du directeur")
- "Contexte" lié aux valeurs constantes
[Vue personnelle]
Il semble préférable d'écrire l'arrière-plan non seulement dans la source, mais également dans le nom de la table et le nom de la colonne de la base de données.
7.5 Revenir rapidement de la fonction
Certaines personnes pensent que les fonctions ne devraient pas utiliser plusieurs minutes de retour. Stupide. Il est bon de revenir rapidement de la fonction. Au contraire, c'est parfois souhaitable. ～ La raison pour laquelle nous voulons avoir une sortie de fonction est que nous voulons nous assurer que du code de nettoyage est exécuté. Les langues modernes offrent ce mécanisme d'une manière plus sophistiquée.
En Java, try ... finally est l'idiome du code de nettoyage.
[Supplément] La source de "l'interdiction des retours autres que la fin de la fonction"
MISRA-C, une "norme de conception logicielle pour le langage C", semble en être la source.
http://d.hatena.ne.jp/eel3/20121225/1356443485
9.2 Réduire la portée des variables
- Réduisez le nombre de lignes de code où les variables sont visibles autant que possible.
- Abaissez la position de la définition.
- La définition de variable se déplace juste avant d'utiliser la variable --Dans le langage C d'origine, il était nécessaire de définir des variables au début des fonctions et des blocs.
appendice
Règles générales de dénomination Java
- Nom de la classe: cas de chameau commençant par des lettres majuscules
- Variables: cas commençant par une minuscule
- Constante: tout en majuscule, cas de serpent (délimité par un trait de soulignement)
- Paquet: tout en minuscules
- Nommer les variables avec la nomenclature et les méthodes avec les verbes
Normes de codage de référence
Vue personnelle des conventions de codage
- Ne pas apporter de circonstances dans d'autres langues
- N'apportez pas les règles du langage C à Java
- Y compris le style de retrait, etc.
- Soyez conscient des temps
- Avec le développement de l'IDE, la définition du code facile à lire change un peu. --Java avait l'habitude de mettre un trait de soulignement à la fin d'un champ. Actuellement, il est affiché dans différentes couleurs dans l'EDI, il n'est donc pas recommandé. https://www.acroquest.co.jp/webworkshop/javacordingrule/Acroquest_JavaCodingStandard_7_0.pdf ――Le contenu du «code lisible» peut éventuellement devenir démodé.
Site de référence
http://qiita.com/AKB428/items/20e81ccc8d9998b5535d
Recommended Posts