Bonne ou mauvaise programmation

[Myki]

La preuve ....

 

 

777

[patzepat]

Oui, je sais!

Mais je me tues à vous le répétez: ne vous cantonnez pas à cette utilisation!

Ben si, justement, cantonnez vous à ça. Pour le reste ça doit être dans les specs, pas dans les commentaires de code...

[Maeke]

Oui, je sais!

Mais je me tues à vous le répétez: ne vous cantonnez pas à cette utilisation!

Ben si, justement, cantonnez vous à ça. Pour le reste ça doit être dans les specs, pas dans les commentaires de code...

Donc pour toi, on doit se cantonner aux spéc et ne jamais tenter de faire mieux?

[Myki]

Je m'en doute, mais le temps de zapping est multiplié par le nombre de commentaires à "zapper"

Oui et non.

 

Car avant de "compiler" le prog, il y'a toujours une phase de "défrichage" qui se fait par un parser (enlève les commentaires, rajoute les fonctions inline, etc).

 

Donc le temps de d'enlever une ligne de commentaires ou milles lignes est de l'ordre du ridicule ... mais sans avoir un rapport de 1/1000

 

777

[Maeke]

Je m'en doute, mais le temps de zapping est multiplié par le nombre de commentaires à "zapper"

Oui et non.

 

Car avant de "compiler" le prog, il y'a toujours une phase de "défrichage" qui se fait par un parser (enlève les commentaires, rajoute les fonctions inline, etc).

 

Donc le temps de d'enlever une ligne de commentaires ou milles lignes est de l'ordre du ridicule ... mais sans avoir un rapport de 1/1000

 

777

D'accord, mais là, c'était dans le cas d'un langage interprété.

[tangui]

 

Donc le temps de d'enlever une ligne de commentaires ou milles lignes est de l'ordre du ridicule ... mais sans avoir un rapport de 1/1000

 

777

je d'enleve

tu d'enleves

il elle on d'enleve

nous d'enlevons

vous d'enlevez

ils elles d'enlevent

[patzepat]

Ben si, justement, cantonnez vous à ça. Pour le reste ça doit être dans les specs, pas dans les commentaires de code...

Donc pour toi, on doit se cantonner aux spéc et ne jamais tenter de faire mieux?

A te lire, je pense que tu n'as jamais bossé sur un projet informatique, alors en deux mots sache que la base c'est de décrire ce que l'on va faire et de mettre en oeuvre ce qu'on a décrit.

 

La programmation à la volée sans spec c'est bon pour les particuliers qui font leur page web. Quand tu bosses à plusieurs, pour des gens et que tu dois fournir un produit de qualité, tu spécifies ce que tu vas faire. Ce que tu fais évoluer après c'est de la correction parce que tu constates que ce n'est pas conforme aux specs, notamment aux chapitres sur la qualité de service ou les contraintes de sollicitation et autres.

[Maeke]

Erf, j'crois qu'il va falloir faire un résumé, j'ai l'impression qu'on a dépassé légèrement la question (je sais, j'y suis pour quelque chose).

[Maeke]

Ben si, justement, cantonnez vous à ça. Pour le reste ça doit être dans les specs, pas dans les commentaires de code...

Donc pour toi, on doit se cantonner aux spéc et ne jamais tenter de faire mieux?

A te lire, je pense que tu n'as jamais bossé sur un projet informatique, alors en deux mots sache que la base c'est de décrire ce que l'on va faire et de mettre en oeuvre ce qu'on a décrit.

 

La programmation à la volée sans spec c'est bon pour les particuliers qui font leur page web. Quand tu bosses à plusieurs, pour des gens et que tu dois fournir un produit de qualité, tu spécifies ce que tu vas faire. Ce que tu fais évoluer après c'est de la correction parce que tu constates que ce n'est pas conforme aux specs, notamment aux chapitres sur la qualité de service ou les contraintes de sollicitation et autres.

En tant qu'électronicien ayant pratiqué un poil les automatismes avec micro-controlleur, je peux te garantir qu'il m'est arrivé de corriger les spécs, ayant trouvé une solution plus efficace que celles demandées.

Bien sûr, çà n'arrive pas tout les jours mais certains signes démontrent que c'est déjà arrivé à m$ de modifier les spécs.

Modifié le 23 avril 2003 par Maeke

[tangui]

m$ ce n'est vraiment pas un bon exemple à citer...