Blog de Toxicode

On écrit du code non seulement pour être compris de l’ordinateur ou d’autres programmeurs, mais aussi avec une intention esthétique. Un code qui plaît à l’œil a de la valeur en tant que tel et doit être encouragé au maximum. Cela ne veut pas dire que l’aspect esthétique est l’unique priorité, mais il a sa place aussi bien que les autres dans les critères de choix du programmeur

Mais qu’est-ce exactement qu’un beau code ? Quand on parle de Ruby, un beau code se situe souvent au croisement entre un assemblage d’idiomes Ruby et d’un langage customisé et spécifique à un domaine.

Voyons un exemple simple issu d’Active Record :

  class Project < ApplicationRecord

     belongs_to :account

     has_many :participants, class_name: ‘Person’

     validates_presence_of :name

   end

Cela ressemble à du DSL mais c’est une définition de classe avec trois appels de méthodes de classe qui prennent en paramètre des symboles et options. Il n’y a rien de sophistiqué, mais ces quelques lignes, aussi simples que jolies, offrent autant de pouvoir en plus que de flexibilité.

Une partie de la beauté de ces lignes de code vient de ce qu’elles honorent les principes mentionnés ci-avant, dont celui de Convention plutôt que Configuration.

Lorsqu’on crée une association avec un belongs_to :account, par convention on référence un modèle « Account » stocké dans la table nommée « accounts » via la clé « account_id ».

Un autre exemple du système de migrations de base de données :
   class CreateAccounts < ActiveRecord::Migration
     def change
       create_table :accounts do |t|
         t.integer :queenbee_id
         t.timestamps
       end
     end
   end

Le programmeur déclare une classe de façon conventionnelle, comme la sous classe ActiveRecord::Migration qui implémente #change, et le framework peut faire toute la plomberie autour, et sait que c’est cette méthode qu’il doit appeler. Dans le cas de ces migrations, cela va non seulement permettre d’appeler rails db:migrate pour mettre à jour la base de données avec cette nouvelle table mais aussi de la supprimer avec un autre appel.

Mais parfois, un beau code peut être plus subtil, et plutôt que de le rendre aussi bref que puissant, le challenge pourra être d’avoir une écriture fluide et bien rythmée.

Prenons ces deux lignes :

if people.include? person

if person.in? people

Même si le résultat est le même, le style et le focus sont légèrement différents. La première ligne se focalise sur la collection, tandis que la seconde se concentre sur la personne. Même si les deux lignes ont quasiment la même longueur, la deuxième semble beaucoup plus belle et peut susciter un réel plaisir esthétique pour le programmeur lorsqu’elle est utilisée dans un cas où la condition concerne la personne.