[Coding style] Vos solutions pour un code lisible ?

[Sephi-Chan]

Bonsoir,

Je lance ce sujet pour connaître vos astuces, vos solutions, vos techniques, etc. pour un code lisible et maintenable.

N'hésitez-donc pas à citer les conventions et règles que vous avez adopté et surtout : montrez des bouts de code qui illustrent vos habitudes !


Sephi-Chan

[anthono]

Pour le php j'ai l'habitude de faire une page menu.php que j'include dans mon index, elle contient un switch qui lit la variable $_GET['page'] et dans chaque case je met la page que je veux include elle sont contenu dans un dossier page, je trouve que sa fait mieux rangez

[pascal]

Plein de trucs :
- utiliser un framework puissant et documenté (symfony)
- écrire moins de code
- éviter de coder des fonctionnalités inutiles
- placer le code au bon endroit : le script général, l'accès aux données, le html sont dans des endroits différents
- utiliser les conventions du framework

A+

Pascal

[JauneLaCouleur]

- Ne pas mettre de commentaire dans le code, mais "autour" du code.
- Utilisé des normes d'écriture et les conserver, du code homogène c'est le pied.
- Pas de JS dans de XHTML
- Pas de XHTML dans de PHP
- Revisité son code, tout les mois si c'est possible. Pour le code réutilisé, c'est indispensable. Ne pas se dire: " ca fonction donc je le garde comme ca. " Car PHP évolue beaucoup, et du code très complexe, peut devenir très simple. Et donc, plus performant.
- Ne jamais faire de copier-coller.
- Imprimer son code et le relire. (perso, je ne l'ai jamais fait, mais certain utilise cette technique pour faire du code propres)
- Indenté. ( c'est stupide, mais beaucoup ne le font pas correctement... )

[guile]

- des espaces autour des opérateurs... tous les opérateurs
- aligner les affectations (utiliser des tabulations pour faire en sorte que les = d'affections soit alignés)
- mettre les instructions similaires ensembles quand c'est possible
- mettre des sauts de ligne entre les groupes d'instructions
- utiliser des commentaires pour "présenter" le prochain groupe d'instructions (donc c'est à l'inverse de JauneLaCouleur MAIS pas tout à fait car les commentaires de ligne sont mis en fin de ligne, les commentaires de "groupe d'instructions" sont mis au dessus du code en question)
- camelCase

J'aime bien les conseils de JauneLaCouleur chez qui je retrouve de l'extrem programming :-D

[naholyr]

En plus de ce qui a déjà été dit par guile (j'ai l'impression qu'on a les mêmes conventions) :
- Factoriser.
- Nommer les fonctions en fonction de ce qu'elles font et non pas en fonction de leurs types d'entrée/retour.
- Nommer les variables en fonction de ce qu'elles sont et non pas en fonction de leur type.

[Sephi-Chan]

N'hésitez pas à poster le code source d'une de vos classe (par exemple) pour illustrer vos propos. Je pense que c'est plus parlant, et puis ça permet de partager/emprunter des astuces.

Par exemple, comment gérez vous la définition d'un grand tableau, sautez-vous à la ligne ? Si oui, quand ? Comment indentez-vous les lignes qui suivent ? Où placez-vous les parenthèses ? C'est ce genre de chose que j'aime bien voir quand je lis du code source.


Sephi-Chan

[Sephi-Chan]

Par exemple, êtes vous plutôt du genre à écrire :

def send_mail_forum_close(parameters)

  Notifier.deliver_forum_close(parameters.merge({ :user_name => name, :user_email => email, :user_points => points, :user_id => id })

end

Ou bien :

# User#send_mail_forum_close

# Send a mail to the user when a forum is closed.

# Add user specific parameters.

def send_mail_forum_close(parameters)

  Notifier.deliver_forum_close(

    parameters.merge({

      :user_name    => name,

      :user_email   => email,

      :user_points  => points,

      :user_id      => id

    })

  )

end

Ou encore (en Ruby, pas mal de caractères peuvent être omis (et le sont généralement )) :

# User#send_mail_forum_close

# Send a mail to the user when a forum is closed.

# Add user specific parameters.

def send_mail_forum_close(parameters)

  Notifier.deliver_forum_close(

    parameters.merge  :user_name    => name,

                      :user_email   => email,

                      :user_points  => points,

                      :user_id      => id

  )

end

Enfin, il y a beaucoup de manière d'agencer son code, et c'est justement ce genre de chose que j'aime bien voir (car il m'arrive souvent d'hésiter).

Notez qu'en Ruby, l'interpréteur cherche par défaut les variables et méthodes dans self. Aussi, puisque l'on est dans la classe User, je n'ai pas besoin de mettre self.name, self.email : name et email suffisent (par contre, si je veux affecter, je dois mettre self.machin = "Chose", sinon, Ruby va croire que c'est une affectation locale).


Sephi-Chan

[naholyr]

Méthode n° 2, mais avec un vrai langage par contre

[Sephi-Chan]

Méthode n° 2, mais avec un vrai langage par contre

Qu'est-ce que tu reproches à Ruby (n'hésite pas à me dire ça par MP, pour ne pas dériver si tôt) ?
Tu as pris la moins Rubyesque, la plus verbeuse. T'as vraiment pas la classe ! :p


Sephi-Chan