JeuWeb - Crée ton jeu par navigateur
[Coding style] Vos solutions pour un code lisible ? - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [Coding style] Vos solutions pour un code lisible ? (/showthread.php?tid=4309)

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17


RE: [Coding style] Vos solutions pour un code lisible ? - Sephi-Chan - 29-08-2009

(29-08-2009, 12:55 PM)NicoMSEvent a écrit : moi par contre, je préfixe mes variables en fonction de leur portée.
g_ pour les gobales
l_ pour les locales
s_ pour les statiques
p_ pour les paramètres passés (éventuellement pi_ po_ pio_ pour les paramètres en entrée/sortie si le langage le permet (comme PL/SQL), sinon en général ma valeur de retour pour une fonction sera tjs l_ret

C'est amusant que tu soulèves ce point. En Ruby, la portée est définie par un caractère qui préfixe le nom de la variable.


class Character

@@count = 0 # Ça commence par @@ donc c'est une variable de classe.

# Retourne le nombre de personnages instanciés.
# Le self.count indique que c'est une méthode de classe.
def self.count
@@count
end

# Constructeur.
def initialize(name)
@name = name # Ça commence par @ donc c'est un attribut.
@@count += 1
end

end

$lang = "fr" # Ça commence par $ donc c'est global.

corwin = Character.new('Corwin') # Quand on ne met rien de spécial, c'est local.
mandor = Character.new('Mandor') # Quand on ne met rien de spécial, c'est local.

puts "#{Character.count} personnages instanciés." # 2

Encre une fois, Ruby se montre peu verbeux est très clair. On écrit peu et on identifie les portées d'un simple coup d'oeil.


(29-08-2009, 03:11 PM)OncleJames a écrit : Travaillant en équipe et à distance, cette notation nous a fait gagner bien du temps.
Elle ne demande pas de changer le nom, sa fonction, .. juste de préciser ce qu'elle contient.

Dans des listes de fonctions, savoir ce que l'on doit passer en argument juste en regardant son nom, c'est très agréable (et gain de temps par la même occasion, au lieu d'embêter ses voisins à comprendre ce qu'ils ont programmés :nonSmile.

À mons sens, le nommage et la documentation suffisent.
Mais du moment que ça vous aide, c'est l'essentiel. Wink


Sephi-Chan


RE: [Coding style] Vos solutions pour un code lisible ? - naholyr - 29-08-2009

Pas de variables globales, ça simplifie encore plus le processus :lol:
Et des fonctions suffisamment courtes pour que la liste des paramètres soit toujours à portée de vue, ça permet d'être sûr qu'on sait toujours si on manipule une variable locale "classique" ou un paramètre d'entrée.

Finalement, en s'astreignant à ne pas faire joujou avec des notations exotiques, on s'ajoute des règles très saines Tongue


RE: [Coding style] Vos solutions pour un code lisible ? - Zamentur - 01-09-2009

Alors pour ma part j'utilise dans al-gol des conventions décrite dans un document à destination des éventuel développeur qui voudrait rejoindre le projet, en voici donc un extrait:

Citation :Les commentaires

Il y a 2 types de commentaire:
  • Les commentaires du code :Ils servent à savoir ce que fait un bout de code
  • Les commentaire de génération de doc :Ils servent à générer la doc de toutes les pages, fonctions, classes, méthodes, variables du projet. Pour ces derniers il faut suivre la syntaxe de http://www.PHPdoc.org .

Les commentaires doivent être en français car le projet n'a pas pour intention d'accueillir des codeurs non francophone.

Convention de nommage
  • Les noms en anglais:
    Il est demandé de nommer les variables, et autre nom de page, méthode ou autre en anglais.

    Ceci afin de garder une homogénéité avec le code natif de php

  • Les fichiers contenus dans un sous répertoire (différent de db et doc) doivent porter leur noms, exemple:

    Autorisé: /lang/fr/upload.fr.php /index.php /class/upload.class.php /media/css/book.css /media/tpl/book.tpl.php

    Interdit: /class/upload.php

  • Les répertoires doivent avoir des noms uniques.

  • Tous les noms doivent être en minuscule.

  • On utilise toujours le _ plutôt que le -.

Règle de codage
Code PHP :
<?php 
public static function exemple() {
while (
$ma_condition_ultra_supra_longue_qui_prend_plus_de_80_caracteres)
echo
'mon instruction se place alors en dessous et indenté';

$tableaux=array(
'id' => 'test',
'id_long' => 'test',
'id2' => 'test',
'id3' => 'test'
);

if (
true) {
echo
'zut';
return
false;
}
else echo
'la ligne est courte pas besoin de mettre en dessous!';


}
  • L'indentation doit être de 4 espaces
  • L'accolade ouvrante doit se trouver sur la même ligne que la structure de contrôle (if,else, switch, while...)
  • L'accolade fermante doit se trouver au même niveau que la première lettre de l'instruction de la structure de contrôle
  • Si il n'y a qu'une seul action, les accolades peuvent être omise. Dans ce cas l'actions doit être sur la même ligne que l'instruction de la structure de contrôle OU sur la ligne du dessous avec un décalage d'une indentation si la lisibilité s'en trouve gêné (condition trop longue).
  • Les longs array doivent être présenté comme dans l'exemple
  • [TODO] Tris des méthodes (alphabétique?)

Il y aussi des conventions pour l'arborescence des fichiers.

Et je part du principe qu'une méthode/fonction ne doit faire qu'une action et que son code doit se concentrer la dessus. Par exemple, pas question de mettre if ($number>0) $text.='s'; en plein milieu d'une méthode d'affichage d'un message, car sa génération n'est pas de son ressort.

Sinon je porte beaucoup d'importance à l'écriture d'un fichier de test pour chaque classe, avant même que celle ci soit créer voir même complètement conceptualisé. Cette technique permet de voir comment doit réagir la boite avant même son existence. La revue de ce fichier peut être faite pendant qu'on code la classe proprement dite si une idée vient.

A la fin le code est revu, réorganisé, simplifié, les commentaires phpdocumentor complété si inexistant. La classe est alors considéré comme stable.

Je n'utilise pas de framework pour l'instant, mais j'y viendrait peut être, par contre j'utilise une organisation MVC basique de mon cru.


RE: [Coding style] Vos solutions pour un code lisible ? - Argorate - 01-09-2009

Personnellement, je n'aime pas du tout la pratique asymétrique dans le code de ce style:

Code PHP :
<?php 
function test () {

if(...) {
...
}

return ...
}

Pour plus de clarté et de visibilité, je préfère une écriture en alignement, on vois d'où on part et où ça s'arrete. Wink
Code PHP :
<?php 
function test ()
{

if(...)
{
...
}

return ...
}



RE: [Coding style] Vos solutions pour un code lisible ? - Sephi-Chan - 01-09-2009

Quand j'écrivais en PHP, je préférais la notation :


if(true == true){
echo "Moi j'aime le pâté !";
}

Je n'aime pas la notation qui consiste à omettre les accolades, à moins que l'unique instruction soit très courte et soit placé sur la même ligne.

Une autre notation que je ne supporte pas :

function test () {
}

Les espaces de part et d'autres des parenthèses n'ont pas de sens et sont source d'erreur.


Côté Ruby, j'utilise cette syntaxe :


# Generate a notification frame with the given content.
def notification_tag(message)
content_tag :div, :class => 'notification' do
message
end
end

Notons toutefois qu'on peut mettre l'instruction sur une seule ligne, et/ou remplacer le do par un { et le end par un }. Comme cela :


content_tag :div, :class => 'notification' {
message
}

content_tag :div, :class => 'notification' do message end

content_tag :div, :class => 'notification' do { message }

J'expliquerai l'utilisation des blocs dans un article à part. C'est une autre petite perle du langage Ruby.


Sephi-Chan


RE: [Coding style] Vos solutions pour un code lisible ? - Argorate - 01-09-2009

Autant la notion d'espace entre condition et accolade - ou entre mot clé et parenthèse - je trouve que c'est totalement libre a chacun et que ça ne nuit pas a la lisibilité ni au fonctionnement, autant je n'aime pas cette histoire d'accolade "caché"...

PS: j'imagine bien que c'est pour l'exemple, mais pas d'accolade pour une instruction^^ et pas de guillemet pour un echo de ce genre :p

Si je dis ça, c’est pour empêcher que des gens qui passent vite fait, retiennent des mauvaises choses.


RE: [Coding style] Vos solutions pour un code lisible ? - Sephi-Chan - 01-09-2009

(01-09-2009, 08:07 PM)Argorate a écrit : PS: j'imagine bien que c'est pour l'exemple, mais pas d'accolade pour une instruction^^ et pas de guillemet pour un echo de ce genre :p

Si je dis ça, c’est pour empêcher que des gens qui passent vite fait, retiennent des mauvaises choses.

J'utilise des guillemets doubles pour ne pas avoir à échapper l'apostrophe de ma chaîne. C'est la meilleure alternative pour la lisibilité.


// Mauvaise notation.
echo 'Moi j\'aime le pâté !;

// Bonne notation.
echo "Moi j'aime le pâté !";

De même, quand on doit intégrer des variables, il est plus lisible (et donc maintenable) d'utiliser les guillemets doubles, et de toujours encadrer la variable (que ce soit une variable scalaire, un tableau ou un objet) d'accolades.


// Mauvaise notation.
echo 'Moi j\'aime le ' . nourriture . ' pâté !;

// Bonne notation.
echo "Moi j'aime le {$nourriture} !";


Et justement, s'il y a bien quelque chose à retenir, c'est — à mon avis — de ne pas utiliser la forme sans accolade.

Voici mon (donc ça n'est que mon avis) classement, du pire vers le meilleur :


// La notation la plus sale et la plus sensible en terme de maintenabilité.
if(true == true)
echo "Moi j'aime le pâté !";

// Il y a du mieux, mais c'est toujours pas top pour la maintenabilité.
if(true == true) echo "Moi j'aime le pâté !";

// Un peu plus propre, aucune ambiguïté.
if(true == true){ echo "Moi j'aime le pâté !"; }

// La bonne notation : aucune ambiguïté possible, ni maintenant, ni dans le futur.
if(true == true){
echo "Moi j'aime le pâté !";
}

À mon sens, ce sont les clés d'un code utilisable dans l'industrie du développement, où le travail en équipe et la maintenabilité sont de vrais challenge.


Sephi-Chan


RE: [Coding style] Vos solutions pour un code lisible ? - Argorate - 01-09-2009

Tien donc, encore un truc où je ne suis pas de cette avis ^^

Les guillemets te font perdre du temps d'exécution.
et mettre un anti-slash ce n’est pas la mort et n'a rien d'horrible ou d'ambigu.

Quand a rajouter des accolade quand il n'y en a pas besoin => rajout de caractères inutiles => lisibilité--

M'enfin comme tu veux Smile


RE: [Coding style] Vos solutions pour un code lisible ? - NicoMSEvent - 01-09-2009

Pour moi, déjà, ne pas avoir de données dans les traitements (idéalement Wink )

Donc, pas de chaine de caractères, ce qui signifie pas de " ni de ' ^^

On les stocke en DB, avec des htmlentities($chaine,ENT_QUOTES,'UTF-8') afin d'éviter tout problème de caractères spéciaux, guillements, apostrophes, etc...

J'apprécie ce genre de code aussi :
Code :
echo $condition?$resultat_db['msg_ok']:$resultat_db['msg_fail'];
Et p-e même ceci par extension. Je trouve ça très parlant. Peut-être déroutant pour les néophytes... mais on en prends vite l'habitude ^^
Code :
echo $resultat_db[$condition?'msg_ok':'msg_fail'];

j'externalise en maximum, j'ai un fichier avec toutes mes requetes SQL, paramétrables avec un sprintf
Code :
$req_insert_operation="INSERT INTO operation (nom,password,msg_ok,msg_fail) VALUES ('%s',PASSWORD('%s'),'%s','%s');";
$req_sel_operation="SELECT * FROM operation WHERE id='%s';"
et ensuite je les utilise comme ceci :
Code :
RequestDB( //j'appelle ici a ma couche d'abstraction DB
    sprintf($req_insert_perso
        ,htmlentities($_POST['nom'],ENT_QUOTES,'UTF-8')
        ,htmlentities($_POST['password'],ENT_QUOTES,'UTF-8')
        ,htmlentities($_POST['msg_ok'],ENT_QUOTES,'UTF-8')
        ,htmlentities($_POST['msg_fail'],ENT_QUOTES,'UTF-8')
    )
);
ça demande de connaitre les arguments a passer, mais c'est hô combien plus propre a mes yeux ^^


RE: [Coding style] Vos solutions pour un code lisible ? - Allwise - 01-09-2009

Pour ma part, pas grand chose à ajouter, tout ce que je fais / m'efforce de faire a été dit. J'avoue que même si j'essaie de bien faire au départ, je finis souvent par mélanger du français et de l'anglais dans mon code. Quand l'anglais est plus court et plus parlant j'y recours, sûrement mon côté flemmard / bordélique ^^

Quant à l'utilisation des accolades, au début, tant en PHP qu'en javascript, je les omettais quand c'était possible, mais avec le temps je les ai mises partout, parce que je trouvais que c'était naturellement plus lisible. De même, au départ j'étais plus du genre
Code PHP :
<?php 
if (1)
{
// Code
}
que
Code PHP :
<?php 
if (1) {
//code
}
Mais avec le temps j'ai basculé vers la seconde présentation. Je suppose qu'ai pris l'habitude de me fier davantage à l'indentation qu'aux accolades.

Quant à l'utilisation des quote / double quote, ça dépend du contexte. Si j'ai un gros pavé de texte ce seront les double, si c'est une ptite phrase ce sera les simples. Au début j'étais plus partisan des simples pour des raisons d'optimisation mais encore une fois, le temps m'a fait changer d'avis Wink et m'a fait comprendre que c'était pas là qu'il fallait chercher. Certes PHP parse chaque mot à la recherche d'une variable quand on utilise les guillemets, mais je ne suis pas convaincu du gain que ça peut apporter dans une application et du ressenti des utilisateurs. D'ailleurs, t'as un cas concret qui met en évidence ce gain de temps d'exécution, à part des boucles énormes qui servent à rien ? :bisou:

Je n'utilise jamais de préfixe à mes noms de variables, sauf en Javascript ( et éventuellement dans d'autres langages ) quand je définis des champs de formulaire. Je les préfixe par le type de champ : lstPays, txtNom, chkSexe... Ça m'aide à m'y retrouver quand il y en a beaucoup Smile

Sinon Argo, le code le plus concis n'est pas forcément le plus lisible. En fait, c'est le contraire. Si on suit ton raisonnement, les indentations et les retours chariots sont inutiles Smile Ce qu'on fait pour rendre un code illisible, c'est en partie ça, supprimer les espaces / indentations, et raccourcir au maximum le nom des variables. Bon ok j'avoue je suis un chieur :glace:

EDIT
Ce qui est dommage avec ta façon de faire Nico, c'est que tant au niveau de l'utilisation d'IDE PHP genre Eclipse qui affichent la liste des arguments, tant au niveau de la doc ( phpDoc ), c'est pas parlant du tout. Pourquoi ne pas intégrer le sprintf dans une fonction plutôt ?

Code PHP :
<?php 
RequestDB
( //j'appelle ici a ma couche d'abstraction DB
sprintf($req_insert_perso
,htmlentities($_POST['nom'],ENT_QUOTES,'UTF-8')
,
htmlentities($_POST['password'],ENT_QUOTES,'UTF-8')
,
htmlentities($_POST['msg_ok'],ENT_QUOTES,'UTF-8')
,
htmlentities($_POST['msg_fail'],ENT_QUOTES,'UTF-8')
)
);

// ======>

function insertTruc($nom, $password, $msg_ok, $msg_fail) {
RequestDB( //j'appelle ici a ma couche d'abstraction DB
sprintf($req_insert_perso
,htmlentities($nom,ENT_QUOTES,'UTF-8')
,
htmlentities($password,ENT_QUOTES,'UTF-8')
,
htmlentities($msg_ok,ENT_QUOTES,'UTF-8')
,
htmlentities($msg_fail,ENT_QUOTES,'UTF-8')
)
);
}
PAreil mais en plus pratique ^^