Le lundi 05 décembre 2005 à 09:59 +0100, Rodolphe Quiedeville a écrit : > Gael Canal wrote:
> ok pour une charte de nommage mais personnellement je trouve que > beaucoup de charte de nommage sont un vrai cauchemar pour les codeurs, > il faut bien voir que nous avons sous les yeux à longueur de journées > des noms de champs et de tables alors pitié pas de charte inesthétique ;-) J'en conviens volontiers, et je reconnais qu'il est pénible de se plier à des contraintes lorsque l'on code. > > suffixer le nom de la table de _id (pour la clé primaire), > > Typiquement je ne suis pas pour, rowid me parait très bien comme clé > primaire parce que je me vois mal taper tous les le jour le nom de la > clé primaire de la table llx_telephonie_distributeur_commerciaux Juste histoire de donner une seconde chance à ma proposition, je propose quelques contre arguments : 1. il y a toujours le copier-coller 2. il y a toujours la possibilité (et c'est même une bonne idée) de réutiliser le code 3. pour les cas extrême, dans le dispositif que je propose, on peut toujours faire : $table="telephonie_distributeur_commerciaux"; $sql="select cod_$table, lib_$table from $table where id_$table=12"; etc... 4. l'utilisation systématique de rowid est-elle plus une aide pour les développeurs qu'une clé primaire aisément identifiable et ratachée à une table ? Est-ce que le code n'est pas plus lisible dans le cas xxx_id ? Dans le cas de requetes complexes incluant plusieurs tables, est-ce que plusieurs rowid n'est pas susceptible de générer des bugs / confusions etc.. Je comprend que cette proposition soit lourde de conséquences, non pas pour une question d'habitude de codeurs qui en ont vu d'autres, ni pour la longueur des noms de champs, après tout, mysql_real_escape_string est assez long a taper aussi, mais surtout pour ce qu'elle impliquerait en adaptation du code existant; je n'espère donc pas qu'elles soit adoptée sous les vivas :-) Les problèmes de réalisation du MPD ne sont pas vraiment le problème, mais, je souhaitais attirer votre attention sur cette question, car dolibarr atteint une masse critique de plus d'une centaine de tables, et que la maintenabilité du code au dela d'un certain point risque d'être compromise faute de standards de codage. Un MPD peut aider à cela; un code bien documenté aussi; des règles de codage aussi etc... c'est juste un tout. ...au moins j'aurais essayé :-) ++ Gael _______________________________________________ Dolibarr-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
