Conventions de nommage, conventions de code

"Salut, Amigo ! Aujourd'hui, je vais vous parler des styles de code et de l'importance du style de code."

"Je vais commencer par ce qui compte le plus.  Le code Java doit être facile à lire.  L'approche générale du code est la suivante : le code est écrit une fois mais lu cent fois."

"Supposons que vous et 10 autres programmeurs écriviez une application. Vous travaillez sur l'application pendant trois ans, avec des versions intermédiaires tous les trois mois."

"C'est long?"

« C'est Java, ma jeune sauterelle ! » Que diriez-vous d'un système d'entreprise tournant sur une dizaine de serveurs et écrit par 100 personnes sur plus de 6 ans ? Cela arrive aussi parfois."

"Waouh."

"Quoi qu'il en soit, la règle principale, la principale exigence pour le code est qu'il doit être facile à lire pour les autres développeurs."

"Dans d'autres langages de programmation, les gens travaillent souvent en petites équipes sur de petites tâches, ils peuvent donc avoir une autre règle principale, telle que 'Ça marche ? Excellent'."

"Au cours de quelques années, tous les membres de votre équipe apporteront plusieurs modifications au code que vous avez écrit. Et à chaque fois, ils devront comprendre comment le code fonctionne."

"Et un code incompréhensible qui fonctionne parfaitement est difficile à changer.  Ils le rejetteront et le réécriront à leur façon.  Alors, écrivez du code que les autres peuvent comprendre.  Si vous pouvez améliorer votre code, alors améliorez-le. S'il peut être amélioré, alors il faut l'améliorer ! "

"Si vous écrivez du code pendant 15 minutes et que vous passez ensuite deux heures à l'améliorer, vous le faites bien. Combien de temps faites-vous gagner à l'équipe ?"

"'2 heures pour comprendre votre code' x 'les 100 fois où les gens auront besoin de le comprendre' = 200 heures."

"J'ai tiré ces chiffres de nulle part, mais je veux que vous compreniez le problème et sa portée.  Votre code est créé pour être lu par d'autres programmeurs.  Tout le reste est secondaire."

"Le code ne fonctionne-t-il pas correctement ? Nous le corrigerons. Pas optimisé ? Nous l'optimiserons. Non documenté ? Nous ajouterons des commentaires."

« Le code est-il difficile à lire ? Jetez cette merde à la poubelle et écrivez tout à nouveau à partir de zéro ! »

"Je ne pensais pas que c'était si grave."

"L'une des raisons pour lesquelles Java est un langage de programmation de premier plan est que tout le code Java est écrit pour être lu par d'autres programmeurs."

« Passons maintenant à la deuxième question : comment rendre votre code le plus lisible possible ? »

"N'importe qui peut comprendre quand quelqu'un parle des mots familiers dans sa langue maternelle. Il en va de même ici. Le code est facile à lire lorsqu'un programmeur peut facilement deviner :

A)  Ce que fait chaque méthode

B)  Le but de chaque classe

C)  Exactement ce que chaque variable stocke.

Tout cela est communiqué dans des noms : noms de classe, noms de méthode et noms de variable. De plus, il y a du style quand il s'agit de nommer les variables. Et il y a le style de code."

"Je suis prêt à écouter."

" La programmation est basée sur un bon anglais !  Un programme bien écrit se lit comme une documentation technique ordinaire. "

« Commençons par les noms. »

"Un nom de méthode doit décrire brièvement ce que fait la méthode. Ensuite, le code peut être lu comme une simple prose."

public String downloadPhoto(String url)
{
 String resultFileName = TempHelper.createTempFileName();

 Downloader downloader = new SingleFileDownloader(new Url(url));
 downloader.setResultFileName(resultFileName)
 downloader.start();
 while(downloader.isDone())
 {
  Thread.sleep(1000);
 }

 if (downloader.hasError())
  return null;

 return resultFileName;
}

"Voici comment un tel programme est lu."

Ligne 1.

"La méthode s'appelle 'downloadPhoto'. Il semble qu'elle télécharge un fichier photo sur Internet. Où est-elle téléchargée ? Nous ne savons pas encore. D'où ? La méthode a un paramètre nommé url - c'est probablement l'URL de le téléchargement."

Ligne 3.

