Bonsoir
Voilà, j'ai une petite question pas trop méchante, mais qui a éveillé ma
curiosité.
Pour faire simple, je commence par ma fonction:
int left(int x, int y)
{
while(laby[x-1][y] == '.' && x-1 >= 0 ) x--;
return x;
}
qui est censé me donner l'abscisse du point le plus à gauche sur cette ligne
(en s'arrêtant aux "obstables" != '.').
Supposons qu'on arrive à la colonne 0, on a l'évaluation suivante:
(laby[-1][y] == '.' && -1 >=0) qui est fausse, bien sûr.
que va me donner le prog à l'exécution de la fonction dans ce cas?
Y a-t-il un moyen de faire évaluer le x >= 0 en premier pour éventuellement
éviter le laby[x][y]?
J'imagine que quoo qu'il en soit les 2 booléennes sont évaluées, mais ce
n'est que conjecture.
Merci
Miguel
Le Thu, 29 Apr 2004 14:17:10 +0200, Alexandre BACQUART a écrit :
-- Tek "'Free software' is a matter of liberty, not price.", Richard STALLMAN.
Ce n'est pas un programme, mais c'est un bon début et le message a de plus le mérite d'être relativement neutre. Et puis tout bien réfléchi non :
-- Tek
qui n'est pas copyleft, encore moins C89 ou que sais-je encore, et surtout complètement vide de sens, mais qui à ce titre aura au moins le mérite de ne lancer aucun débat métaphysique HS. J'irai même jusqu'à dire qu'elle tape le poing sur la table en remettant en question la véritable identité d'une signature (par pseudonyme j'entends).
Content ? :)
Ah non maintenant ta signature dépasse les 6 lignes préconisées par la netiquette ;)
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
Le Thu, 29 Apr 2004 14:17:10 +0200, Alexandre BACQUART a écrit :
--
Tek
"'Free software' is a matter of liberty, not price.", Richard STALLMAN.
Ce n'est pas un programme, mais c'est un bon début et le message a de
plus le mérite d'être relativement neutre. Et puis tout bien réfléchi non :
--
Tek
qui n'est pas copyleft, encore moins C89 ou que sais-je encore, et
surtout complètement vide de sens, mais qui à ce titre aura au moins le
mérite de ne lancer aucun débat métaphysique HS. J'irai même jusqu'à
dire qu'elle tape le poing sur la table en remettant en question la
véritable identité d'une signature (par pseudonyme j'entends).
Content ? :)
Ah non maintenant ta signature dépasse les 6 lignes préconisées par la
netiquette ;)
--
Florent "flure" C.
Décrypter l'@ pour répondre
Coders don't die, they just JMP without RET !
Le Thu, 29 Apr 2004 14:17:10 +0200, Alexandre BACQUART a écrit :
-- Tek "'Free software' is a matter of liberty, not price.", Richard STALLMAN.
Ce n'est pas un programme, mais c'est un bon début et le message a de plus le mérite d'être relativement neutre. Et puis tout bien réfléchi non :
-- Tek
qui n'est pas copyleft, encore moins C89 ou que sais-je encore, et surtout complètement vide de sens, mais qui à ce titre aura au moins le mérite de ne lancer aucun débat métaphysique HS. J'irai même jusqu'à dire qu'elle tape le poing sur la table en remettant en question la véritable identité d'une signature (par pseudonyme j'entends).
Content ? :)
Ah non maintenant ta signature dépasse les 6 lignes préconisées par la netiquette ;)
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
Erwann ABALEA
On Thu, 29 Apr 2004, Alexandre BACQUART wrote:
[...]
pour satisfaire les tatillons). A la base, c'est plus un délire qu'autre chose, ce n'est PAS le corps du message, comme semble d'ailleurs l'indiquer le "--" séparateur classique des NG, ce n'est pas non plus un
Le séparateur est "-- n", ne pas oublier l'espace... ;)
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- ah koi ca sert de donner son nom si ce n'est pour avoir des emmerdes ? vous avez pas vu encore ke des barges il y en a partout et que devoiler toute ces informations c'est dangereux ? -+- Mickey in GNU : Le retour du fils de l'homme invisible -+-
On Thu, 29 Apr 2004, Alexandre BACQUART wrote:
[...]
pour satisfaire les tatillons). A la base, c'est plus un délire qu'autre
chose, ce n'est PAS le corps du message, comme semble d'ailleurs
l'indiquer le "--" séparateur classique des NG, ce n'est pas non plus un
Le séparateur est "-- n", ne pas oublier l'espace... ;)
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
ah koi ca sert de donner son nom si ce n'est pour avoir des emmerdes ?
vous avez pas vu encore ke des barges il y en a partout et que devoiler
toute ces informations c'est dangereux ?
-+- Mickey in GNU : Le retour du fils de l'homme invisible -+-
pour satisfaire les tatillons). A la base, c'est plus un délire qu'autre chose, ce n'est PAS le corps du message, comme semble d'ailleurs l'indiquer le "--" séparateur classique des NG, ce n'est pas non plus un
Le séparateur est "-- n", ne pas oublier l'espace... ;)
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- ah koi ca sert de donner son nom si ce n'est pour avoir des emmerdes ? vous avez pas vu encore ke des barges il y en a partout et que devoiler toute ces informations c'est dangereux ? -+- Mickey in GNU : Le retour du fils de l'homme invisible -+-
Horst Kraemer
On 29 Apr 2004 08:00:12 GMT, Marc Boyer wrote:
Pierre Maurette wrote:
Ce qui veut dire qu'AMHA, un compilateur C ne devrait pas pouvoir proposer d'option "Evaluation booléenne complète". Faut le faire à la main. En se méfiant des optimisations.
Ou alors, on joue avec & et | et des == 1
Eval complète de a && b se fait avec a == 1 & b == 1
Non. Avec
a!=0 & b!=0
ou bien avec
!!a & !!b
-- Horst
On 29 Apr 2004 08:00:12 GMT, Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
Pierre Maurette wrote:
Ce qui veut dire qu'AMHA, un compilateur C ne devrait pas pouvoir
proposer d'option "Evaluation booléenne complète". Faut le faire à la
main. En se méfiant des optimisations.
Ou alors, on joue avec & et | et des == 1
Eval complète de
a && b
se fait avec
a == 1 & b == 1
Ce qui veut dire qu'AMHA, un compilateur C ne devrait pas pouvoir proposer d'option "Evaluation booléenne complète". Faut le faire à la main. En se méfiant des optimisations.
Ou alors, on joue avec & et | et des == 1
Eval complète de a && b se fait avec a == 1 & b == 1
Non. Avec
a!=0 & b!=0
ou bien avec
!!a & !!b
-- Horst
Xavier Combelle
Horst Kraemer wrote:
On 29 Apr 2004 08:00:12 GMT, Marc Boyer wrote:
Pierre Maurette wrote:
Ce qui veut dire qu'AMHA, un compilateur C ne devrait pas pouvoir proposer d'option "Evaluation booléenne complète". Faut le faire à la main. En se méfiant des optimisations.
Ou alors, on joue avec & et | et des == 1
Eval complète de a && b se fait avec a == 1 & b == 1
Non. Avec
a!=0 & b!=0
ou bien avec
!!a & !!b
Naivement, je pensait que la clarté du code était importante, j'aurait sugéré, en introduisant deux variables supplementaires: a_est_vrai = a, b_est_vrai = b, a_est_vrai && b_est_vrai
Xavier
Horst Kraemer wrote:
On 29 Apr 2004 08:00:12 GMT, Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
Pierre Maurette wrote:
Ce qui veut dire qu'AMHA, un compilateur C ne devrait pas pouvoir
proposer d'option "Evaluation booléenne complète". Faut le faire à la
main. En se méfiant des optimisations.
Ou alors, on joue avec & et | et des == 1
Eval complète de
a && b
se fait avec
a == 1 & b == 1
Non. Avec
a!=0 & b!=0
ou bien avec
!!a & !!b
Naivement, je pensait que la clarté du code
était importante, j'aurait sugéré, en introduisant
deux variables supplementaires:
a_est_vrai = a, b_est_vrai = b, a_est_vrai && b_est_vrai
Ce qui veut dire qu'AMHA, un compilateur C ne devrait pas pouvoir proposer d'option "Evaluation booléenne complète". Faut le faire à la main. En se méfiant des optimisations.
Ou alors, on joue avec & et | et des == 1
Eval complète de a && b se fait avec a == 1 & b == 1
Non. Avec
a!=0 & b!=0
ou bien avec
!!a & !!b
Naivement, je pensait que la clarté du code était importante, j'aurait sugéré, en introduisant deux variables supplementaires: a_est_vrai = a, b_est_vrai = b, a_est_vrai && b_est_vrai
Xavier
Marc Boyer
Xavier Combelle wrote:
Horst Kraemer wrote:
On 29 Apr 2004 08:00:12 GMT, Marc Boyer wrote: Non. Avec a!=0 & b!=0
ou bien avec !!a & !!b
Naivement, je pensait que la clarté du code était importante, j'aurait sugéré, en introduisant deux variables supplementaires: a_est_vrai = a, b_est_vrai = b, a_est_vrai && b_est_vrai
Mais quelle est la mesure qui permet de dire que c'est plus clair ? La notion de clarté dépend de pleins de choses, et trop d'information tue l'information. A titre personnel, je préfère if ( a!=0 & b!=0 ) // <=> a && b avec evaluation systematique de b plutot que a_est_vrai= a; b_est_vrai= b; if (a_est_vrai && b_est_vrai) mais je ne pretends pas que mon jugement sur ce point soit universel.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Xavier Combelle wrote:
Horst Kraemer wrote:
On 29 Apr 2004 08:00:12 GMT, Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
Non. Avec
a!=0 & b!=0
ou bien avec
!!a & !!b
Naivement, je pensait que la clarté du code
était importante, j'aurait sugéré, en introduisant
deux variables supplementaires:
a_est_vrai = a, b_est_vrai = b, a_est_vrai && b_est_vrai
Mais quelle est la mesure qui permet de dire que c'est plus
clair ?
La notion de clarté dépend de pleins de choses, et trop
d'information tue l'information. A titre personnel, je préfère
if ( a!=0 & b!=0 ) // <=> a && b avec evaluation systematique de b
plutot que
a_est_vrai= a;
b_est_vrai= b;
if (a_est_vrai && b_est_vrai)
mais je ne pretends pas que mon jugement sur ce point soit universel.
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
On 29 Apr 2004 08:00:12 GMT, Marc Boyer wrote: Non. Avec a!=0 & b!=0
ou bien avec !!a & !!b
Naivement, je pensait que la clarté du code était importante, j'aurait sugéré, en introduisant deux variables supplementaires: a_est_vrai = a, b_est_vrai = b, a_est_vrai && b_est_vrai
Mais quelle est la mesure qui permet de dire que c'est plus clair ? La notion de clarté dépend de pleins de choses, et trop d'information tue l'information. A titre personnel, je préfère if ( a!=0 & b!=0 ) // <=> a && b avec evaluation systematique de b plutot que a_est_vrai= a; b_est_vrai= b; if (a_est_vrai && b_est_vrai) mais je ne pretends pas que mon jugement sur ce point soit universel.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Horst Kraemer
On Fri, 30 Apr 2004 10:21:19 +0200, Xavier Combelle wrote:
Horst Kraemer wrote:
On 29 Apr 2004 08:00:12 GMT, Marc Boyer wrote:
Pierre Maurette wrote:
Ce qui veut dire qu'AMHA, un compilateur C ne devrait pas pouvoir proposer d'option "Evaluation booléenne complète". Faut le faire à la main. En se méfiant des optimisations.
Ou alors, on joue avec & et | et des == 1
Eval complète de a && b se fait avec a == 1 & b == 1
Non. Avec
a!=0 & b!=0
ou bien avec
!!a & !!b
Naivement, je pensait que la clarté du code était importante, j'aurait sugéré, en introduisant deux variables supplementaires: a_est_vrai = a, b_est_vrai = b, a_est_vrai && b_est_vrai
Bien sûr. Dans la "vraie vie" j'utiliserais toujours cette version au lieu de jouets comme a!=0&b!=0 ou !!a&!!b.
On 29 Apr 2004 08:00:12 GMT, Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
Pierre Maurette wrote:
Ce qui veut dire qu'AMHA, un compilateur C ne devrait pas pouvoir
proposer d'option "Evaluation booléenne complète". Faut le faire à la
main. En se méfiant des optimisations.
Ou alors, on joue avec & et | et des == 1
Eval complète de
a && b
se fait avec
a == 1 & b == 1
Non. Avec
a!=0 & b!=0
ou bien avec
!!a & !!b
Naivement, je pensait que la clarté du code
était importante, j'aurait sugéré, en introduisant
deux variables supplementaires:
a_est_vrai = a, b_est_vrai = b, a_est_vrai && b_est_vrai
Bien sûr. Dans la "vraie vie" j'utiliserais toujours cette version au
lieu de jouets comme a!=0&b!=0 ou !!a&!!b.
On Fri, 30 Apr 2004 10:21:19 +0200, Xavier Combelle wrote:
Horst Kraemer wrote:
On 29 Apr 2004 08:00:12 GMT, Marc Boyer wrote:
Pierre Maurette wrote:
Ce qui veut dire qu'AMHA, un compilateur C ne devrait pas pouvoir proposer d'option "Evaluation booléenne complète". Faut le faire à la main. En se méfiant des optimisations.
Ou alors, on joue avec & et | et des == 1
Eval complète de a && b se fait avec a == 1 & b == 1
Non. Avec
a!=0 & b!=0
ou bien avec
!!a & !!b
Naivement, je pensait que la clarté du code était importante, j'aurait sugéré, en introduisant deux variables supplementaires: a_est_vrai = a, b_est_vrai = b, a_est_vrai && b_est_vrai
Bien sûr. Dans la "vraie vie" j'utiliserais toujours cette version au lieu de jouets comme a!=0&b!=0 ou !!a&!!b.
-- Horst
Xavier Combelle
Mais quelle est la mesure qui permet de dire que c'est plus clair ? La notion de clarté dépend de pleins de choses, et trop d'information tue l'information. A titre personnel, je préfère if ( a!=0 & b!=0 ) // <=> a && b avec evaluation systematique de b plutot que a_est_vrai= a; b_est_vrai= b; if (a_est_vrai && b_est_vrai) mais je ne pretends pas que mon jugement sur ce point soit universel.
Qu'est-ce qu'on appelle plus clair, c'est une vrai question. Pour ma part, je considère qu'un code clair ne doit pas se reposer sur une subtilité du langage.
C'est pour cette raison que j'évite d'utiliser l'opérateur ternaire ?: ou la construction suivante: printf("Hello ---------------------------------- " " Worldn");
La raison principale est, qu'en général, j'ignore les connaissances qu'ont les personnes qui vont relire mon code. je suppose donc qu'elles n'ont que le minimum requis.
Amicalement, Xavier
Mais quelle est la mesure qui permet de dire que c'est plus
clair ?
La notion de clarté dépend de pleins de choses, et trop
d'information tue l'information. A titre personnel, je préfère
if ( a!=0 & b!=0 ) // <=> a && b avec evaluation systematique de b
plutot que
a_est_vrai= a;
b_est_vrai= b;
if (a_est_vrai && b_est_vrai)
mais je ne pretends pas que mon jugement sur ce point soit universel.
Qu'est-ce qu'on appelle plus clair, c'est une vrai question.
Pour ma part, je considère qu'un code clair ne doit pas se reposer
sur une subtilité du langage.
C'est pour cette raison que j'évite d'utiliser l'opérateur ternaire ?:
ou la construction suivante:
printf("Hello ---------------------------------- "
" Worldn");
La raison principale est, qu'en général, j'ignore les connaissances
qu'ont les personnes qui vont relire mon code. je suppose donc
qu'elles n'ont que le minimum requis.
Mais quelle est la mesure qui permet de dire que c'est plus clair ? La notion de clarté dépend de pleins de choses, et trop d'information tue l'information. A titre personnel, je préfère if ( a!=0 & b!=0 ) // <=> a && b avec evaluation systematique de b plutot que a_est_vrai= a; b_est_vrai= b; if (a_est_vrai && b_est_vrai) mais je ne pretends pas que mon jugement sur ce point soit universel.
Qu'est-ce qu'on appelle plus clair, c'est une vrai question. Pour ma part, je considère qu'un code clair ne doit pas se reposer sur une subtilité du langage.
C'est pour cette raison que j'évite d'utiliser l'opérateur ternaire ?: ou la construction suivante: printf("Hello ---------------------------------- " " Worldn");
La raison principale est, qu'en général, j'ignore les connaissances qu'ont les personnes qui vont relire mon code. je suppose donc qu'elles n'ont que le minimum requis.
Amicalement, Xavier
Marc Boyer
Xavier Combelle wrote:
Qu'est-ce qu'on appelle plus clair, c'est une vrai question. Pour ma part, je considère qu'un code clair ne doit pas se reposer sur une subtilité du langage.
Oui, mais chaque règle a ses limites. Pour moi, un code clair, c'est un code qui permet plusieurs vitesses de lecture non ambigues. J'aime aussi l'idiome "small is beautifull": on écrit que le code nécessaire, on fait pas dans le verbeux qui englobe le code utile dans du bruit.
C'est pour cette raison que j'évite d'utiliser l'opérateur ternaire ?:
Je limite son usage aux cas où il simplifie l'écriture et évite une imbrication inutile.
ou la construction suivante: printf("Hello ---------------------------------- " " Worldn");
Là, non, pas d'accord. La série de 4 printf, je trouve que c'est du bruit...
La raison principale est, qu'en général, j'ignore les connaissances qu'ont les personnes qui vont relire mon code. je suppose donc qu'elles n'ont que le minimum requis.
Oui, mais dans ce cas, l'usage de & associé à un commentaire on peut avoir une lecture rapide du if, et si on s'y intéresse plus, on regarde de pret et le commentaire explique. Le fait de faire les affectations avant, j'y vois une sémantique différente dans le flot de controle.
Ceci dit, on discute autour d'une hypothèse de base "évaluation systématique" qui est AMHA une mauvaise idée, et qui ne nous ammène qu'à de mauvaises solutions ;-)
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Xavier Combelle wrote:
Qu'est-ce qu'on appelle plus clair, c'est une vrai question.
Pour ma part, je considère qu'un code clair ne doit pas se reposer
sur une subtilité du langage.
Oui, mais chaque règle a ses limites.
Pour moi, un code clair, c'est un code qui permet plusieurs
vitesses de lecture non ambigues.
J'aime aussi l'idiome "small is beautifull": on écrit
que le code nécessaire, on fait pas dans le verbeux qui
englobe le code utile dans du bruit.
C'est pour cette raison que j'évite d'utiliser l'opérateur ternaire ?:
Je limite son usage aux cas où il simplifie l'écriture
et évite une imbrication inutile.
ou la construction suivante:
printf("Hello ---------------------------------- "
" Worldn");
Là, non, pas d'accord. La série de 4 printf, je trouve
que c'est du bruit...
La raison principale est, qu'en général, j'ignore les connaissances
qu'ont les personnes qui vont relire mon code. je suppose donc
qu'elles n'ont que le minimum requis.
Oui, mais dans ce cas, l'usage de & associé à un commentaire
on peut avoir une lecture rapide du if, et si on s'y intéresse
plus, on regarde de pret et le commentaire explique.
Le fait de faire les affectations avant, j'y vois une
sémantique différente dans le flot de controle.
Ceci dit, on discute autour d'une hypothèse de base
"évaluation systématique" qui est AMHA une mauvaise idée,
et qui ne nous ammène qu'à de mauvaises solutions ;-)
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
Qu'est-ce qu'on appelle plus clair, c'est une vrai question. Pour ma part, je considère qu'un code clair ne doit pas se reposer sur une subtilité du langage.
Oui, mais chaque règle a ses limites. Pour moi, un code clair, c'est un code qui permet plusieurs vitesses de lecture non ambigues. J'aime aussi l'idiome "small is beautifull": on écrit que le code nécessaire, on fait pas dans le verbeux qui englobe le code utile dans du bruit.
C'est pour cette raison que j'évite d'utiliser l'opérateur ternaire ?:
Je limite son usage aux cas où il simplifie l'écriture et évite une imbrication inutile.
ou la construction suivante: printf("Hello ---------------------------------- " " Worldn");
Là, non, pas d'accord. La série de 4 printf, je trouve que c'est du bruit...
La raison principale est, qu'en général, j'ignore les connaissances qu'ont les personnes qui vont relire mon code. je suppose donc qu'elles n'ont que le minimum requis.
Oui, mais dans ce cas, l'usage de & associé à un commentaire on peut avoir une lecture rapide du if, et si on s'y intéresse plus, on regarde de pret et le commentaire explique. Le fait de faire les affectations avant, j'y vois une sémantique différente dans le flot de controle.
Ceci dit, on discute autour d'une hypothèse de base "évaluation systématique" qui est AMHA une mauvaise idée, et qui ne nous ammène qu'à de mauvaises solutions ;-)
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Régis Troadec
"Xavier Combelle" a écrit dans le message de news:40975ece$0$17914$
Salut,
Qu'est-ce qu'on appelle plus clair, c'est une vrai question. Pour ma part, je considère qu'un code clair ne doit pas se reposer sur une subtilité du langage.
Oui, mais qu'est-ce qu'on entend par subtilité de langage ? En C, un usage abusif de pointeurs ou de macros a vite fait de faire tourner les programmeurs en bourrique. Il y aussi une question de style (indentation, noms donnés aux variables, fonctions, etc....) qui fera que le programmeur mettra plus ou moins de temps à appréhender le code. Suivre un référentiel de codage ainsi que bien documenter son code sont indispensables pour une reprise de code aisée.
C'est pour cette raison que j'évite d'utiliser l'opérateur ternaire ?:
Je le trouve tout indiqué et très lisible dans le cas d'une affection à une variable dépendante d'une condition simple. Je ne l'utiliserai par contre pas récursivement, c'est là que ca devient illisible et une siouxerie.
ou la construction suivante: printf("Hello ---------------------------------- " " Worldn");
Comme Marc, je ne suis pas d'accord. La concaténation automatique de chaines constantes est je pense un atout et confère une très bonne lisibilité à l'usage de fonctions prenant des chaines en paramètres.
La raison principale est, qu'en général, j'ignore les connaissances qu'ont les personnes qui vont relire mon code. je suppose donc qu'elles n'ont que le minimum requis.
Si le code est bien documenté et que tu as bien respecté un référentiel (à commencer par la norme :)), je considère qu'il n'y a pas de minimum requis. A la personne aussi de se documenter, de consulter le référentiel et d'apprendre le cas échéant, bref, tout benef pour elle aussi.
Regis
"Xavier Combelle" <xavier_combelle@yahoo.fr> a écrit dans le message de
news:40975ece$0$17914$626a14ce@news.free.fr...
Salut,
Qu'est-ce qu'on appelle plus clair, c'est une vrai question.
Pour ma part, je considère qu'un code clair ne doit pas se reposer
sur une subtilité du langage.
Oui, mais qu'est-ce qu'on entend par subtilité de langage ?
En C, un usage abusif de pointeurs ou de macros a vite fait de faire tourner
les programmeurs en bourrique. Il y aussi une question de style
(indentation, noms donnés aux variables, fonctions, etc....) qui fera que le
programmeur mettra plus ou moins de temps à appréhender le code. Suivre un
référentiel de codage ainsi que bien documenter son code sont indispensables
pour une reprise de code aisée.
C'est pour cette raison que j'évite d'utiliser l'opérateur ternaire ?:
Je le trouve tout indiqué et très lisible dans le cas d'une affection à une
variable dépendante d'une condition simple. Je ne l'utiliserai par contre
pas récursivement, c'est là que ca devient illisible et une siouxerie.
ou la construction suivante:
printf("Hello ---------------------------------- "
" Worldn");
Comme Marc, je ne suis pas d'accord. La concaténation automatique de chaines
constantes est je pense un atout et confère une très bonne lisibilité à
l'usage de fonctions prenant des chaines en paramètres.
La raison principale est, qu'en général, j'ignore les connaissances
qu'ont les personnes qui vont relire mon code. je suppose donc
qu'elles n'ont que le minimum requis.
Si le code est bien documenté et que tu as bien respecté un référentiel (à
commencer par la norme :)), je considère qu'il n'y a pas de minimum requis.
A la personne aussi de se documenter, de consulter le référentiel et
d'apprendre le cas échéant, bref, tout benef pour elle aussi.
"Xavier Combelle" a écrit dans le message de news:40975ece$0$17914$
Salut,
Qu'est-ce qu'on appelle plus clair, c'est une vrai question. Pour ma part, je considère qu'un code clair ne doit pas se reposer sur une subtilité du langage.
Oui, mais qu'est-ce qu'on entend par subtilité de langage ? En C, un usage abusif de pointeurs ou de macros a vite fait de faire tourner les programmeurs en bourrique. Il y aussi une question de style (indentation, noms donnés aux variables, fonctions, etc....) qui fera que le programmeur mettra plus ou moins de temps à appréhender le code. Suivre un référentiel de codage ainsi que bien documenter son code sont indispensables pour une reprise de code aisée.
C'est pour cette raison que j'évite d'utiliser l'opérateur ternaire ?:
Je le trouve tout indiqué et très lisible dans le cas d'une affection à une variable dépendante d'une condition simple. Je ne l'utiliserai par contre pas récursivement, c'est là que ca devient illisible et une siouxerie.
ou la construction suivante: printf("Hello ---------------------------------- " " Worldn");
Comme Marc, je ne suis pas d'accord. La concaténation automatique de chaines constantes est je pense un atout et confère une très bonne lisibilité à l'usage de fonctions prenant des chaines en paramètres.
La raison principale est, qu'en général, j'ignore les connaissances qu'ont les personnes qui vont relire mon code. je suppose donc qu'elles n'ont que le minimum requis.
Si le code est bien documenté et que tu as bien respecté un référentiel (à commencer par la norme :)), je considère qu'il n'y a pas de minimum requis. A la personne aussi de se documenter, de consulter le référentiel et d'apprendre le cas échéant, bref, tout benef pour elle aussi.
