5 questions qu’un développeur devrait se poser quand il code !

Soyez sociable ! Partagez :

Les bons développeurs le savent, il est difficile de maintenir un code qui ne respecte aucune convention de développement.

La communauté des développeurs a créé pour ça une espèce de charte de bonnes pratiques pour écrire du code propre.

5 questions qu'un développeur devrait se poser quand il code !

#1 - Est-ce que je peux faire plus simple ?

Le principe du " KISS (Keep It Simple, Stupid !) - Garde ça simple, idiot ! " doit répondre a une simple règle, comment je peux rendre mon code plus simple à lire.

Je vais prendre une exemple :

if(b == true)
  false
else
  true
end

Vous devriez être en train de rire tellement ça parait évident, mais le principe Keep It Simple, Stupid ! ressemble un peu à ça. On devrait écrire :

return !b

" Je choisirai un homme paresseux pour faire un travail difficile parce qu'il trouvera un moyen facile de le faire." - Bill Gates

#2 - Est-ce que je peux utiliser ça autre part ? ou Est-ce que j'ai déjà écrit ça ?

Dérière cette question, nous avons la règle " DRY (Don't Repeat Yourself) - Ne te répète pas " .

Le principe est simple, lorsque j'écris un morceau de code, je dois toujours me demander si ce bout de code peut être réutilisé.

<header>
  Bonjour <%= "#{@user.firstname} #{@user.lastname}" %> !
</header>

<div class="main">
  <%= "#{@user.firstname} #{@user.lastname}" %>, nous espérons que vous allez bien... Bla Bla Bla
</div>

<footer>
  Au revoir <%= "#{@user.firstname} #{@user.lastname}" %>
</footer>

Dans cet exemple, on peut voir que j'ai écrit trois fois la même chose, à savoir :

<%= "#{@user.firstname} #{@user.lastname}" %>

Il pourrait être intéressant dans mon modèle d'écrire la fonction suivante :

def name
  "#{self.firstname} #{self.lastname}"
end

Me permettant ainsi d'écrire un code plus propre :

<header>
  Bonjour <%= @user.name %> !
</header>

<div class="main">
  <%= @user.name %>, nous espérons que vous allez bien... Bla Bla Bla
</div>

<footer>
  Au revoir <%= @user.name %>
</footer>

D'autant que s'il me prend l'envie d'y ajouter le genre (M, Mme, Mlle) je n'ai qu'une modification à faire pour tout mon site.

#3 - Est-ce que ce que je fais n'a pas déjà été fait ?

Vous lez savez, on ne réinvente pas le fil à couper le beurre ! Et c'est inutile de re-coder systématique certaine fonction qui existe déjà...

Je vais prendre un exemple (valable en Ruby, mais je suis sûr qu'il existe des exemples similaires dans les autres langages) :

def print_price(price)
  "#{price.round(2)} €"
end

Je viens d'écrire une fonction pour afficher mon prix ! Super ! Mais si j'avais cherché un peu, j'aurai trouvé la fonction " number_to_currency " qui le fait également, et qui est natif à Ruby On Rails !

#4 - Est-ce que mon code est lisible ?

Quand j'ai appris à développer, j'étais surpris qu'on nous demande d'écrire nos fonctions sur papier avant de l'écrire sur ordi. Ainsi nos profs pouvaient ramasser nos copies et les corriger !

Une chose que j'ai appris par cette méthode, c'est qu'il faut écrire du code lisible, car j'ai reçu quelques 0 car mon code n'était pas lisible.

def toto
  bidule = "Janvier_Février_Mars_Avril_Mai_Juin_Juillet_Août_Septembre_Octobre_Novembre_Décembre".split("_")
  machin = 0
  bidule.each do |truc|
    case truc
    swith "Janvier", "Mars", "Mai", "Juillet", "Aout", "Octobre", "Décembre"
      machin = 31
    switch "Avril", "Juin", "Septembre", "Novembre"
      machin = 30
    switch "Février"
      machin = 28
    end
    puts "#{truc} a #{machin} jours"
  end
end

Ne nous posons pas trop de question sur l'utilité de cette fonction mais seulement sur la lisibilité:

• Le nom de la fonction n'est pas explicite
• Le nom des variables est très mal choisi

Ce qui fait qu'il faut interpréter le code dans sa tête pour comprendre ce que fait la fonction. Imaginons que le code ait été le suivant :

def print_day_count_by_month
  months = "Janvier_Février_Mars_Avril_Mai_Juin_Juillet_Août_Septembre_Octobre_Novembre_Décembre".split("_")
  day_count = 0
  months.each do |month|
    case month
    swith "Janvier", "Mars", "Mai", "Juillet", "Aout", "Octobre", "Décembre"
      day_count = 31
    switch "Avril", "Juin", "Septembre", "Novembre"
      day_count = 30
    switch "Février"
      day_count = 28
    end
    puts "#{month} a #{day_count} jours"
  end
end

Sans avoir à interpréter la fonction mentalement, on sait que la fonction sert à afficher le nombre de jour pour chaque mois.

5# - Est-ce que mon code va fonctionner ailleurs ?

On parle ici de portabilité de son code. D'une manière générale, votre code source devrait pouvoir être utilisable depuis n'importe qu'elle poste.

Ainsi je ne vais pas écrire :

path = '/home/paul/Documents/Projets/MyApp/vendors/'

Mais plutôt :

path = "#{Rails.root}/vendors/"

Ainsi, peu importe la station de travail que j'utilise, mon chemin sera toujours bon !

Si ici l'exemple est trivial, il faut appliquer ce principe partout dans votre application et toujours considérer que rien ne devrait être " Fait en dur " !

Soyez Sociable ! Partagez !