"La variable resultFileName est déclarée et affectée d'une valeur par TempHelper.createTempFileName();"

Il doit donc s'agir du chemin local vers le fichier où nous enregistrerons notre fichier téléchargé.

"Le nom 'TempHelper' ne nous dit rien. Le suffixe 'Helper' indique qu'il s'agit d'une sorte de classe utilitaire qui ne contient pas de logique métier importante, mais qui est plutôt utilisée pour simplifier les tâches de routine qui se produisent fréquemment."

"Le nom de la méthode 'createTempFileName' indique que cette méthode crée et renvoie le nom d'un fichier temporaire (fichier temporaire). Un fichier temporaire est un fichier temporaire qui est créé pendant un certain temps, puis généralement supprimé au moment où le programme est fermé. "

Ligne 5.

"Un objet SingleFileDownloader est créé et affecté au téléchargeur de variable."

C'est l'objet qui va télécharger notre fichier depuis Internet.

"Un objet SingleFileDownloader est affecté au téléchargeur de variables. D'après le nom, nous pouvons supposer que le programme a plusieurs types de classes de téléchargeur. L'un a été écrit pour télécharger des fichiers uniques, et nous pouvons probablement nous attendre à rencontrer d'autres téléchargeurs dans le code pour les groupes de fichiers avec des noms tels que : MultiFileDownloader, FileGroupDownloader ou DirectoryDownloader"

Ligne 6.

"Nous définissons la propriété resultFileName de l'objet téléchargeur égale à la valeur de la variable resultFileName. En d'autres termes, nous indiquons au chargeur où enregistrer le fichier téléchargé. Comme vous vous en doutez. Donc, nous prédisons essentiellement le code !"

Ligne 7.

"Nous appelons la méthode de démarrage. Le téléchargement démarre. Cela a du sens. Je me demande comment le téléchargement se passe : par parties, sur un fil séparé, ou le tout ici ? Si nous téléchargeons le tout ici, cela pourrait prendre un certain temps. longtemps et avoir des conséquences."

Lignes 8-11.

"Ah. Ici, nous voyons la boucle standard écrite par quelqu'un qui attend la fin d'un téléchargement. L'objet downloder a une propriété done, qui est renvoyée par la méthode isDone(). Parce que la méthode s'appelle isDone(), plutôt que getDone( ), nous concluons que la variable done est un booléen ou peut-être un booléen."

Lignes 13-14.

"Si une erreur se produit pendant le téléchargement, la méthode downloadPhoto renvoie null. C'est bien qu'elle gère les erreurs. C'est dommage qu'elle renvoie simplement null - on ne sait pas quelle est l'erreur. Il serait préférable de lever une exception avec des informations sur l'erreur."

Ligne 16.

"Nous renvoyons le chemin vers le fichier local qui contient le fichier téléchargé."

« Waouh ! »

"Le code de ce programme permet de comprendre parfaitement ce qu'il fait. Vous pouvez même faire des suppositions sur la façon dont le programme est organisé et sur les autres classes/méthodes que nous trouverons."

"Maintenant, je comprends à quel point les noms sont importants."

"En savoir plus sur les noms. Vous pouvez souvent deviner les méthodes d'un objet/classe. Par exemple, si un objet est une collection, il aura très probablement une méthode size() ou count() pour obtenir le nombre d'éléments. Aussi , il aura probablement une méthode add() ou insert(). Les éléments sont extraits des classes de collection à l'aide des méthodes get/getItem/getElement."

"Si une variable est appelée i, j ou k, il s'agit très probablement d'un compteur de boucle."

"Si une variable est appelée m ou n, il s'agit très probablement de la taille d'un tableau/d'une collection."

"Si une variable est appelée nom, il s'agit très probablement d'une chaîne contenant le nom de quelqu'un."

"Si une classe s'appelle FileInputStream, alors c'est à la fois un fichier et un flux d'entrée."

"Plus vous voyez de code, plus il est facile de lire le code des autres."

"Mais parfois il y a du code qui est très difficile à lire. Dans ce cas, voici un conseil très pratique :"

"C'est drôle et pas drôle en même temps."

"Maintenant, parlons un peu des styles utilisés pour nommer les variables."

"Les développeurs Java essaient de donner des noms très informatifs aux variables et aux méthodes. Par conséquent, les noms sont souvent constitués de plusieurs mots. Il existe 4 styles pour la capitalisation des noms composés."

