Commentaires sur code source... le retour

Bonjour/Bonsoir, (entouré la réponse qui vous convient)

J'ai fini mon petit exercice, si quelqu'un voudrais y jeter un oeil
pour me dire ce qu'il en pense.

Bon, j'suis pas un pro (notamment j'ai surtout jamais fait de C en industrie
mais quelques trucs...)
Il n'y a aucun vrai commentaire sur la programmation en elle même, j'ai
juste survolé les fichiers...
[Au passage, pour éviter d'encombrer pour rien ton serveur free, rajoute un
clean dans ton make qui efface les .o, *~ et tout fichier qui ne sert à
rien... ]

C'est 100% C (sinon je posterais pas ici).

Suivant les recommandations données sur ce NG, j'ai mis mon exercice
sur un serveur web.

http://thetemplar.free.fr/source.tar.gz

Je compte déjà revoir la méthode pour me balader dans les arrays pour
la rendre plus lisible, selon les conseils de DINH Viêt Hoà (J'ai pas
fait de fautes j'espère ?).

En effet il est préférable de n'utiliser l'arithmétique sur les pointeurs
que dans des cas très très rares et dans lesquels c'est justifié.

Si vous avez d'autres conseils, commentaires, tortures à me faire,
allez-y (...je crains rien...) :-)

En fait, pour le code en lui même je n'ai pas tout regardé encore. Seulement
je me demande si il n'y a pas un peu *trop* de commentaires dans ton code.
OK on m'a toujours dit faut en mettre, mais faut aussi se modérer. Entre
autre, je vois que tu mets un gros pavé en haut de la fonction (ce qui est
recommandé par mes profs) mais en plus tu mets des commentaires dans les
fonctions. Genre :

/* gros pavé de commentaire*/
int
check_param( char ***const param_p, int *const argc_p )
{
/* Program status */
int err = EXIT_FAILURE;

/* Position in the array valid_params_s[] */
unsigned int pos = 0;

/* Debug : Check the pointers */
assert ( param_p != NULL && argc_p != NULL );

Là ca me parait un peu excessif...
En clair, il me semblait que c'était _soit_ le gros pavé _soit_ les
commentaires dans la fonction. Sauf dans les cas particuliers où tu fais un
truc bizarre ou pas clair dans la fonction tu le commentes...

De plus, c'est un logiciel qui crie quand tu ignores les valeurs de retours
des fonctions ou alors tu as appris à écrire :
(void) printf("Voided %sn", string);

Je t'ai souvent vu sur ce forum écrire ce genre de choses, et personne ne
t'a jamais repris. Je sais que c'est standard, mais si des gens qui font du
C en industrie par exemple peuvent me le dire, c'est seulement pour
améliorer les chances de problèmes du canal carpien ou alors ce genre de
programmation est vraiment demandée pour être plus "claire" ou je ne sais
quoi d'autre...

Anthony
--
"On est bien sûr de soi quand on est grand, avec notre savoir, notre
moral, tous ces principes auxquels on tient tant.
Mais c'est souvent trop tard que l'on comprend, que le bonheur
était simple comme un jeu d'enfant." -- Sinsemilia

Anthony Fleury wrote:

Bonjour/Bonsoir, (entouré la réponse qui vous convient)

J'ai fini mon petit exercice, si quelqu'un voudrais y jeter un oeil
pour me dire ce qu'il en pense.

(snip commentaire sur les commentaires)

De plus, c'est un logiciel qui crie quand tu ignores les valeurs de retours
des fonctions ou alors tu as appris à écrire :
(void) printf("Voided %sn", string);

Je t'ai souvent vu sur ce forum écrire ce genre de choses, et personne ne
t'a jamais repris. Je sais que c'est standard, mais si des gens qui font du
C en industrie par exemple peuvent me le dire, c'est seulement pour
améliorer les chances de problèmes du canal carpien ou alors ce genre de
programmation est vraiment demandée pour être plus "claire" ou je ne sais
quoi d'autre...

Je ne suis pas sûr d'avoir bien décrypté, mais si ta question est :
"pourquoi caster le retour de printf() vers void ?", la réponse est que
cela indique à un certain nombre d'outils de vérification de code - dont
éventuellement aussi un autre programmeur - qu'on ignore
*volontairement* la valeur de retour.

Bruno

Anthony Fleury wrote:
[snip void sur retour de printf]

Je t'ai souvent vu sur ce forum écrire ce genre de choses, et
personne ne t'a jamais repris. Je sais que c'est standard, mais si
des gens qui font du C en industrie par exemple peuvent me le dire,
c'est seulement pour améliorer les chances de problèmes du canal
carpien ou alors ce genre de programmation est vraiment demandée
pour être plus "claire" ou je ne sais quoi d'autre...

Je ne suis pas sûr d'avoir bien décrypté, mais si ta question est :
"pourquoi caster le retour de printf() vers void ?", la réponse est
que cela indique à un certain nombre d'outils de vérification de code
- dont éventuellement aussi un autre programmeur - qu'on ignore
*volontairement* la valeur de retour.

En fait, je savais la signification de ce cast. Ma question était en clair :
Est ce que c'est vraiment fait dans la vie de tous les jours par quelqu'un
qui est payé pour écrire du code? Mis à part pour contenter ces outils
(d'ailleurs y'a peut-être une option pour virer ces warnings?)
Parce que dans le cas du printf() par exemple, il est très rare (enfin plus
précisément il ne m'est jamais arrivé) d'avoir à vérifier son retour. La
personne qui relit un tel code ne sera donc pas étonné de ne pas voir de
vérification de ce retour...
Ca doit être mon experience qui fait ca, mais je ne vois pas d'utilité à ce
cast mis à part accentuer les problèmes que l'on peut avoir à trop utiliser
un clavier.

[HS]
Et ces questions en amènent une autre : est ce que de tels outils sont
utilisés pour vérifier un code quand tu programmes en entreprise?
[HS]

Anthony -- qui n'est jamais allé dans ces endroits bizarres où des gens sont
payés pour faire du C (et pourquoi on me paye pas moi??)
--
"On est bien sûr de soi quand on est grand, avec notre savoir, notre
moral, tous ces principes auxquels on tient tant.
Mais c'est souvent trop tard que l'on comprend, que le bonheur
était simple comme un jeu d'enfant." -- Sinsemilia

On Tue, 28 Oct 2003 09:31:52 +0100
"Anthony Fleury" <fleury_anthony@a_enlever.hotmail.com> wrote:

Bon, j'suis pas un pro (notamment j'ai surtout jamais fait de C en
industrie mais quelques trucs...)

Je ne travaille pas non plus en industrie ;)

