Voici donc ce qui devrait arriver dans les pages de man.
Par rapport à ce que nous avions proposé, les parties "WARNING"
et "BUG" ont été oublié, pour ne reprendre que la description
de ce qu'elles font, pas les mises en garde.
DESCRIPTION
The strcat() function appends the src string to the dest
string, overwriting the null character (`\0') at the end of
dest, and then adds a terminating null character. The
strings may not overlap, and the dest string must have
enough space for the result.
The strncat() function is similar, except that
* it will use at most n characters from src; and
* src does not need to be null terminated if it contains n
or more characters.
As with strcat(), the resulting string in dest is always
null terminated.
If src contains n or more characters, strcat() writes n+1
characters to dest (n from src plus the terminating null
character). Therefore, the size of dest must be at least
strlen(dest)+n+1.
"Charlie Gordon" a écrit dans le message de news:468060bc$0$29160$
Encore sur l'élégance : 0 == n est une faute de goût qui détonne. Pourquoi ignorer les conventions de nommages apparentes dans ces quelques lignes ?
Goût, élégance ?? Est-ce que je lis bien : ecrire n==0 est plus élégant que d'écrire 0==n ?
La "convention" d'écrire 0==n, présente __l'avantage objectif__ de distinguer une erreur de frappe. Cela à un "goût" d'éfficacité qui me va.
"La beauté est dans l'oeil".
Richard Delorme
"Charlie Gordon" a écrit dans le message de news:468060bc$0$29160$
Encore sur l'élégance : 0 == n est une faute de goût qui détonne. Pourquoi ignorer les conventions de nommages apparentes dans ces quelques lignes ?
Goût, élégance ?? Est-ce que je lis bien : ecrire n==0 est plus élégant que d'écrire 0==n ?
Tout du moins, c'est plus lisible , car dans « n == 0 » on a l'ordre grammatical habituel (pour nous Francophones ou Anglophones) _sujet_, _verbe_, _objet_.
La "convention" d'écrire 0==n, présente __l'avantage objectif__ de distinguer une erreur de frappe.
Comme les bons compilateurs détectent aussi l'erreur de frappe quand l'égalité est écrite dans l'autre sens, l'avantage n'est pas très grand. A la rigueur, écrire « !n » au lieu de « n == 0 » présenterait l'avantage de taper moins de caractères et d'éviter l'erreur sur le '==' mais c'est peu lisible.
"La beauté est dans l'oeil".
La beauté a l'ambiguïté d'être à la fois universelle et personnelle.
-- Richard
"Charlie Gordon" <news@chqrlie.org> a écrit dans le message de
news:468060bc$0$29160$426a74cc@news.free.fr...
Encore sur l'élégance : 0 == n est une faute de goût qui détonne.
Pourquoi ignorer les conventions de nommages apparentes dans ces quelques
lignes ?
Goût, élégance ??
Est-ce que je lis bien : ecrire n==0 est plus élégant que d'écrire 0==n ?
Tout du moins, c'est plus lisible , car dans « n == 0 » on a l'ordre
grammatical habituel (pour nous Francophones ou Anglophones) _sujet_,
_verbe_, _objet_.
La "convention" d'écrire 0==n, présente __l'avantage objectif__ de
distinguer une erreur de frappe.
Comme les bons compilateurs détectent aussi l'erreur de frappe quand
l'égalité est écrite dans l'autre sens, l'avantage n'est pas très grand.
A la rigueur, écrire « !n » au lieu de « n == 0 » présenterait
l'avantage de taper moins de caractères et d'éviter l'erreur sur le '=='
mais c'est peu lisible.
"La beauté est dans l'oeil".
La beauté a l'ambiguïté d'être à la fois universelle et personnelle.
"Charlie Gordon" a écrit dans le message de news:468060bc$0$29160$
Encore sur l'élégance : 0 == n est une faute de goût qui détonne. Pourquoi ignorer les conventions de nommages apparentes dans ces quelques lignes ?
Goût, élégance ?? Est-ce que je lis bien : ecrire n==0 est plus élégant que d'écrire 0==n ?
Tout du moins, c'est plus lisible , car dans « n == 0 » on a l'ordre grammatical habituel (pour nous Francophones ou Anglophones) _sujet_, _verbe_, _objet_.
La "convention" d'écrire 0==n, présente __l'avantage objectif__ de distinguer une erreur de frappe.
Comme les bons compilateurs détectent aussi l'erreur de frappe quand l'égalité est écrite dans l'autre sens, l'avantage n'est pas très grand. A la rigueur, écrire « !n » au lieu de « n == 0 » présenterait l'avantage de taper moins de caractères et d'éviter l'erreur sur le '==' mais c'est peu lisible.
"La beauté est dans l'oeil".
La beauté a l'ambiguïté d'être à la fois universelle et personnelle.
-- Richard
Stephane Legras-Decussy
"Sylvain" a écrit dans le message de news: 46805045$0$5089$
placer des tests invariants dans des boucles ne m'a paru élégant.
sauf que le code "pas élégant" de Charlie, je le comprends en une lecture, à 3h00 du matin, et avec un bébé qui pleure à côté...
c'est peut être une bonne définition de "maintenable"... :-)
"Sylvain" <noSpam@mail.net> a écrit dans le message de news:
46805045$0$5089$ba4acef3@news.orange.fr...
placer des tests invariants dans des boucles ne m'a paru élégant.
sauf que le code "pas élégant" de Charlie, je le comprends en une
lecture, à 3h00 du matin, et avec un bébé qui pleure à côté...
c'est peut être une bonne définition de "maintenable"... :-)
"Sylvain" a écrit dans le message de news: 46805045$0$5089$
placer des tests invariants dans des boucles ne m'a paru élégant.
sauf que le code "pas élégant" de Charlie, je le comprends en une lecture, à 3h00 du matin, et avec un bébé qui pleure à côté...
c'est peut être une bonne définition de "maintenable"... :-)
Ael Rowan Terence
"Richard Delorme" a écrit dans le message de news:46817688$0$21150$
"Charlie Gordon" a écrit dans le message de news:468060bc$0$29160$
Encore sur l'élégance : 0 == n est une faute de goût qui détonne. Pourquoi ignorer les conventions de nommages apparentes dans ces quelques
lignes ?
Goût, élégance ?? Est-ce que je lis bien : ecrire n==0 est plus élégant que d'écrire 0==n ?
Tout du moins, c'est plus lisible , car dans « n == 0 » on a l'ordre grammatical habituel (pour nous Francophones ou Anglophones) _sujet_, _verbe_, _objet_.
La "convention" d'écrire 0==n, présente __l'avantage objectif__ de distinguer une erreur de frappe.
Comme les bons compilateurs détectent aussi l'erreur de frappe quand l'égalité est écrite dans l'autre sens, l'avantage n'est pas très grand. A la rigueur, écrire « !n » au lieu de « n == 0 » présenterait l'avantage de taper moins de caractères et d'éviter l'erreur sur le '==' mais c'est peu lisible.
Pardon , je n'ai pas été clair, je parle de cette erreur de frappe, que le compilateur ne detecte pas : if ( n=0 )
A la place de if ( n==0)
Avec l'erreur de frappe le programme va compilé, et va même donner l'illusion de fonctionner sauf que le résultat est faux. Un fois établit que le programme ne va pas, on peut se lire se relire et se rerelire et ne pas voir la coquille.
par contre e compilateur va immédiatement donner une erreur lorsque il trouvera "if (0=n)" à la place de "if (0==n)"
"Richard Delorme" <richard-delorme@nospam.fr> a écrit dans le message de
news:46817688$0$21150$7a628cd7@news.club-internet.fr...
"Charlie Gordon" <news@chqrlie.org> a écrit dans le message de
news:468060bc$0$29160$426a74cc@news.free.fr...
Encore sur l'élégance : 0 == n est une faute de goût qui détonne.
Pourquoi ignorer les conventions de nommages apparentes dans ces
quelques
lignes ?
Goût, élégance ??
Est-ce que je lis bien : ecrire n==0 est plus élégant que d'écrire 0==n
?
Tout du moins, c'est plus lisible , car dans « n == 0 » on a l'ordre
grammatical habituel (pour nous Francophones ou Anglophones) _sujet_,
_verbe_, _objet_.
La "convention" d'écrire 0==n, présente __l'avantage objectif__ de
distinguer une erreur de frappe.
Comme les bons compilateurs détectent aussi l'erreur de frappe quand
l'égalité est écrite dans l'autre sens, l'avantage n'est pas très grand.
A la rigueur, écrire « !n » au lieu de « n == 0 » présenterait
l'avantage de taper moins de caractères et d'éviter l'erreur sur le '=='
mais c'est peu lisible.
Pardon , je n'ai pas été clair, je parle de cette erreur de frappe, que le
compilateur ne detecte pas :
if ( n=0 )
A la place de
if ( n==0)
Avec l'erreur de frappe le programme va compilé, et va même donner
l'illusion de fonctionner sauf que le résultat est faux.
Un fois établit que le programme ne va pas, on peut se lire se relire et se
rerelire et ne pas voir la coquille.
par contre e compilateur va immédiatement donner une erreur lorsque il
trouvera "if (0=n)" à la place de "if (0==n)"
"Richard Delorme" a écrit dans le message de news:46817688$0$21150$
"Charlie Gordon" a écrit dans le message de news:468060bc$0$29160$
Encore sur l'élégance : 0 == n est une faute de goût qui détonne. Pourquoi ignorer les conventions de nommages apparentes dans ces quelques
lignes ?
Goût, élégance ?? Est-ce que je lis bien : ecrire n==0 est plus élégant que d'écrire 0==n ?
Tout du moins, c'est plus lisible , car dans « n == 0 » on a l'ordre grammatical habituel (pour nous Francophones ou Anglophones) _sujet_, _verbe_, _objet_.
La "convention" d'écrire 0==n, présente __l'avantage objectif__ de distinguer une erreur de frappe.
Comme les bons compilateurs détectent aussi l'erreur de frappe quand l'égalité est écrite dans l'autre sens, l'avantage n'est pas très grand. A la rigueur, écrire « !n » au lieu de « n == 0 » présenterait l'avantage de taper moins de caractères et d'éviter l'erreur sur le '==' mais c'est peu lisible.
Pardon , je n'ai pas été clair, je parle de cette erreur de frappe, que le compilateur ne detecte pas : if ( n=0 )
A la place de if ( n==0)
Avec l'erreur de frappe le programme va compilé, et va même donner l'illusion de fonctionner sauf que le résultat est faux. Un fois établit que le programme ne va pas, on peut se lire se relire et se rerelire et ne pas voir la coquille.
par contre e compilateur va immédiatement donner une erreur lorsque il trouvera "if (0=n)" à la place de "if (0==n)"
Charlie Gordon
"Ael Rowan Terence" a écrit dans le message de news: f5tmrv$mnm$
Pardon , je n'ai pas été clair, je parle de cette erreur de frappe, que le compilateur ne detecte pas : if ( n=0 )
A la place de if ( n==0)
Avec l'erreur de frappe le programme va compilé, et va même donner l'illusion de fonctionner sauf que le résultat est faux.
Si ton compilateur ne proteste pas sur cette ligne, c'est qu'il est mal configuré. Il faut impérativement passer les bonnes options au compilateur pour qu'il fasse ce genre de verifications. Cela se fait en modifiant le Makefile ou le bouzin de projet sous Windos. Si encore ton compilateur n'offre pas la possibilité de protester sur if (n = 0) c'est qu'il doit être remplacé par un outil plus moderne.
Un fois établit que le programme ne va pas, on peut se lire se relire et se rerelire et ne pas voir la coquille.
Vrai. C'est pourquoi il faut utiliser des outils automatisés pour cela.
par contre e compilateur va immédiatement donner une erreur lorsque il trouvera "if (0=n)" à la place de "if (0==n)"
Effectivement, cette méthode classique fonctionne pour ce cas particulier, au prix d'une perte de lisibilité à mon avis, et je ne suis pas le seul à penser cela. Les outils automatisés (de la famille lint, splint...) ou le compilateur avec les bonnes options (-Wall au moins) détecteront non seulement ce cas d'erreur, mais pointeront aussi des tas d'autres problèmes potentiels : - variables utilisées potentiellement sans avoir été initialisées. - appels de fonction sans prototype - utilisation combinées d'opérateurs dont la précédence n'est souvent pas correctement maitrisée (ex: x = base + off & 0x7ff) - mélanges subtils d'opérandes signés et non-signés (ex: if (sizeof(buf)
-1) )
C'est tellement plus productif, qu'on ne peut plus s'en passer. Dès lors, la vue d'un idiome archaique comme if (0 == n) écorche les yeux, car il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
Chqrlie.
"Ael Rowan Terence" <Nul@Null.fr> a écrit dans le message de news:
f5tmrv$mnm$1@news1.completel.net...
Pardon , je n'ai pas été clair, je parle de cette erreur de frappe, que le
compilateur ne detecte pas :
if ( n=0 )
A la place de
if ( n==0)
Avec l'erreur de frappe le programme va compilé, et va même donner
l'illusion de fonctionner sauf que le résultat est faux.
Si ton compilateur ne proteste pas sur cette ligne, c'est qu'il est mal
configuré. Il faut impérativement passer les bonnes options au compilateur
pour qu'il fasse ce genre de verifications. Cela se fait en modifiant le
Makefile ou le bouzin de projet sous Windos. Si encore ton compilateur
n'offre pas la possibilité de protester sur if (n = 0) c'est qu'il doit
être remplacé par un outil plus moderne.
Un fois établit que le programme ne va pas, on peut se lire se relire et
se
rerelire et ne pas voir la coquille.
Vrai. C'est pourquoi il faut utiliser des outils automatisés pour cela.
par contre e compilateur va immédiatement donner une erreur lorsque il
trouvera "if (0=n)" à la place de "if (0==n)"
Effectivement, cette méthode classique fonctionne pour ce cas particulier,
au prix d'une perte de lisibilité à mon avis, et je ne suis pas le seul à
penser cela.
Les outils automatisés (de la famille lint, splint...) ou le compilateur
avec les bonnes options (-Wall au moins) détecteront non seulement ce cas
d'erreur, mais pointeront aussi des tas d'autres problèmes potentiels :
- variables utilisées potentiellement sans avoir été initialisées.
- appels de fonction sans prototype
- utilisation combinées d'opérateurs dont la précédence n'est souvent pas
correctement maitrisée (ex: x = base + off & 0x7ff)
- mélanges subtils d'opérandes signés et non-signés (ex: if (sizeof(buf)
-1) )
C'est tellement plus productif, qu'on ne peut plus s'en passer. Dès lors,
la vue d'un idiome archaique comme if (0 == n) écorche les yeux, car il
indique à l'évidence que son auteur a quelques trains de retard sur les
outils de développement, et que son code doit être relu avec d'autant plus
d'attention.
"Ael Rowan Terence" a écrit dans le message de news: f5tmrv$mnm$
Pardon , je n'ai pas été clair, je parle de cette erreur de frappe, que le compilateur ne detecte pas : if ( n=0 )
A la place de if ( n==0)
Avec l'erreur de frappe le programme va compilé, et va même donner l'illusion de fonctionner sauf que le résultat est faux.
Si ton compilateur ne proteste pas sur cette ligne, c'est qu'il est mal configuré. Il faut impérativement passer les bonnes options au compilateur pour qu'il fasse ce genre de verifications. Cela se fait en modifiant le Makefile ou le bouzin de projet sous Windos. Si encore ton compilateur n'offre pas la possibilité de protester sur if (n = 0) c'est qu'il doit être remplacé par un outil plus moderne.
Un fois établit que le programme ne va pas, on peut se lire se relire et se rerelire et ne pas voir la coquille.
Vrai. C'est pourquoi il faut utiliser des outils automatisés pour cela.
par contre e compilateur va immédiatement donner une erreur lorsque il trouvera "if (0=n)" à la place de "if (0==n)"
Effectivement, cette méthode classique fonctionne pour ce cas particulier, au prix d'une perte de lisibilité à mon avis, et je ne suis pas le seul à penser cela. Les outils automatisés (de la famille lint, splint...) ou le compilateur avec les bonnes options (-Wall au moins) détecteront non seulement ce cas d'erreur, mais pointeront aussi des tas d'autres problèmes potentiels : - variables utilisées potentiellement sans avoir été initialisées. - appels de fonction sans prototype - utilisation combinées d'opérateurs dont la précédence n'est souvent pas correctement maitrisée (ex: x = base + off & 0x7ff) - mélanges subtils d'opérandes signés et non-signés (ex: if (sizeof(buf)
-1) )
C'est tellement plus productif, qu'on ne peut plus s'en passer. Dès lors, la vue d'un idiome archaique comme if (0 == n) écorche les yeux, car il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
Chqrlie.
Thierry B.
--{ Charlie Gordon a plopé ceci: }--
la vue d'un idiome archaique comme if (0 == n) écorche les yeux, car il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
Je m'y attache, je m'y attache, mais il y a quand même 30000 lignes
dont certaines ont maintenant plus de 15 ans. En tout cas, merci à tous pour ces interessaints trol^Wconseils. Même après 20 ans de pratique, on a toujours quelque chose à apprendre ici...
-- Press any key to continue or any other key to quit
--{ Charlie Gordon a plopé ceci: }--
la vue d'un idiome archaique comme if (0 == n) écorche les yeux, car il
indique à l'évidence que son auteur a quelques trains de retard sur les
outils de développement, et que son code doit être relu avec d'autant plus
d'attention.
Je m'y attache, je m'y attache, mais il y a quand même 30000 lignes
dont certaines ont maintenant plus de 15 ans. En tout cas, merci à
tous pour ces interessaints trol^Wconseils. Même après 20 ans de
pratique, on a toujours quelque chose à apprendre ici...
--
Press any key to continue or any other key to quit
la vue d'un idiome archaique comme if (0 == n) écorche les yeux, car il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
Je m'y attache, je m'y attache, mais il y a quand même 30000 lignes
dont certaines ont maintenant plus de 15 ans. En tout cas, merci à tous pour ces interessaints trol^Wconseils. Même après 20 ans de pratique, on a toujours quelque chose à apprendre ici...
-- Press any key to continue or any other key to quit
Ael Rowan Terence
"Charlie Gordon" a écrit dans le message de news:46826773$0$10944$
"Ael Rowan Terence" a écrit dans le message de news: f5tmrv$mnm$
Les outils automatisés (de la famille lint, splint...) ou le compilateur avec les bonnes options (-Wall au moins) détecteront non seulement ce cas
d'erreur
Effectivement, j'ai quelques metros de retard.Je viens de vérifier. Et à la vérité, l'option est positionnée mais je continuais, malgré tout, avec l'idiome "affreux". Merci, pour l'éclaircissement.
"Charlie Gordon" <news@chqrlie.org> a écrit dans le message de
news:46826773$0$10944$426a74cc@news.free.fr...
"Ael Rowan Terence" <Nul@Null.fr> a écrit dans le message de news:
f5tmrv$mnm$1@news1.completel.net...
Les outils automatisés (de la famille lint, splint...) ou le compilateur
avec les bonnes options (-Wall au moins) détecteront non seulement ce cas
d'erreur
Effectivement, j'ai quelques metros de retard.Je viens de vérifier.
Et à la vérité, l'option est positionnée mais je continuais, malgré tout,
avec l'idiome "affreux".
Merci, pour l'éclaircissement.
"Charlie Gordon" a écrit dans le message de news:46826773$0$10944$
"Ael Rowan Terence" a écrit dans le message de news: f5tmrv$mnm$
Les outils automatisés (de la famille lint, splint...) ou le compilateur avec les bonnes options (-Wall au moins) détecteront non seulement ce cas
d'erreur
Effectivement, j'ai quelques metros de retard.Je viens de vérifier. Et à la vérité, l'option est positionnée mais je continuais, malgré tout, avec l'idiome "affreux". Merci, pour l'éclaircissement.
Sylvain
Charlie Gordon wrote on 27/06/2007 15:34:
[...] il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
les indications d'évidences fondées sur les seuls a priori du lecteur sont une source inépuisable de jugements stériles.
Sylvain.
Charlie Gordon wrote on 27/06/2007 15:34:
[...]
il indique à l'évidence que son auteur a quelques trains de retard sur les
outils de développement, et que son code doit être relu avec d'autant plus
d'attention.
les indications d'évidences fondées sur les seuls a priori du lecteur
sont une source inépuisable de jugements stériles.
[...] il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
les indications d'évidences fondées sur les seuls a priori du lecteur sont une source inépuisable de jugements stériles.
Sylvain.
Charlie Gordon
"Sylvain" a écrit dans le message de news: 46829f7b$0$25930$
Charlie Gordon wrote on 27/06/2007 15:34:
[...] il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
les indications d'évidences fondées sur les seuls a priori du lecteur sont une source inépuisable de jugements stériles.
C'est à dessein que j'emploie ce terme : est évident ce qui saute aux yeux. Le jugement que j'en tire est certes personnel, fondé sur mon expérience de relecture de code C quasi quotidienne depuis 25 ans. L'utilisation par l'auteur de cet idiome n'est pas une preuve en soi, c'est une indication statistiquement significative qu'il faut relire ce code avec plus d'attention, ne serait-ce qu'à cause de la gymnastique intellectuelle supplémentaire que ces constructions imposent.
Chqrlie.
"Sylvain" <noSpam@mail.net> a écrit dans le message de news:
46829f7b$0$25930$ba4acef3@news.orange.fr...
Charlie Gordon wrote on 27/06/2007 15:34:
[...]
il indique à l'évidence que son auteur a quelques trains de retard sur
les outils de développement, et que son code doit être relu avec d'autant
plus d'attention.
les indications d'évidences fondées sur les seuls a priori du lecteur sont
une source inépuisable de jugements stériles.
C'est à dessein que j'emploie ce terme : est évident ce qui saute aux yeux.
Le jugement que j'en tire est certes personnel, fondé sur mon expérience de
relecture de code C quasi quotidienne depuis 25 ans. L'utilisation par
l'auteur de cet idiome n'est pas une preuve en soi, c'est une indication
statistiquement significative qu'il faut relire ce code avec plus
d'attention, ne serait-ce qu'à cause de la gymnastique intellectuelle
supplémentaire que ces constructions imposent.
"Sylvain" a écrit dans le message de news: 46829f7b$0$25930$
Charlie Gordon wrote on 27/06/2007 15:34:
[...] il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
les indications d'évidences fondées sur les seuls a priori du lecteur sont une source inépuisable de jugements stériles.
C'est à dessein que j'emploie ce terme : est évident ce qui saute aux yeux. Le jugement que j'en tire est certes personnel, fondé sur mon expérience de relecture de code C quasi quotidienne depuis 25 ans. L'utilisation par l'auteur de cet idiome n'est pas une preuve en soi, c'est une indication statistiquement significative qu'il faut relire ce code avec plus d'attention, ne serait-ce qu'à cause de la gymnastique intellectuelle supplémentaire que ces constructions imposent.
Chqrlie.
Charlie Gordon
"Thierry B." a écrit dans le message de news:
--{ Charlie Gordon a plopé ceci: }--
la vue d'un idiome archaique comme if (0 == n) écorche les yeux, car il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
Je m'y attache, je m'y attache, mais il y a quand même 30000 lignes
dont certaines ont maintenant plus de 15 ans. En tout cas, merci à tous pour ces interessaints trol^Wconseils. Même après 20 ans de pratique, on a toujours quelque chose à apprendre ici...
Je pense la même chose. Hier, au détour d'une conversation de geek au resto, j'ai découvert un cas ou (*p) n'est pas équivalent à (p[0]).
Chqrlie.
"Thierry B." <tth@prout.stex> a écrit dans le message de news:
ku6al4-o66.ln1@prout.stex...
--{ Charlie Gordon a plopé ceci: }--
la vue d'un idiome archaique comme if (0 == n) écorche les yeux, car il
indique à l'évidence que son auteur a quelques trains de retard sur les
outils de développement, et que son code doit être relu avec d'autant
plus
d'attention.
Je m'y attache, je m'y attache, mais il y a quand même 30000 lignes
dont certaines ont maintenant plus de 15 ans. En tout cas, merci à
tous pour ces interessaints trol^Wconseils. Même après 20 ans de
pratique, on a toujours quelque chose à apprendre ici...
Je pense la même chose.
Hier, au détour d'une conversation de geek au resto, j'ai découvert un cas
ou (*p) n'est pas équivalent à (p[0]).
la vue d'un idiome archaique comme if (0 == n) écorche les yeux, car il indique à l'évidence que son auteur a quelques trains de retard sur les outils de développement, et que son code doit être relu avec d'autant plus d'attention.
Je m'y attache, je m'y attache, mais il y a quand même 30000 lignes
dont certaines ont maintenant plus de 15 ans. En tout cas, merci à tous pour ces interessaints trol^Wconseils. Même après 20 ans de pratique, on a toujours quelque chose à apprendre ici...
Je pense la même chose. Hier, au détour d'une conversation de geek au resto, j'ai découvert un cas ou (*p) n'est pas équivalent à (p[0]).
