Dans mon projet, j'ai cr=E9e un global.h qui contient tous les includes
des librairies annexes que j'utilise.
Du coup je mets ce global.h dans l'ent=EAte de mes classes ( qui
n'utilisent pas n=E9cessairement toutes les librairies =E0 la fois ).
Question : Est-ce qu'il vaut mieux mettre les #include au cas par cas
dans chaque header de les classes ? ( Et pourquoi ? )
Merci
G
ma principale motivation =E9tait de ne pas copier / coller des tonnes de
#include dans chaque .h
In article <49857132$0$9397$, Etienne Rousee wrote:
>Gégé a écrit : >> Du coup dans la déclaration de mes fonctions > >il faut que j'utilise std::string ;
>"string" seulement, si dans le cpp, tu mets le >"using namespace std;" avant le "#include ...".
Mauvais conseil, tres mauvais conseil.
Un fichier d'entetes qui depend de facon aussi directe de la maniere dont il est inclus, c'est une excellente recette pour trouver les emmerdes.
Très, très mauvais conseil. La présence d'un « using namespace » modifie la recherche du nom par la suite ; il peut donc modifier la sèmantique des en-têtes inclus par la suite. Du coup, il ne faut *jamais* le faire (au moins dans la portée globale) avant le dernier #include. (En général, je déconseillerais de le faire en dehors des portées limitée. limitée. Pour une définition de « limitée » qui dépend beaucoup du contexte.)
-- James Kanze
On 1 fév, 11:41, es...@lain.home (Marc Espie) wrote:
In article <49857132$0$9397$ba4ac...@news.orange.fr>,
Etienne Rousee <etie...@rousee.org> wrote:
>Gégé a écrit :
>> Du coup dans la déclaration de mes fonctions
> >il faut que j'utilise std::string ;
>"string" seulement, si dans le cpp, tu mets le
>"using namespace std;" avant le "#include ...".
Mauvais conseil, tres mauvais conseil.
Un fichier d'entetes qui depend de facon aussi directe de la
maniere dont il est inclus, c'est une excellente recette pour
trouver les emmerdes.
Très, très mauvais conseil. La présence d'un « using namespace »
modifie la recherche du nom par la suite ; il peut donc modifier
la sèmantique des en-têtes inclus par la suite. Du coup, il ne
faut *jamais* le faire (au moins dans la portée globale) avant
le dernier #include. (En général, je déconseillerais de le faire
en dehors des portées limitée. limitée. Pour une définition de
« limitée » qui dépend beaucoup du contexte.)
In article <49857132$0$9397$, Etienne Rousee wrote:
>Gégé a écrit : >> Du coup dans la déclaration de mes fonctions > >il faut que j'utilise std::string ;
>"string" seulement, si dans le cpp, tu mets le >"using namespace std;" avant le "#include ...".
Mauvais conseil, tres mauvais conseil.
Un fichier d'entetes qui depend de facon aussi directe de la maniere dont il est inclus, c'est une excellente recette pour trouver les emmerdes.
Très, très mauvais conseil. La présence d'un « using namespace » modifie la recherche du nom par la suite ; il peut donc modifier la sèmantique des en-têtes inclus par la suite. Du coup, il ne faut *jamais* le faire (au moins dans la portée globale) avant le dernier #include. (En général, je déconseillerais de le faire en dehors des portées limitée. limitée. Pour une définition de « limitée » qui dépend beaucoup du contexte.)
-- James Kanze
James Kanze
On 1 fév, 11:55, Fabien LE LEZ wrote:
On Sun, 1 Feb 2009 10:41:30 +0000 (UTC), (Marc Espie):
>Un fichier d'entetes qui depend de facon aussi directe de la >maniere dont il est inclus, c'est une excellente recette pour >trouver les emmerdes.
Yep. Un en-tête doit être autosuffisant, tout en ayant aussi peu d'effets secondaires que possible.
Donc :
- dans un .h, écrire systématiquement std::string, etc., et ne pas utiliser "using namespace" ni "using std::string".
En ce qui concerne std::, c'est probablement un bon conseil en général, et non seulement dans les en-têtes. C'est un espèce référentiel énorme, avec un contenu fluxuant, et un nom assez court qu'on peut se permettre de le citer à chaque utilisation.
En ce qui concerne d'autres namespaces, la règle est moins systèmatique. En absolu, pas de « using namespace » à la port ée globale dans un en-tête « exporté ». En revanche, dans des en-tête locaux, il m'arrive bien de faire un:
namespace Gabi { namespace Text { namespace SomeComponentPrivate { // ... } using namespace SomeComponentPrivate ; } }
En somme, dans l'implémentation de SomeComponent, le namespace SomeComponentPrivate fait logiquement partie de Gabi::Text (et il faudrait avouer qu'écrire systematiquement Gabi::Text::UTF8::RegularExpressionPrivate::, ça rend les expressions un peu lourdes).
- dans un .cpp, tu peux, si tu y tiens vraiment, écrire "using namespace std" après le dernier #include. Je me contente quant à moi d'introduire uniquement les noms que j'utilise beaucoup dans ce .cpp. Par exemple : using std::string; using std::vector;
Ces règles obligent à écrire "std::" un peu plus souvent que tu le voudrais, mais évite bien des emmerdes.
Ça rend aussi le code plus lisible. Si le nom de l'objet est std::cout (ce qui n'est pas un nom excessivement long), c'est bien plus lisible s'il s'écrit std::cout. L'intérêt des using n'apparaît que quand les noms sans le using devient excessivement longs.
-- James Kanze
On 1 fév, 11:55, Fabien LE LEZ <grams...@gramster.com> wrote:
On Sun, 1 Feb 2009 10:41:30 +0000 (UTC), es...@lain.home (Marc
Espie):
>Un fichier d'entetes qui depend de facon aussi directe de la
>maniere dont il est inclus, c'est une excellente recette pour
>trouver les emmerdes.
Yep. Un en-tête doit être autosuffisant, tout en ayant aussi
peu d'effets secondaires que possible.
Donc :
- dans un .h, écrire systématiquement std::string, etc., et ne
pas utiliser "using namespace" ni "using std::string".
En ce qui concerne std::, c'est probablement un bon conseil en
général, et non seulement dans les en-têtes. C'est un espèce
référentiel énorme, avec un contenu fluxuant, et un nom assez
court qu'on peut se permettre de le citer à chaque utilisation.
En ce qui concerne d'autres namespaces, la règle est moins
systèmatique. En absolu, pas de « using namespace » à la port ée
globale dans un en-tête « exporté ». En revanche, dans des
en-tête locaux, il m'arrive bien de faire un:
namespace Gabi {
namespace Text {
namespace SomeComponentPrivate {
// ...
}
using namespace SomeComponentPrivate ;
}
}
En somme, dans l'implémentation de SomeComponent, le namespace
SomeComponentPrivate fait logiquement partie de Gabi::Text (et
il faudrait avouer qu'écrire systematiquement
Gabi::Text::UTF8::RegularExpressionPrivate::, ça rend les
expressions un peu lourdes).
- dans un .cpp, tu peux, si tu y tiens vraiment, écrire
"using namespace std" après le dernier #include.
Je me contente quant à moi d'introduire uniquement les noms que
j'utilise beaucoup dans ce .cpp. Par exemple :
using std::string;
using std::vector;
Ces règles obligent à écrire "std::" un peu plus souvent que
tu le voudrais, mais évite bien des emmerdes.
Ça rend aussi le code plus lisible. Si le nom de l'objet est
std::cout (ce qui n'est pas un nom excessivement long), c'est
bien plus lisible s'il s'écrit std::cout. L'intérêt des using
n'apparaît que quand les noms sans le using devient
excessivement longs.
On Sun, 1 Feb 2009 10:41:30 +0000 (UTC), (Marc Espie):
>Un fichier d'entetes qui depend de facon aussi directe de la >maniere dont il est inclus, c'est une excellente recette pour >trouver les emmerdes.
Yep. Un en-tête doit être autosuffisant, tout en ayant aussi peu d'effets secondaires que possible.
Donc :
- dans un .h, écrire systématiquement std::string, etc., et ne pas utiliser "using namespace" ni "using std::string".
En ce qui concerne std::, c'est probablement un bon conseil en général, et non seulement dans les en-têtes. C'est un espèce référentiel énorme, avec un contenu fluxuant, et un nom assez court qu'on peut se permettre de le citer à chaque utilisation.
En ce qui concerne d'autres namespaces, la règle est moins systèmatique. En absolu, pas de « using namespace » à la port ée globale dans un en-tête « exporté ». En revanche, dans des en-tête locaux, il m'arrive bien de faire un:
namespace Gabi { namespace Text { namespace SomeComponentPrivate { // ... } using namespace SomeComponentPrivate ; } }
En somme, dans l'implémentation de SomeComponent, le namespace SomeComponentPrivate fait logiquement partie de Gabi::Text (et il faudrait avouer qu'écrire systematiquement Gabi::Text::UTF8::RegularExpressionPrivate::, ça rend les expressions un peu lourdes).
- dans un .cpp, tu peux, si tu y tiens vraiment, écrire "using namespace std" après le dernier #include. Je me contente quant à moi d'introduire uniquement les noms que j'utilise beaucoup dans ce .cpp. Par exemple : using std::string; using std::vector;
Ces règles obligent à écrire "std::" un peu plus souvent que tu le voudrais, mais évite bien des emmerdes.
Ça rend aussi le code plus lisible. Si le nom de l'objet est std::cout (ce qui n'est pas un nom excessivement long), c'est bien plus lisible s'il s'écrit std::cout. L'intérêt des using n'apparaît que quand les noms sans le using devient excessivement longs.
-- James Kanze
Jean-Marc Bourguet
Mickaël Wolff writes:
Fabien LE LEZ a écrit :
- dans un .h, écrire systématiquement std::string, etc., et ne pas utiliser "using namespace" ni "using std::string".
Et en utilisant la technique des namespaces anonymes ça te dérange aussi ?
namespace projet { namespace { using std::string ;
class machin { protected: string nom ;
//... } ; } }
Ça permet d'éviter la pollution du namespace global tout en permettant d'éviter de rendre le code trop lourd à la lecture.
Qu'est-ce que ça t'apporte par rapport à
namespace projet { using std::string ;
class machin { protected: string nom ;
//... } ; }
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Mickaël Wolff <mickael.wolff@laposte.net> writes:
Fabien LE LEZ a écrit :
- dans un .h, écrire systématiquement std::string, etc., et ne pas
utiliser "using namespace" ni "using std::string".
Et en utilisant la technique des namespaces anonymes ça te dérange aussi ?
namespace projet
{
namespace {
using std::string ;
class machin
{
protected:
string nom ;
//...
} ;
}
}
Ça permet d'éviter la pollution du namespace global tout en permettant
d'éviter de rendre le code trop lourd à la lecture.
Qu'est-ce que ça t'apporte par rapport à
namespace projet
{
using std::string ;
class machin
{
protected:
string nom ;
//...
} ;
}
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
- dans un .h, écrire systématiquement std::string, etc., et ne pas utiliser "using namespace" ni "using std::string".
Et en utilisant la technique des namespaces anonymes ça te dérange aussi ?
namespace projet { namespace { using std::string ;
class machin { protected: string nom ;
//... } ; } }
Ça permet d'éviter la pollution du namespace global tout en permettant d'éviter de rendre le code trop lourd à la lecture.
Qu'est-ce que ça t'apporte par rapport à
namespace projet { using std::string ;
class machin { protected: string nom ;
//... } ; }
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Mickaël Wolff writes:
Jean-Marc Bourguet a écrit :
Qu'est-ce que ça t'apporte par rapport à
project::string n'existe pas (normalement) avec le namespace anonyme, alors qu'il existe dans ta version.
Il me semble que si. En tout cas,
#include <string>
namespace projet { namespace { using std::string ; } }
void f() { projet::string x; }
passe avec les compilateurs que j'ai essayé (g++, Comeau).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Mickaël Wolff <mickael.wolff@laposte.net> writes:
Jean-Marc Bourguet a écrit :
Qu'est-ce que ça t'apporte par rapport à
project::string n'existe pas (normalement) avec le namespace anonyme,
alors qu'il existe dans ta version.
Il me semble que si. En tout cas,
#include <string>
namespace projet
{
namespace {
using std::string ;
}
}
void f()
{
projet::string x;
}
passe avec les compilateurs que j'ai essayé (g++, Comeau).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
project::string n'existe pas (normalement) avec le namespace anonyme, alors qu'il existe dans ta version.
Il me semble que si. En tout cas,
#include <string>
namespace projet { namespace { using std::string ; } }
void f() { projet::string x; }
passe avec les compilateurs que j'ai essayé (g++, Comeau).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
James Kanze
On Feb 1, 1:46 pm, Jean-Marc Bourguet wrote:
Mickaël Wolff writes: > Fabien LE LEZ a écrit : >> - dans un .h, écrire systématiquement std::string, etc., et ne pas >> utiliser "using namespace" ni "using std::string".
> Et en utilisant la technique des namespaces anonymes ça te > dérange aussi ?
> namespace projet > { > namespace { > using std::string ;
> class machin > { > protected: > string nom ;
> //... > } ; > } > }
> Ça permet d'éviter la pollution du namespace global tout > en permettant d'éviter de rendre le code trop lourd à la > lecture.
Qu'est-ce que ça t'apporte par rapport à
namespace projet { using std::string ;
class machin { protected: string nom ;
//... } ; }
La classe « machin » dans une unité de traduction n'est pas la même que dans une autre unité. On se démande même bien ce qu'elle fait dans un en-tête.
Sinon, c'est une « using declaration » ; c'est comme si std::string était en fait déclaré dans projet::<anonyme>.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Feb 1, 1:46 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Mickaël Wolff <mickael.wo...@laposte.net> writes:
> Fabien LE LEZ a écrit :
>> - dans un .h, écrire systématiquement std::string, etc., et ne pas
>> utiliser "using namespace" ni "using std::string".
> Et en utilisant la technique des namespaces anonymes ça te
> dérange aussi ?
> namespace projet
> {
> namespace {
> using std::string ;
> class machin
> {
> protected:
> string nom ;
> //...
> } ;
> }
> }
> Ça permet d'éviter la pollution du namespace global tout
> en permettant d'éviter de rendre le code trop lourd à la
> lecture.
Qu'est-ce que ça t'apporte par rapport à
namespace projet
{
using std::string ;
class machin
{
protected:
string nom ;
//...
} ;
}
La classe « machin » dans une unité de traduction n'est pas la
même que dans une autre unité. On se démande même bien ce
qu'elle fait dans un en-tête.
Sinon, c'est une « using declaration » ; c'est comme si
std::string était en fait déclaré dans projet::<anonyme>.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Mickaël Wolff writes: > Fabien LE LEZ a écrit : >> - dans un .h, écrire systématiquement std::string, etc., et ne pas >> utiliser "using namespace" ni "using std::string".
> Et en utilisant la technique des namespaces anonymes ça te > dérange aussi ?
> namespace projet > { > namespace { > using std::string ;
> class machin > { > protected: > string nom ;
> //... > } ; > } > }
> Ça permet d'éviter la pollution du namespace global tout > en permettant d'éviter de rendre le code trop lourd à la > lecture.
Qu'est-ce que ça t'apporte par rapport à
namespace projet { using std::string ;
class machin { protected: string nom ;
//... } ; }
La classe « machin » dans une unité de traduction n'est pas la même que dans une autre unité. On se démande même bien ce qu'elle fait dans un en-tête.
Sinon, c'est une « using declaration » ; c'est comme si std::string était en fait déclaré dans projet::<anonyme>.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Mickaël Wolff
James Kanze a écrit :
Sinon, c'est une « using declaration » ; c'est comme si std::string était en fait déclaré dans projet::<anonyme>.
En fait je m'étais complètement planté dans mon exemple. Ce que je voulais écrire c'était :
namespace projet { class machin ;
namespace { using str::string ; } }
Afin de tenter de limiter la portée du string à l'intérieur du namespace projet.
De toute façon, projet::string serait accessible depuis n'importe quelle unité comprenant l'en-tête. Donc de toute façon mon intuition était fausse, et l'usage du namespace anonyme n'était pas pertinente pour résoudre le problème l'origine de ce fil de discussion.
Sinon, c'est une « using declaration » ; c'est comme si
std::string était en fait déclaré dans projet::<anonyme>.
En fait je m'étais complètement planté dans mon exemple. Ce que je
voulais écrire c'était :
namespace projet
{
class machin ;
namespace {
using str::string ;
}
}
Afin de tenter de limiter la portée du string à l'intérieur du
namespace projet.
De toute façon, projet::string serait accessible depuis n'importe
quelle unité comprenant l'en-tête. Donc de toute façon mon intuition
était fausse, et l'usage du namespace anonyme n'était pas pertinente
pour résoudre le problème l'origine de ce fil de discussion.
Sinon, c'est une « using declaration » ; c'est comme si std::string était en fait déclaré dans projet::<anonyme>.
En fait je m'étais complètement planté dans mon exemple. Ce que je voulais écrire c'était :
namespace projet { class machin ;
namespace { using str::string ; } }
Afin de tenter de limiter la portée du string à l'intérieur du namespace projet.
De toute façon, projet::string serait accessible depuis n'importe quelle unité comprenant l'en-tête. Donc de toute façon mon intuition était fausse, et l'usage du namespace anonyme n'était pas pertinente pour résoudre le problème l'origine de ce fil de discussion.
"string" seulement, si dans le cpp, tu mets le "using namespace std;" avant le "#include ...".
et dans le cpp je mets un using namespace?
Oui, si tu veut éviter le "std::" et que tu ne prévois pas de problèmes de conflits de noms.
Ce qui suppose de savoir comment va se dérouler la suite de la vie de ce code, ce qui est raisonnable si on sait qu'on va jeter le code à la fin du TP, un peu moins si on envisage que ce code soit utilisé pour de vrai, maintenu, ré-utilisé, adapté...
Marc Boyer -- En France, un habitant sur 1000 est en prison. Aux USA, 7 habitants sur 1000 sont en prison. Est-ce que les USA sont 7 fois plus sûrs ?
On 2009-02-01, Etienne Rousee <etienne@rousee.org> wrote:
Gégé a écrit :
Du coup dans la déclaration de mes fonctions
>il faut que j'utilise std::string ;
"string" seulement, si dans le cpp, tu mets le
"using namespace std;" avant le "#include ...".
et dans le cpp je mets un using namespace?
Oui, si tu veut éviter le "std::" et que tu ne
prévois pas de problèmes de conflits de noms.
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Marc Boyer
--
En France, un habitant sur 1000 est en prison.
Aux USA, 7 habitants sur 1000 sont en prison.
Est-ce que les USA sont 7 fois plus sûrs ?
"string" seulement, si dans le cpp, tu mets le "using namespace std;" avant le "#include ...".
et dans le cpp je mets un using namespace?
Oui, si tu veut éviter le "std::" et que tu ne prévois pas de problèmes de conflits de noms.
Ce qui suppose de savoir comment va se dérouler la suite de la vie de ce code, ce qui est raisonnable si on sait qu'on va jeter le code à la fin du TP, un peu moins si on envisage que ce code soit utilisé pour de vrai, maintenu, ré-utilisé, adapté...
Marc Boyer -- En France, un habitant sur 1000 est en prison. Aux USA, 7 habitants sur 1000 sont en prison. Est-ce que les USA sont 7 fois plus sûrs ?
espie
In article , Marc Boyer wrote:
Ce qui suppose de savoir comment va se dérouler la suite de la vie de ce code, ce qui est raisonnable si on sait qu'on va jeter le code à la fin du TP, un peu moins si on envisage que ce code soit utilisé pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles, de facon mecanique, ce qui veut dire prendre des automatismes corrects. (comme presenter son code toujours de la meme facon, verifier les appels systemes qui peuvent echouer, ne pas laisser passer de warnings a la compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons de faire du code. On s'en prend une qui est correcte et on s'y tient. (et si on tombe sur un cas ou ca ne marche pas on essaie de se trouver une facon de corriger ce qu'on fait, de la maniere la plus simple et la plus automatique possible...)
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
(et si on tombe sur un cas ou ca ne marche pas on essaie de se trouver
une facon de corriger ce qu'on fait, de la maniere la plus simple et la
plus automatique possible...)
Ce qui suppose de savoir comment va se dérouler la suite de la vie de ce code, ce qui est raisonnable si on sait qu'on va jeter le code à la fin du TP, un peu moins si on envisage que ce code soit utilisé pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles, de facon mecanique, ce qui veut dire prendre des automatismes corrects. (comme presenter son code toujours de la meme facon, verifier les appels systemes qui peuvent echouer, ne pas laisser passer de warnings a la compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons de faire du code. On s'en prend une qui est correcte et on s'y tient. (et si on tombe sur un cas ou ca ne marche pas on essaie de se trouver une facon de corriger ce qu'on fait, de la maniere la plus simple et la plus automatique possible...)
Michael DOUBEZ
Marc Espie wrote:
In article , Marc Boyer wrote:
Ce qui suppose de savoir comment va se dérouler la suite de la vie de ce code, ce qui est raisonnable si on sait qu'on va jeter le code à la fin du TP, un peu moins si on envisage que ce code soit utilisé pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles, de facon mecanique, ce qui veut dire prendre des automatismes corrects. (comme presenter son code toujours de la meme facon, verifier les appels systemes qui peuvent echouer, ne pas laisser passer de warnings a la compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se concentrer sur les objectifs du TP plutôt que de passer du temps sur l'aspect qualité (qui est une mesure assez vague). En plus, le message est plus clair si il n'est pas parasité par des considérations secondes par rapport à ce qui doit être démontré.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons de faire du code. On s'en prend une qui est correcte et on s'y tient.
Les aficionados de PERL vont faire une attaque. :)
-- Michael
Marc Espie wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations secondes
par rapport à ce qui doit être démontré.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Les aficionados de PERL vont faire une attaque. :)
Ce qui suppose de savoir comment va se dérouler la suite de la vie de ce code, ce qui est raisonnable si on sait qu'on va jeter le code à la fin du TP, un peu moins si on envisage que ce code soit utilisé pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles, de facon mecanique, ce qui veut dire prendre des automatismes corrects. (comme presenter son code toujours de la meme facon, verifier les appels systemes qui peuvent echouer, ne pas laisser passer de warnings a la compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se concentrer sur les objectifs du TP plutôt que de passer du temps sur l'aspect qualité (qui est une mesure assez vague). En plus, le message est plus clair si il n'est pas parasité par des considérations secondes par rapport à ce qui doit être démontré.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons de faire du code. On s'en prend une qui est correcte et on s'y tient.
Les aficionados de PERL vont faire une attaque. :)
-- Michael
Jean-Marc Bourguet
Michael DOUBEZ writes:
Marc Espie wrote: > In article , > Marc Boyer wrote: >> Ce qui suppose de savoir comment va se dérouler >> la suite de la vie de ce code, ce qui est raisonnable >> si on sait qu'on va jeter le code à la fin du TP, >> un peu moins si on envisage que ce code soit utilisé >> pour de vrai, maintenu, ré-utilisé, adapté... > Euh, mauvaise logique, changer de logique. > Une bonne partie de l'informatique, c'est cense etre faire des choses > qui marchent de facon previsible. > 99% de ce qu'on fait est debile, c'est le 1% restant qui presente > de l'interet. > Il faut s'arranger pour que les 99% soient les plus simples possibles, > de facon mecanique, ce qui veut dire prendre des automatismes corrects. > (comme presenter son code toujours de la meme facon, verifier les appels > systemes qui peuvent echouer, ne pas laisser passer de warnings a la > compilation). > Si tu autorises les gens a prendre des habitudes differentes "parce que > c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se concentrer sur les objectifs du TP plutôt que de passer du temps sur l'aspect qualité (qui est une mesure assez vague). En plus, le message est plus clair si il n'est pas parasité par des considérations secondes par rapport à ce qui doit être démontré.
Si dans les TP on ne voit pas les bonnes pratiques, on prend beaucoup trop de mauvaises habitudes.
(Personnellement, j'avais pris le texte de Marc Boyer comme de l'ironie).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Michael DOUBEZ <michael.doubez@free.fr> writes:
Marc Espie wrote:
> In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
> Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
>> Ce qui suppose de savoir comment va se dérouler
>> la suite de la vie de ce code, ce qui est raisonnable
>> si on sait qu'on va jeter le code à la fin du TP,
>> un peu moins si on envisage que ce code soit utilisé
>> pour de vrai, maintenu, ré-utilisé, adapté...
> Euh, mauvaise logique, changer de logique.
> Une bonne partie de l'informatique, c'est cense etre faire des choses
> qui marchent de facon previsible.
> 99% de ce qu'on fait est debile, c'est le 1% restant qui presente
> de l'interet.
> Il faut s'arranger pour que les 99% soient les plus simples possibles,
> de facon mecanique, ce qui veut dire prendre des automatismes corrects.
> (comme presenter son code toujours de la meme facon, verifier les appels
> systemes qui peuvent echouer, ne pas laisser passer de warnings a la
> compilation).
> Si tu autorises les gens a prendre des habitudes differentes "parce que
> c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.
Si dans les TP on ne voit pas les bonnes pratiques, on prend beaucoup trop
de mauvaises habitudes.
(Personnellement, j'avais pris le texte de Marc Boyer comme de l'ironie).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Espie wrote: > In article , > Marc Boyer wrote: >> Ce qui suppose de savoir comment va se dérouler >> la suite de la vie de ce code, ce qui est raisonnable >> si on sait qu'on va jeter le code à la fin du TP, >> un peu moins si on envisage que ce code soit utilisé >> pour de vrai, maintenu, ré-utilisé, adapté... > Euh, mauvaise logique, changer de logique. > Une bonne partie de l'informatique, c'est cense etre faire des choses > qui marchent de facon previsible. > 99% de ce qu'on fait est debile, c'est le 1% restant qui presente > de l'interet. > Il faut s'arranger pour que les 99% soient les plus simples possibles, > de facon mecanique, ce qui veut dire prendre des automatismes corrects. > (comme presenter son code toujours de la meme facon, verifier les appels > systemes qui peuvent echouer, ne pas laisser passer de warnings a la > compilation). > Si tu autorises les gens a prendre des habitudes differentes "parce que > c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se concentrer sur les objectifs du TP plutôt que de passer du temps sur l'aspect qualité (qui est une mesure assez vague). En plus, le message est plus clair si il n'est pas parasité par des considérations secondes par rapport à ce qui doit être démontré.
Si dans les TP on ne voit pas les bonnes pratiques, on prend beaucoup trop de mauvaises habitudes.
(Personnellement, j'avais pris le texte de Marc Boyer comme de l'ironie).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
