Je pense que la maniére de coder vient surtout de la formation que tu as eu.
Ensuite viennent l'experience. Pas celle que tu as aquise en ecrivant tes programmes, mais celles que tu as aquise en relisant, reutilisant du code d'autres personnes.
Personnelement, je reprend regulierement du code fait par d'autres personnes. Je n'ai jamais remarqué que le code correspond à la personnalité de la personne, mais plutôt de ces connaissances du langage. On utilise les fonctions, procédures, algo que l'on connait. Il est vrai que chaque personnes a son propre style, ses habitudes, ses methodes, etc...
En fait, la methode de coder depend surtout de ce que va devenir le code. Comme je sais qu'on le relit deriere moi et qu'il va resservir, j'essaye de faire claire et simple.
Sinon, à force de relir du code d'autres personnes, on prend les bonnes idées. Et on laisse tomber les mauvaises. C'est en regardant les autres que l'on apprend.
A lire tout les autres commentaires, j'ai vraiment l'impression que chacun parle pour soi: MOI je code code cela, parce que MOI je prefere que ce soit comme cela.
De plus quand on fait de la qualité, il y a souvent des régles de codages. Il m'est arrivé de verifié que du code vérifie des régles de codages (genre lignes de moins de 70 caractéres, constante en majuscules, nom de procedure comprenant un verbe, nom de la fonction indiquant ce qu'elle produit, etc...). Super chiant, mais tres formateur quand à la meilleur méthode de coder.
Par experience, voici quand même quelque truc pour rendre un programme comprehensible.
-- Des noms qui veulent dire quelques choses. C'est pas toujours le cas.
-- Avoir la même convention de styles pour tout le programme, surtout quand plusieurs personnes travaille dessus.
-- Des procedures/ fonctions de moins de 40 instructions (instructions, pas lignes). Si c'est trop gros, tu decoupes.
-- Un entête pour chaque procedure/fonction comprenant le nom de la procedure, les nom et fonction des paramétres, commentaire en 1 ou 2 lignes (d'ailleurs, s'il faut plus pour expliquer ce que fait la fonction, c'est qu'elle est trop compliqué). En plus ça permet de faire un separation entre les procedure/fonction. C'est pas beaucoup, mais ca permet de mettre les idées au point avant de coder et c'est super quand on relit du code.
-- Le moins de variables globale possibe, c'est toujours chiants de chercher quelle fonctions l'initialise, laquel la modifie, etc...
-- Lorsque tu decrit une procedure fonction, un paramétre par ligne come cela on les voit tout de suite.
ex
procedure TOTO
(
...Paramétre_1 : in T_Type_1;
...Paramétre_2 : in T_Type_2;
)
-- Enfin afin que tout le monde y trouve son compte, 1 indentation = 1 tabulation, comme cela, celui qui veut une indetation de 2, il regle tab = 2, etc...
# Re: Critères de personnalité d'un code (formation et experience)
Posté par Tutur . En réponse à la dépêche Critères de personnalité d'un code. Évalué à 1.
Ensuite viennent l'experience. Pas celle que tu as aquise en ecrivant tes programmes, mais celles que tu as aquise en relisant, reutilisant du code d'autres personnes.
Personnelement, je reprend regulierement du code fait par d'autres personnes. Je n'ai jamais remarqué que le code correspond à la personnalité de la personne, mais plutôt de ces connaissances du langage. On utilise les fonctions, procédures, algo que l'on connait. Il est vrai que chaque personnes a son propre style, ses habitudes, ses methodes, etc...
En fait, la methode de coder depend surtout de ce que va devenir le code. Comme je sais qu'on le relit deriere moi et qu'il va resservir, j'essaye de faire claire et simple.
Sinon, à force de relir du code d'autres personnes, on prend les bonnes idées. Et on laisse tomber les mauvaises. C'est en regardant les autres que l'on apprend.
A lire tout les autres commentaires, j'ai vraiment l'impression que chacun parle pour soi:
MOI je code code cela, parce que MOI je prefere que ce soit comme cela.
De plus quand on fait de la qualité, il y a souvent des régles de codages. Il m'est arrivé de verifié que du code vérifie des régles de codages (genre lignes de moins de 70 caractéres, constante en majuscules, nom de procedure comprenant un verbe, nom de la fonction indiquant ce qu'elle produit, etc...). Super chiant, mais tres formateur quand à la meilleur méthode de coder.
Par experience, voici quand même quelque truc pour rendre un programme comprehensible.
-- Des noms qui veulent dire quelques choses. C'est pas toujours le cas.
-- Avoir la même convention de styles pour tout le programme, surtout quand plusieurs personnes travaille dessus.
-- Des procedures/ fonctions de moins de 40 instructions (instructions, pas lignes). Si c'est trop gros, tu decoupes.
-- Un entête pour chaque procedure/fonction comprenant le nom de la procedure, les nom et fonction des paramétres, commentaire en 1 ou 2 lignes (d'ailleurs, s'il faut plus pour expliquer ce que fait la fonction, c'est qu'elle est trop compliqué). En plus ça permet de faire un separation entre les procedure/fonction. C'est pas beaucoup, mais ca permet de mettre les idées au point avant de coder et c'est super quand on relit du code.
-- Le moins de variables globale possibe, c'est toujours chiants de chercher quelle fonctions l'initialise, laquel la modifie, etc...
-- Lorsque tu decrit une procedure fonction, un paramétre par ligne come cela on les voit tout de suite.
ex
procedure TOTO
(
...Paramétre_1 : in T_Type_1;
...Paramétre_2 : in T_Type_2;
)
-- Enfin afin que tout le monde y trouve son compte, 1 indentation = 1 tabulation, comme cela, celui qui veut une indetation de 2, il regle tab = 2, etc...