L’art de coder

Citations

Bjarne Stroustrup (inventeur du c++)
” J’aime que mon code soit élégant et efficace.
La logique doit être simple pour que les bogues aient du mal à se cacher.
Les dépendances doivent être minimes afin de faciliter la maintenance.
La gestion des erreurs doit être totale.
Les performances doivent être proche de l’idéal afin que personne ne soit tenté d’apporter des optimisations éhontées qui dégraderaient le code. ”

Bjarne Stroustrup (inventeur du c++)
” Un code propre est un code simple et direct.
Il se lit comme une prose parfaitement écrite.
Un code propre ne cache jamais les intentions du concepteur, mais est au contraire constitué d’abstractions nettes et de lignes de contrôle franches. ”

Michael Feathers, auteur de Working Effectively with Legacy Code
Je pourrais établir la liste de toutes les qualités que j’ai notées dans un code propre,
mais l’une d’elles surpasse toutes les autres.
Un code propre semble toujours avoir été écrit par quelqu’un de soigné.
Rien ne permet de l’améliorer de manière évidente. Tout a déjà été réfléchi par l’auteur du code et, si vous tentez d’imaginer des améliorations, vous revenez au point de départ, en appréciant le code que l’on vous a laissé, un code laissé par quelqu’un qui se souciait énormément de son métier.


Choisir des noms révélateurs des intentions

Choisir de bons noms prend du temps, mais permet d’en gagner plus encore. Vous devez donc faire attention à vos noms et les changer dès que vous en trouvez de meilleurs.

eviter
// Temps écoulé en jours
int d;

 

permisint elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

A EVITER:
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}

Supposons que nous travaillions sur un jeu du type démineur.

VALIDE:
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}

Choisir des noms prononçables

Si nous ne pouvons pas les prononcer, nous ne pouvons pas en discuter sans paraître
idiots. La programmation étant une activité sociale, cet aspect est important.


Les fonctions

La première règle  est d’écrire des fonctions courtes.
La deuxième règle est qu’elles doivent être encore plus courtes que cela.

UNE FONCTION DOIT FAIRE UNE SEULE CHOSE.
ELLE DOIT LA FAIRE BIEN ET NE FAIRE QU’ELLE.
Plus une fonction est courte et ciblée, plus il est facile de choisir un nom descriptif.

Le niveau d’indentation d’une fonction ne doit donc pas être supérieur à un
ou deux. Par ailleurs, les fonctions sont ainsi plus faciles à lire et à comprendre.

Un niveau d’abstraction par fonction.
Pour inclure les pages de montage et de démontage, nous incluons le montage, puis le contenu de la page de test et enfin le démontage. Pour inclure le montage, nous incluons le montage d’une suite s’il s’agit d’une suite, puis nous incluons le montage normal. Pour inclure le montage d’une suite, nous recherchons la page “SuiteSetUp” dans la hiérarchie parente et nous incluons une instruction avec le chemin de cette page. Pour rechercher le parent…

Les couplages temporels

eviterpublic void dive(String reason) {
saturateGradient();
reticulateSplines();
diveForMoog(reason); }

permis

public void dive(String reason) {
   Gradient gradient = saturateGradient();
   List<Spline> splines = reticulateSplines(gradient);

   diveForMoog(splines, reason); }

Chaque fonction produit un résultat dont la suivante a besoin. Il
n’existe donc aucune manière sensée de les invoquer dans le désordre.

“Vous savez que vous travaillez avec du code propre lorsque chaque fonction que vous lisez correspond presque parfaitement à ce que vous attendiez.”

N’ayez pas peur de créer un nom long.

Un nom long descriptif vaut mieux qu’un nom court énigmatique complété d’un long commentaire descriptif.

Arguments d’une fonction

Idéalement, le nombre d’arguments d’une fonction devrait être égal à zéro.
Ensuite viennent les fonctions à un argument, puis à deux arguments.


A EVITER
Les fonctions à trois arguments doivent être évitées autant que possible. Les fonctions qui prennent plus de trois arguments exige une très bonne raison ou ne doivent jamais être employées.

Objets en argument d’une fonction

Lorsque des groupes de variables sont passés ensemble, il est fort probable qu’ils fassent partie d’un concept qui mérite son propre nom. Il est conseillé alors de réduire le nombre d’argument en créant des objets.

Une fonction doit posséder une entrée et une sortie

Pour respecter cette règle, il ne doit y avoir qu’une seule instruction return dans une fonction, aucune instruction break ou continue dans une boucle et jamais, au grand jamais, d’instruction goto.
L’ ART DE LA PROGRAMMATION EST L’ART DE LA CONCEPTION DU LANGUAGE.

Le véritable objectif est de raconter l’histoire du système et que les fonctions écrites doivent s’unir proprement en un langage clair et précis.

Les commentaires

Les commentaires sont, au mieux, un mal nécessaire. Si nos langages de programmation étaient suffisamment expressifs ou si nous avions suffisamment de talent pour les manier de manière à exprimer nos intentions, nous n’aurions pas souvent besoin des commentaires, voire jamais.

Par conséquent, lorsque vous éprouvez le besoin d’écrire un commentaire, réfléchissez
et essayez de trouver une solution pour exprimer vos intentions avec du code.
Chaque fois que vous écrivez un commentaire, faites la grimace et ressentez le poids de

l’échec.

eviter// Vérifier si l’employé peut bénéficier de tous les avantages.
if ((employee.flags & HOURLY_FLAG) &&(employee.age > 65))

 

permis

if (employee.isEligibleForFullBenefits())


La mise en forme

La mise en forme du code se place au niveau de la communication.
La communication est le premier commandement du développeur professionnel.

Vous pensiez peut-être que le premier commandement du développeur professionnel

était “faire en sorte que cela fonctionne”.

Des fichiers contiennent généralement 200 lignes, et une taille maximale de 500 lignes. Les fichiers courts sont généralement plus faciles à comprendre que les fichiers longs.

Les variables de contrôle des boucles doivent généralement être déclarées juste avant l’instruction de boucle.

public int countTestCases() {
   int count= 0;
   for (Test each: tests)
      count += each.countTestCases();
   return count;
}

Variables d’instance
A contrario, les variables d’instance doivent être déclarées au début de la classe.

Fonctions dépendantes
Lorsqu’une fonction en appelle une autre, les deux doivent être verticalement proches
et l’appelant doit se trouver au-dessus de l’appelé, si possible.

Constante et fonction
Il était préférable de passer une constante depuis l’endroit où la connaître a un sens que de la cacher dans une fonction.

Affinité conceptuelle
Certaines parties du code veulent se trouver à côté de certaines autres. Elles présentent une affinité conceptuelle. Plus cette affinité est grande, moins la distance verticale qui les sépare est importante.

Moins le fichier propose de méthodes, mieux c’est.
Moins une fonction connaît de variables, mieux c’est. Moins un fichier contient de
variables globale, mieux c’est.