Un Electron Libre...

Quand j'ai vu cette chaine sur les conventions de codage se diffuser sur le web avant l'été (ici ou encore là), je me disais "enfin une qui va me passer à coté, je peux dormir tranquille", ne me considérant pas comme un développeur (ou alors un du dimanche ) et n'étant pas non plus développeur de formation... Et bien non, Nicolas Hoizey a décidé de me refiler cette chaine.

Pour les projets réalisés dans un cadre professionnel, pour tout ce qui a été en html/css/php et autres boucles SPIP, j'ai par le passé tenté de bêtement copier ce que faisaient mes petits camarades. Cela se justifiait principalement par le fait que j'intervenais ponctuellement sur le code et ne souhaitait pas les perturber plus que nécessaire.

Pour les projets réalisés dans un cadre professionnel et dont je suis à l'origine ou pour mes projets perso, je n'ai pas de règle précise, je vise surtout une logique de lisibilté.

Cela donnera par ex pour un script bash dont l'objectif est de packager des fichiers par ex :

#
## Get relevant information for the packaging
#
 
# Do we need to send file on the front server ?
... some code ...
 
# Do we need to send file on the database server ?
... some code ...
 
#
## Let's build the package
#
 
# Package files for front server
... some code ...
 
# Package files for database server
... some code ...

Je prends souvent ce schéma pour tout ce qui a trait à l'administration système et pour les CSS (en adaptant les caractères de commentaires bien sur...).

Pour continuer sur les CSS, mon ordre de fabrication de mon fichier va être le suivant :

• Eléments globaux / génériques
• Section des plus "grandes" vers les plus "petites" (body > left > sidebar)
• Au sein de chaque section, en premier lieux les éléments de positionnement puis ceux de mise en forme (pour reprendre une logique du plus grand au plus petit)

L'idée étant de regrouper le code en des sous-ensemble logiques.

Cela pourrait donner qqc comme :

/********************************
*  Elements généraux/generiques
********************************/
 
body {
}
 
h1 {
}
 
a {
}
 
/********************************
* Zone gauche
********************************/
 
#left {
}
 
/* Menu gauche */
 
#left #menu {
}
 
#left #menu a{
}

Par contre, là où j'ai toujours eu un souci avec PHP par ex, c'est sur la convention à suivre sur la gestion des accolades (qui en plus suivant l'IDE, l'interpréation peut changer) :

Ex :

if ($toto == "toto")
    {
    ... some code ...
    }

ou

if ($toto == "toto")
{
    ... some code ...
}

ou :

if ($toto == "toto") {
    ... some code ...
    }

ou :

if ($toto == "toto") {
    ... some code ...
}

Ou surement encore plein d'autres choses faisant que mon code au final se trouvait mal indenté (ou pas toujours de la même façon, ne parvenant pas à décider de ce qui était le plus lisible), surtout si les choses avaient tendance à s'imbriquer.

Je pense d'ailleurs que c'est une des raisons pour lesquelles j'aime python. L'indentation que l'on doit respecter permet de donner une bonne lisibilité du code. En plus, la charte de bonne conduite est clairement définie, même si je ne la suis pas encore dans son intégralité...

"""
Profile
 
This object is used to provide some common information regarding the profile of a user.
"""
 
class Profile(models.Model):
    CIVILITY_CHOICES = (
         ('single', _('Single')),
         ('taken', _('Taken')),
    )
    who = models.ForeignKey(User, unique=True, verbose_name=_('Person'),)
    photo = models.ImageField(height_field="80", width_field="80", upload_to="photos", blank=True)
    street = models.CharField(_('Address 1'), max_length=100)
    street_bis = models.CharField(_('Address 2'), max_length=100, blank=True)
    zipcode = models.IntegerField(_('Zip code'), max_length=5)
    city = models.CharField(_('City'), max_length=100)
    country = models.CharField(_('Country'), max_length=100)
    phone = models.CharField(_('Phone'), max_length=20)
    mobile = models.CharField(_('Mobile'), max_length=20, blank=True)
    civility = models.CharField(_('Status'), max_length=20, choices=CIVILITY_CHOICES)
    birthdate = models.DateField(_('Birth date'))
    children = models.IntegerField(_('Children'), blank=True, null=True)
 
    def __unicode__(self):
        return self.who.get_full_name()
 
    class Admin:
        list_display = ('who',)
        list_filter = ['who',]
        search_fields = ['who',]
 
    class Meta:
        verbose_name = _('Civil state')
        verbose_name_plural = _('Civil states')

Pour le débat indentation vs espace, j'avoue avoir préféré les espaces. Etant feinéant, je profitais aussi de la fonction de nombreux IDE qui transforment la tabulation en 4 espaces (ce qui permettait de continuer à utiliser la touche tab pour indenter son code...)

En tous cas, si je devais donner une conclusion à cet essai, que pour adopter une convention de codage, il faut :

• Regarder si une convention n'est pas définie au niveau du language, si oui, alors l'adopter.
• Regarder si une convention n'est pas définie au niveau du programme que vous utilisez, si oui, alors l'adopter (et si elle entre en conflit avec celle du langue, tant pis pour le langage, il est plus logique d'avoir un code cohérent)
• Si aucune des deux n'est définie, voir pour trouver une convention qui vous va bien à vous et le cas échéant à vos coéquipiers (à ce titre, mieux vaut en discuter avant le début du code qu'après, ça évitera de vous marcher dessus ensuite...)
• Adopter une terminologie anglaise (penser que votre code et commentaires peuvent être lus/utilisés par un prestataire indien - que feriez vous si vous deviez reprendre un code dont les commentaires sont en chinois par ex ?)

Je n'en finis pas de mes lectures. Dernier livre donc sur ma liste : Petit guide à l'usage du développeur agile.

Le livre m'a bien plu et surtout les derniers chapitres sur le Test Driven Development (TDD), Document Driven Development (zut, pas de bon lien à mettre) (DDD) et la gestion de projet. La partie sur Python en tant que telle m'est globalement passée au dessus de ma petite tête du fait de mon niveau actuel sur le langage (j'ai néanmoins glané quelques trucs ici et là, directement applicable dans mes dev en cours).

Ce livre ne vous aidera pas à appréhender python (enfin moi, cela ne m'a pas aider) et à la limite il n'aborderait pas python, ce ne serait pas grave. L'intérêt du livre n'est pas là mais bien dans les conseils, méthodo, bonnes pratiques qui sont énumérées. Bon faut quand même l'avouer, quand on voit comment TDD et DDD s'appliquent à Python, ça laisse rêveur (et l'équivalent n'existe pas pour PHP ou même Ruby apparemment, surtout pour DDD).

Les seules choses que j'ai trouvé un peu pénible dans le livre tiennent plutôt sur la forme (le formatage du code pourrait être amélioré, pas mal de typo/fautes d'orthographe, etc.)

En tous cas, à lire pour tout (bon) développeur / chef de projet qui se respecte !

D'autres critiques du livre :

• David, Biologeek : Envie de développer agilement en Python ? Suivez le guide !
• Luvit, fiche de Petit guide à l'usage du développeur agile