+- 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)
RE: [Coding style] Vos solutions pour un code lisible ? - QuentinC - 05-09-2009
Bonsoir à tous.
Note préliminaire : Je n'ai pas lu la fin de la page 2 ni la page 3, donc excusez-moi s'il y a de la redite.
Tout d'abord ma particularité à moi, c'est que je n'indente pas le code du tout. Je le fais indenter par un outil automatique au cas où je dois le passer à quelqu'un d'autre, et je ne tiens absolument pas compte de l'indentation s'il y en a dans un code qui vient de quelqu'un d'autre.
Je ne vais pas expliquer pourquoi l'indentation m'importune au plus au point et pourquoi je ne peux que difficilement en tenir compte (et accessoirement pourquoi je ne me mettrai jamais à python), mais ceux qui connaissent ma situation un peu spéciale comprendront probablement. Au pire, je leur explique volontiers par MP, mais pas ici ça vaut mieux.
Pour palier à la non-indentation, il n'est pas rare de trouver dans mes codes un mini-commentaire du genre
}//end foreach availableOptions
Ca arrive surtout quand les blocs sont longs... ce n'est pas si fréquent que ça.
Sinon à part ça, j'utilise le camelCase, pas d'accolades quand il n'y a qu'une instruction, et sinon une accolade sur la même ligne que la structure de contrôle.
Je suis un fan de la notation heredoc que j'utilise tout le temps dès que je fais une sortie sur plusieurs lignes. Je ne suis pas spécialement fan des moteurs de templates, j'ai l'impression que ça complique plus que ça ne simplifie. Je me contente donc de séparer la partie logique de la partie affichage dans des fichiers différents (en général je regroupe les vues dans un dossier, les modèles dans un autre et les contrôleurs à la racine). Donc, la syntaxe heredoc est extrêmement pratique dans les vues puisqu'il évite de devoir sans cesse se soucier de l'échappement des guillemets.
La notation avec apostrophes et concaténation n'est pas spécialement sympa à lire. Au pire, on peut utiliser sprintf pour afficher quelques variables.
Celui qui me dit que la notation heredoc est plus lent que le reste, je l'étripe. C'est vrai, mais c'est tellement infime que... osef.
Un truc super pratique que je me désole de ne pas voir plus souvent est d'écrire la définition d'une fonction avec un espace entre le nom et la parenthèse, et pas d'espace lors des appels (Note : on peut aussi choisir la convention inverse). C'est hyper pratique quand on fait une recherche avec Ctrl+F et qu'on peut atteindre directement ce qu'on veut, soit la définition de la fonction, soit où elle est appelée.
++ Je complèterai ce post après manger.
RE: [Coding style] Vos solutions pour un code lisible ? - naholyr - 05-09-2009
(05-09-2009, 06:26 PM)QuentinC a écrit : écrire la définition d'une fonction avec un espace entre le nom et la parenthèse, et pas d'espace lors des appelsC'est personnellement la convention que je suis.
Citation :C'est hyper pratique quand on fait une recherche avec Ctrl+F et qu'on peut atteindre directement ce qu'on veut, soit la définition de la fonction, soit où elle est appelée.Oui enfin en même temps plutôt que de chercher "fonction (" pour trouver la déclaration, tu peux aussi chercher... "n fonction"
RE: [Coding style] Vos solutions pour un code lisible ? - QuentinC - 05-09-2009
Citation :Oui enfin en même temps plutôt que de chercher "fonction (" pour trouver la déclaration, tu peux aussi chercher... "n fonction"Ca peut marcher en php et en javascript, mais ça ne marchera pas dans les langages où on ne définit pas une fonction avec le mot-clé function. C'est une convention que j'ai prise en java et que j'ai gardée pour le php.
Sinon, définition des tableaux sur une ligne ou sur plusieurs, ça dépend du contenu. Pour les tableaux associatifs, c'est une clé par ligne, sauf si c'est un tableau qui est créé juste pour un appel de fonction p.ex. mafonction(array(truc=>1, bidule=>2)).
Mon plus gros problème c'est que je ne commente presque pas mon code, pour ne pas dire carrément pas du tout. Donc forcément quand je dois le passer à quelqu'un d'autre, c'est pas forcément simple.
RE: [Coding style] Vos solutions pour un code lisible ? - Zamentur - 05-09-2009
Oui ou utiliser un IDE comme Eclipse qui te fait las liste complète des méthodes et fonction et ou il suffit de cliquer pour atteindre ce que l'on souhaite...
Ceci étant dit j'avais jamais pensé à ce détail concernant le besoin de retrouver une fonction.
Un trucs de style dont je m'étonne qu'on en entend pas parler c'est la longueur des lignes. Sur Linux il est demandé de faire des lignes d'une taille maximum de 80 caractères, notamment parce que çà permet d'afficher correctement pour ceux qui ont des petit écran et donc de ne pas scroller horizontalement.
C'est aussi un avantage pour les grand écran car on peux alors utiliser des éditeur comme kate qui propose une vue simultané de 2 fichiers.
Je dis çà car je vois certains code qui dépasse largement les 100 caractères.
Personnelement je trouve toujours un code plus agréable quand les lignes ne sont pas trop longue. Pourtant j'ai un double écran 22 pouces/19 pouces!
Autre remarque de style, la façon dont vous formatez vos requêtes SQL, personnellement j'ai pas encore trouvé de solution idéal .
Dans le même genre que faites vous lorsque une condition est trop longue?
RE: [Coding style] Vos solutions pour un code lisible ? - Sephi-Chan - 05-09-2009
(05-09-2009, 10:07 PM)Zamentur a écrit : Oui ou utiliser un IDE comme Eclipse qui te fait las liste complète des méthodes et fonction et ou il suffit de cliquer pour atteindre ce que l'on souhaite...
Ceci étant dit j'avais jamais pensé à ce détail concernant le besoin de retrouver une fonction.
Un trucs de style dont je m'étonne qu'on en entend pas parler c'est la longueur des lignes. Sur Linux il est demandé de faire des lignes d'une taille maximum de 80 caractères, notamment parce que çà permet d'afficher correctement pour ceux qui ont des petit écran et donc de ne pas scroller horizontalement.
C'est aussi un avantage pour les grand écran car on peux alors utiliser des éditeur comme kate qui propose une vue simultané de 2 fichiers.
Je dis çà car je vois certains code qui dépasse largement les 100 caractères.
Personnelement je trouve toujours un code plus agréable quand les lignes ne sont pas trop longue. Pourtant j'ai un double écran 22 pouces/19 pouces!
Autre remarque de style, la façon dont vous formatez vos requêtes SQL, personnellement j'ai pas encore trouvé de solution idéal .
Dans le même genre que faites vous lorsque une condition est trop longue?
Pour la recherche, je recherche sur le mot def ma_fonction quand je souhaite avoir la définition. Mais bon, ça n'a jamais été un problème (malgré la grande quantité de méthodes définies dans les applications Ruby on Rails).
Au sujet des lignes, j'essaye de ne pas excéder 80. Je m'autorise toutefois jusqu'à 100 caractères si vraiment je ne peux pas découper (mais c'est rare).
Pour SQL, c'est simple, je n'en écris plus (ActiveRecord est vraiment un ORM puissant). Mais quand je suis amené à le faire (pour des amis !
iffle: ), je mets une clause par ligne avec un alignement des éléments. Ça ressemble globalement à ça :
SELECT T.column_a,
OT.column_b AS other_column_b,
OT.column_c,
OT.other_column_c
FROM first_table AS FT
LEFT JOIN other_table AS OT
ON OT.column_b = FT.column_a
WHERE column_a = 'value'
AND OT.other_column_c >= DATE_ADD(NOW(), INTERVAL 1 DAY)
Pour les conditions trop longues, je saute à la ligne :
Un petit défaut à mon goût dans Ruby, c'est que si je souhaite écrire le && en début de ligne, il faut mettre un antislash à la fin de la ligne précédente pour lui dire "je saute une ligne mais pas toi".
if my_method_with_a_long_name(param, other_param) \
&& my_other_method_with_a_long_name(yet_another_param)
@projects = Project.paginate :page => params[:page],
:include => [ :users, :tasks ]
end
Du coup comme je trouve ça moins joli, ben je mets mon && à la fin de la ligne précédente.
if my_method_with_a_long_name(param, other_param) &&
my_other_method_with_a_long_name(yet_another_param)
@projects = Project.paginate :page => params[:page],
:include => [ :users, :tasks ]
end
Sephi-Chan
RE: [Coding style] Vos solutions pour un code lisible ? - QuentinC - 06-09-2009
Citation :Oui ou utiliser un IDE comme Eclipse qui te fait las liste complète des méthodes et fonction et ou il suffit de cliquer pour atteindre ce que l'on souhaite...Deux choses à propos des IDE me concernant :
Ceci étant dit j'avais jamais pensé à ce détail concernant le besoin de retrouver une fonction.
1 - La plupart des IDE ne sont pas du tout ou pas suffisament accessibles pour pouvoir en profiter agréablement. Même ce qui vous paraît très simple n'est pas forcément accessible... par exemple, Notepad++ ne l'est pas, tout ce qui est basé sur QT ou GTK ne le sont pas suffisament non plus.
2 - J'ai un assez vieux PC et la plupart des IDE sont hyper lents. Eclipse serait pas mal, mais il est lent, très lent... et c'est lourd.
Du coup je garde mon bon vieux c:\windows\system32\notepad.exe jusqu'à ce que je trouve un truc tout aussi léger qui ajouterait des fonctions utiles et qui soit accessible. Déjà testé : notepad2.
Citation :Autre remarque de style, la façon dont vous formatez vos requêtes SQL, personnellement j'ai pas encore trouvé de solution idéal .Perso en général quand c'est pas trop long c'est tout sur une seule ligne. Au cas où c'est sur plusieurs lignes, ça ressemble en général à ça chez moi :
Code :
select a.champ1, a.champ2, a.champ3, a.champ4
b.champ1, b.champ2, b.champ3,
c.champ1, c.champ2, c.champ3, c.champ4
from table1 a
left join table2 b on a.champ1 = b.champ1
left join table3 c on a.champ2 = c.champ2
where a.champ1 = 12345 and b.champ3 = 'hello world'
and c.champ5 in (1, 4, 7, 18, 66)
order by a.champ4 asc limit 10Code :
if ($db->count('select id from users where name = %s', $pseudo)>=1) $error = 'Ce pseudo est déjà pris.';Citation :Dans le même genre que faites vous lorsque une condition est trop longue?
Code :
if (
($bidule >= 12345 && $bidule <= 54321)
&& ($truc==$machin || $truc==$bidule)
&& $machin!=$chose) {
...RE: [Coding style] Vos solutions pour un code lisible ? - Siko - 16-09-2009
Citation :Ben perso j'utilise les systeme de template notamment celui du wiki.
Donc j'utilise les short tag quand ils sont activés sinon je génère les echo à a place.
Résultat il n'y a pas de echo.
Ton moteur de template va parser ton fichier template et va tout remplacer par des echo.. au final même si toi tu ne l'écrit pas php va bien exécuter des echo ..
RE: [Coding style] Vos solutions pour un code lisible ? - Zamentur - 16-09-2009
Non je parle des short tag de php.
Le moteur de template ne parse pas les fichiers son code se trouve dans le wiki de jeuweb comme je l'ai dit. Il est très simple mais très pratique
http://wiki.jeuweb.org/tutoprog/template_en_php
Et çà c'est vraiment de la lisibilité contrairement au echo suivie de chaine de caractère qu'on a pu voir... Ca ne devrait jamais arrivé en dehors d'une procédure de debug (le fameux echo 'ok'; archaïque mais fonctionnel)
RE: [Coding style] Vos solutions pour un code lisible ? - Anthor - 16-09-2009
Hélas Siko a raison, les short tags doivent être désactivé, et le sont par défaut depuis quelques années.
C'est pourquoi le moteur de Zend, permet de remplacer les shorttags dans le template, ce qui induit une perte de performance.
Dans tous les cas, shorttag activé, php remplace bien par un echo. Donc ça reviens au même.
RE: [Coding style] Vos solutions pour un code lisible ? - Allwise - 16-09-2009
De plus, niveau portabilité du code, les short tags c'est pas génial et ça peut donner des mauvaises surprises.