Il n'y a aucun vrai commentaire sur la programmation en elle même,
j'ai juste survolé les fichiers...
[Au passage, pour éviter d'encombrer pour rien ton serveur free,
rajoute un clean dans ton make qui efface les .o, *~ et tout fichier
qui ne sert à rien... ]

Oops vi effectivement, merci de me le faire remarquer ;)

En effet il est préférable de n'utiliser l'arithmétique sur les
pointeurs que dans des cas très très rares et dans lesquels c'est
justifié.

Ben disons que ça permettait de garder la position dans l'array une fois
qu'on quitté la fonction.
Je pense que je vais passer en paramètre la position (i), ça sera un peu
plus clair comme ça ;)

Si vous avez d'autres conseils, commentaires, tortures à me faire,
allez-y (...je crains rien...) :-)

En fait, pour le code en lui même je n'ai pas tout regardé encore.
Seulement je me demande si il n'y a pas un peu *trop* de commentaires
dans ton code.

Mon leitmotiv c'est : "C'est plus facile de supprimer que d'ajouter.
Moi je lis mon programme qu'avec les commentaires, maintenant c'est
vraiment quelque chose de pointilleux.
Je ferais un script pour supprimer chaque type de commentaires (étant
donné que chaque type de commentaire à style différent

/* Description */
fonction();

/**********...

ANNONCEMENT D'UNE FONCTION

...************/

/*------------

MACRO

------------*/

/(29*)Structure(29*)

STRUCTURE

(29*)Structure(29*)/

/*-8<---....

FICHIER

....--->8-*/

OK on m'a toujours dit faut en mettre, mais faut aussi se modérer.
Entre autre, je vois que tu mets un gros pavé en haut de la fonction
(ce qui est recommandé par mes profs) mais en plus tu mets des
commentaires dans les fonctions. Genre :

/* gros pavé de commentaire*/
int
check_param( char ***const param_p, int *const argc_p )
{
/* Program status */
int err = EXIT_FAILURE;

/* Position in the array valid_params_s[] */
unsigned int pos = 0;

/* Debug : Check the pointers */
assert ( param_p != NULL && argc_p != NULL );

Là ca me parait un peu excessif...

Je peux faire un script :)

En clair, il me semblait que c'était _soit_ le gros pavé _soit_ les
commentaires dans la fonction. Sauf dans les cas particuliers où tu
fais un truc bizarre ou pas clair dans la fonction tu le commentes...

De plus, c'est un logiciel qui crie quand tu ignores les valeurs de
retours des fonctions ou alors tu as appris à écrire :
(void) printf("Voided %sn", string);

Je t'ai souvent vu sur ce forum écrire ce genre de choses, et personne
ne t'a jamais repris. Je sais que c'est standard, mais si des gens qui
font du C en industrie par exemple peuvent me le dire, c'est seulement
pour améliorer les chances de problèmes du canal carpien ou alors ce
genre de programmation est vraiment demandée pour être plus "claire"
ou je ne sais quoi d'autre...

Ben c'est la façon qu'emploie la FAQ et j'utilise souvent splint qui
m'annonce qu'on peut toujours (void) le retour d'une fonction en cas de
problème.

--
--
ThE_TemPLaR

Eddahbi Karim wrote:

Bonjour/Bonsoir, (entouré la réponse qui vous convient)

J'ai fini mon petit exercice, si quelqu'un voudrais y jeter un oeil pour
me dire ce qu'il en pense.

C'est 100% C (sinon je posterais pas ici).

Suivant les recommandations données sur ce NG, j'ai mis mon exercice sur
un serveur web.

http://thetemplar.free.fr/source.tar.gz

Je compte déjà revoir la méthode pour me balader dans les arrays pour la
rendre plus lisible, selon les conseils de DINH Viêt Hoà (J'ai pas fait
de fautes j'espère ?).

Si vous avez d'autres conseils, commentaires, tortures à me faire,
allez-y (...je crains rien...) :-)

Voilà,

Rapport a tes commentaires (et vu que ca a ete mentionne dans les deux

sous-threads existants): il y a ceux qui soutienne que "bigger is
better", et que le code est d'autant plus clair qu'il est commente. Il y
a aussi ceux, desquels je me sens de plus en plus proche, qui disent que
au diable l'avarice, on est des codeurs, on est bien foutus de lire du
code, et que si tu ne mets pas de commentaires dans ton code, tu ne
risques pas de fourvoyer tes relecteurs avec un commentaire qui n'est
plus en phase avec le code.

Bref, si je me faisais l'avocat du diable >:-) je te conseillerais de
laisser tomber les commentaires et de te concentrer sur l'ecriture de
code clair et lisible...

--
Bertrand Mollinier Toublet
"In regard to Ducatis vs. women, it has been said: 'One is a sexy thing
that you've just got to ride, even if it breaks down a lot, costs a lot
of money, and will probably try to kill you'. However, nowadays I can't
seem to remember which one is which." -- Peer Landa

On Tue, 28 Oct 2003 14:57:45 -0800
Bertrand Mollinier Toublet
<bertrand.mollinierNOSPAMtoublet@enst-bretagne.fr> wrote:

Rapport a tes commentaires (et vu que ca a ete mentionne dans les deux

sous-threads existants): il y a ceux qui soutienne que "bigger is
better", et que le code est d'autant plus clair qu'il est commente. Il
y a aussi ceux, desquels je me sens de plus en plus proche, qui disent
que au diable l'avarice, on est des codeurs, on est bien foutus de
lire du code, et que si tu ne mets pas de commentaires dans ton code,
tu ne risques pas de fourvoyer tes relecteurs avec un commentaire qui
n'est plus en phase avec le code.

Bref, si je me faisais l'avocat du diable >:-) je te conseillerais de
laisser tomber les commentaires et de te concentrer sur l'ecriture de
code clair et lisible...

Moi je soutiens le "delete in one key, add it in one day". C'est assez
dur de se positionner :).
Peut être, faut il à ce moment se fier à soi même et garder son style
perso ;)
--
--
ThE_TemPLaR