1) Minuscules  - Tous les mots sont écrits avec des lettres minuscules. Par exemple:

'Serre'  devient 'serre'

'Hollywood girl'  devient  'hollywoodgirl'

Ce style est utilisé pour les noms de packages.

2) Majuscules  – Tous les mots sont écrits en majuscules et séparés par un trait de soulignement. Par exemple:

La "valeur maximale"  devient MAX_VALUE

"Nombre de chats"  devient CAT_COUNT

"Ce style est utilisé pour les noms de constantes (champs statiques finaux)."

3) CamelCase  - Tous les mots sont écrits en minuscules, sauf que la première lettre de chaque mot est en majuscule. Par exemple:

'Green house'  devient  'GreenHouse'

'Hollywood girl'  devient 'HollywoodGirl'

Ce style est utilisé pour les noms de classes et d'interfaces.

4) Lower CamelCase (casse mixte)  - Tous les mots sont écrits en minuscules, à l'exception de la première lettre de chaque mot, sauf que la première est en majuscule. Par exemple:

'Get width' devient 'getWidth'

'Get Hollywood girl name' devient  'getHollywoodGirlName'

"Ce style est utilisé pour les noms de variables et de méthodes."

"Donc, il n'y a pas trop de règles."

1)  Tout est écrit en Lower CamelCase.

2)  Les noms de classes et d'interfaces sont toujours en majuscules.

3)  Les noms de packages sont toujours en minuscules.

4)  Les constantes sont toujours en majuscules.

"Il y a quelques nuances, mais en général c'est comme ça."

"Parlons maintenant des méthodes.  "Les noms de méthodes commencent presque toujours par un verbe ! 'count' est un mauvais nom pour une méthode. Il vaut mieux l'appeler getCount(). Une méthode effectue une action sur l'objet :  startDownload , interrupt  , sleep  , loadPirateMusic ."

"Comme vous le savez déjà, il existe des getters et des setters pour travailler avec les propriétés/champs d'un objet :  getName / setName , getCount / setCount , etc."

"La seule exception est pour les booléens. Pour les booléens, les noms getter utilisent 'is', pas 'get', par exemple isDone, isEmpty. De cette façon, c'est plus proche du discours ordinaire."

« Que diriez-vous de travailler deux heures par jour au lieu de 8 ? Tenté ?

"Oui!"

"Comme il se doit. Pour un développeur Java junior, l'exigence de base est une excellente compréhension des bases de Java, c'est-à-dire Java Core."

"J'ai une autre question. Pourquoi avons-nous ces différentes méthodes pour obtenir le nombre d'éléments ?"

"Tout d'abord, Java a été inventé il y a plus de 20 ans, avant que des exigences telles que setCount / getCount aient été établies, et il y avait une approche commune tirée du langage C pour" le rendre aussi court que possible "."

"Deuxièmement, la sémantique joue ici un rôle. Quand on parle d'un tableau, on parle de sa longueur. Quand on parle d'une collection, on parle de sa taille."

"Quelle leçon intéressante."

"J'aimerais t'en dire plus, mais j'ai peur que tu ne te souviennes pas de tout d'un coup. Il vaut mieux te le servir par petites portions."

"Mais je veux aborder le style concernant l'utilisation des accolades : {}. Il existe deux approches :"

1)  Le support va sur une nouvelle ligne à chaque fois

2)  La parenthèse ouvrante va à la fin de la ligne précédente, tandis que la parenthèse fermante va sur une nouvelle ligne. Ce style est appelé « accolades égyptiennes ».

"Honnêtement, vous pouvez choisir comment coder. Beaucoup de gens utilisent une accolade ouvrante sur la même ligne. Beaucoup de gens la mettent sur une nouvelle ligne. C'est comme le débat sur le bout de l'œuf à casser : le petit bout ou le gros. fin."

"La seule chose que je peux recommander est de s'en tenir au style utilisé dans le projet sur lequel vous travaillez. Ne modifiez pas le code de quelqu'un d'autre pour qu'il corresponde à votre style préféré.  Les gens sont imparfaits. Je vous le dis en tant que docteur Bilaabo. "

"Merci pour cette leçon intéressante, Bilaabo. Je vais réfléchir à ce que vous avez dit."