Vous avez décidé de devenir un bourré qui rêve tout le temps, misogyne, quoi d’autres ? programmeur, parfait, comme dans la plus part de métier, le début demande à ce qu’on soit passif, être à l’écoute de ceux qui ont plus d’expérience et chercher à mieux évoluer.
En fait, dans la programmation, le vrai problème que rencontre les programmeurs, ce n’est généralement pas algorithmique c’est-à-dire, le problème du projet à résoudre, mais c’est l’organisation générale qui affecte le projet et donc, rend ainsi difficile la résolution de problème du projet. Partant de la structure du projet au développeur, sans une strict rigueur, on reste faucher sur la résolution de problème du problème de problème du projet au lieu de résoudre directement le problème du projet.
Étant que développeur, la manière de coder influence fortement la résolution du problème à long terme. Que cela soit un projet où vous coder seul ou en équipe, certaines bonnes pratiques aident à rester focus sur le projet et celles-là devraient devenir une routine.
Dans cet article, je veux partager avec vous une habitude étant que développeur que vous devriez adopter tant dans un projet solo que collectif pour coder proprement et efficacement.

Le meilleur code source est celui qui en même temps résout le problème et est facile à comprendre.

 

le développeur n’est pas seulement une personne qui écrit du code pour une machine, mais c’est aussi un auteur qui écrit du code que les autres doivent pouvoir relire et comprendre

Robert C. Martin dans Coder proprement (2013)

Les commentaires

Si ce n’était pas la première notion après << Hello world >> que vous avez apprise quand vous appreniez votre langage de programmation préféré, c’est sans doute parmi le 5 d’entre-elle. Avec un projet encore petit, on peut sans doute se passer des commentaires. Mais dès que vous commencez à atteindre 500 à 1000 ligne de code, les commentaires deviennent indispensable tant pour l’équipe que pour soit même.
Mais ce qui est malheureux est qu’au début, on a tendance à faire des projets assez petits que l’habitude de ne pas commenter devient principale. Peu importe le projet, ayez toujours l’habitude de commenter votre code, que cela soit systématique.
Vous n’avez pas besoin de faire des paragraphes dans un commentaire du code source, cela est dédié à la documentation. Un commentaire de code source doit être bref, concis et explicite. L’usage de celui ci est de dire à celui qui le lit sa raison d’être, donner une idée de ce qu’à voulu dire l’auteur.

Nomenclature des identifications

Un identificateur est un mot choisi par le programmeur pour représenter une donnée quelconque. C’est le cas de variable, constant, classe, argument, fonction ou procédure. Implicite que cela pourrait être, juste la bonne nomenclature de ses identificateurs peut rendre votre code assez claire pour quiconque le lira.

Style typographique

Il faut toujours chercher à avoir une logique ou convention unique de nommer vos identifiants ou une catégorie d’identifiant. Logiquement, la convention de nomenclature des identifiants est à la charge du maitre d’œuvre ou le chef du projet lors de l’écriture de la spécification technique du projet mais étant que développeur, vous devriez avoir aussi votre manière homogène ou convention personnelle de nommer vos identificateurs. Certains préfèrent camelCase , d’autres c’est le snack_case.

Un nom sémantique de l’identificateur

Un identificateur représente une donnée, un identificateur bien choisi devrait directement refléter la donnée qu’elle doit contenir au regard de celui qui lit votre code. Vous ne devriez pas abréger vos identificateurs. Je ne sais pas pourquoi une variable qui doit contenir les données d’un utilisateur devrait être nommée seulement ‘u‘ ou ‘a‘. Ce qu’il faut savoir par les noms des identifiants :

  • Donner un nom sensé, qui permet à quelqu’un de déduire facilement ce que contiendra la variable
  • Respecter la cardinalité de la variable. Ex: Une variable qui contiendra qu’un seul utilisateur peut être nommée ‘user’ et celle qui contiendra une collection d’utilisateur peut être nommée ‘users’.
  • Pour les fonctions ou méthodes, donner toujours le nom de la fonction, l’opération ou l’action qu’elle effectue.

Utilisation d’un logiciel de gestion de version

Qu’il soit un travail collectif ou individuel, l’utilisation d’un logiciel de gestion de version dans son projet est une bonne habitude qu’un développeur doit adopter. Il y a Git qui est assez utilisé mais comme c’est une question de préférence, certains préfèrent d’autres que celui ci comme SubVersion (SVN)

Enfin, les bonnes habitudes, on les développe souvent soit même sur base d’expérience, mais en générale, il faut toujours éviter de se répéter.

Catégorisé: