Bonjours a tous.
J'ai ecrie ce morceau de code en C++ qui semble fonctionne
correctement. Mais je me demande s-il y a des choses que je peux
ameliorer dedans(La performance n'est pas un probleme) d'un point de
vue du style de programmation. Le but de ce code est d'annoter un
tableau deux dimensions 'dist' avec la distance en un point passe en
argument. Mais il existe des cases qui sont a distance infinie,
seul les cases qui sont notees comme etant EMPTY 't' 'g' ou 'c' dans
'data' doivent etre annotees. A chaque iteration du calcule je
determine une liste des cases qu'il faudra etudier a la prochaine
iteration. Puis pour etudier une cases je regarde simplement ces
voisines. Celle qui sont a une distance superieur sont ajouter a la
liste. La grille est initialiser a l'infini.
#include "Labyrinthe.h" // Declaration des constantes utiliser dans la
suite.
#include "inondation.h"
#include "iterator"
#include "list"
#include "iostream" // Pour le debugage.
using namespace std;
class Node
{
public:
unsigned short _x;
unsigned short _y;
Node(unsigned short xx,unsigned short yy)
{_x=xx;_y=yy;}
~Node(){}
};
void in_aux(char data[LAB_WIDTH][LAB_HEIGHT],unsigned long
dist[LAB_WIDTH][LAB_HEIGHT],list<Node*> *Fermer,unsigned long prof)
{
list<Node*> *Ouvert = new list<Node*>();
list<Node*>::iterator i;
int j=0;
for(j=0,i=Fermer->begin();i!=Fermer->end();++i)
{
unsigned short x=(*i)->_x,y=(*i)->_y;
if ( x<LAB_WIDTH && y<LAB_HEIGHT &&
(EMPTY==data[x][y] || 't'==data[x][y]
|| 'g'==data[x][y] || 'c'==data[x][y] )
&& prof<dist[x][y]
)
{
dist[x][y]=prof;
for (int k=-1;k<2;k++)
for (int l=-1;l<2;l++)
Ouvert->push_back(new Node( x+k , y+l ));
}
delete *i;
//cout << "j="<<j<<" .\n";
}
delete Fermer;
if (!Ouvert->empty()) in_aux(data,dist,Ouvert,++prof);
}
/*La fonction principal declarer dans l'interface.*/
void inondation(char data[LAB_WIDTH][LAB_HEIGHT],unsigned long
dist[LAB_WIDTH][LAB_HEIGHT],unsigned short t_x,unsigned short t_y)
{
for(int i=0;i<LAB_WIDTH;i++)
for(int j=0;j<LAB_HEIGHT;j++)
dist[i][j]=MAX_LONG;
list<Node*> *Ouvert = new list<Node*>();
Ouvert->push_back(new Node(t_x,t_y));
in_aux(data,dist,Ouvert,0);
}
#include "iterator" #include "list" #include "iostream" // Pour le debugage.
Si ceci compile il a fallut soit mettre le .cpp (ou .cc ou autre) dans le repertoire d'include de l'environnement de développement, ou déplacer les includes standard.
Il faut donc écrire : #include <iterator> #include <list> #include <iostream>
using namespace std;
class Node { public: unsigned short _x; unsigned short _y;
pourquoi ces membres sont publics ? dans ce cas, autant utiliser le mot clé struct, si tous les membres sont publics il est plus clair et permet la même chose que class, la seule différence étant que les membres sont publics par défaut à la place de privés par défaut.
Node(unsigned short xx,unsigned short yy) {_x=xx;_y=yy;}
Question de gout moi ici j'aurai utilisé les listes d'initialisation, mais ca c'est bien sûr pas universel, chacun fait ce qu'il veut.
donc :
Node(unsigned short _x, unsigned short _y):_x(_x),_y(_y) { }
~Node(){}
Si le destructeur est trivial c'est pas la peine de l'écrire :-)
};
void in_aux(char data[LAB_WIDTH][LAB_HEIGHT],unsigned long dist[LAB_WIDTH][LAB_HEIGHT],list<Node*> *Fermer,unsigned long prof) { list<Node*> *Ouvert = new list<Node*>();
C'est là que commence mes vraies remarque, pourquoi utiliser des pointeurs et des new lorsque ca n'a aucune utilité ? (enfin dans le code que l'on a je ne la vois pas). un simple list<Node*> Ouvert; aurait suffit non ? Et vu la taille de Node, je ne vois pas l'interet de travailler sur des pointeurs (sauf si Node est une hierarchie de classe et que l'on peut ainsi manipuler des élements différents selon les cas)
Pour moi un list< Node > Ouvert; serait suffisant et éviteerai ainsi tous ces delete.
list<Node*>::iterator i; int j=0; for(j=0,iþrmer->begin();i!þrmer->end();++i) { unsigned short x=(*i)->_x,y=(*i)->_y;
Ca rend assez bien comme ligne ca, et c'est surement aussi pour ca le public, pour pouvoir accéder aux membres de la class un peu partout, cependant ca enlève un peu la notion d'encapsulation des données du C++, en clair n'importe qui peut mettre la classe dans n'importe quel état, même un étant incohérent, à un moment donné.
avec ce que j'ai mis au dessus : Ouvert.push_back(Node(x+k, y+l));
} delete *i;
et ceci devient inutile.
//cout << "j="<<j<<" .n"; } delete Fermer;
Ca aussi, et cf la fonction du dessous pour quelques explications sur ca justement.
if (!Ouvert->empty()) in_aux(data,dist,Ouvert,++prof); }
/*La fonction principal declarer dans l'interface.*/ void inondation(char data[LAB_WIDTH][LAB_HEIGHT],unsigned long dist[LAB_WIDTH][LAB_HEIGHT],unsigned short t_x,unsigned short t_y) { for(int i=0;i<LAB_WIDTH;i++) for(int j=0;j<LAB_HEIGHT;j++) dist[i][j]=MAX_LONG;
list<Node*> *Ouvert = new list<Node*>();
Là comme au dessus je ne vois pas l'interet de toutes ces * et de ce new dans la ligne. Si l'interêt est de le passer par pointeurs à la fonction in_aux() juste en dessous, alors il aurait été possible de le déclarer normalement, donc sans new, et de passer son adresse avec un & à la fonction, en enlevant bien sûr le delete dans in_aux(). Mais le C++ fait encore mieux avec le passage par référence, il est donc préférable de recevoir une référence sur une list<Node> ou list<Node*> dans in_aux() et ceci nous permet de travailler sur la variable déclarée ici, sans à avoir à manipuler un pointeur. Petit exemple bidon :
#include <iostream>
void ajoute1(int &a) { a++; return; }
int main() { int varlocale = 42; ajoute1(varlocale); std::cout << varlocale << std::endl; }
Ceci affichera 43. En passage par référence il n'y a pas de copie de la variable comme en passage normale, on travaille donc sur l'original sans avoir la notation pointeur et donc le déréférencement à chaque opération. Après il y a peut etre une raison valable que l'on ne voit pas ici pour utiliser des list<Node*>*, pour le Node* ca serait de travailler sur des types dérivés de Node sans perte d'information sur le type réel, en clair de manipuler une liste de classe d'une même hierarchie, chaque item de la liste ayant un type réel qui peut etre différent de celui de l'élement d'avant ou d'après, et pour le list<>* je ne vois pas trop mais bon on ne sait jamais.
Anthony -- It's a bird.. It's a plane.. No, it's KernelMan, faster than a speeding bullet, to your rescue. Doing new kernel versions in under 5 seconds flat.. -- Linus, in the announcement for 1.3.27
daneel wrote:
Bonjours a tous.
Bonjour,
[...]
#include "iterator"
#include "list"
#include "iostream" // Pour le debugage.
Si ceci compile il a fallut soit mettre le .cpp (ou .cc ou autre) dans le
repertoire d'include de l'environnement de développement, ou déplacer les
includes standard.
Il faut donc écrire :
#include <iterator>
#include <list>
#include <iostream>
using namespace std;
class Node
{
public:
unsigned short _x;
unsigned short _y;
pourquoi ces membres sont publics ? dans ce cas, autant utiliser le mot clé
struct, si tous les membres sont publics il est plus clair et permet la
même chose que class, la seule différence étant que les membres sont
publics par défaut à la place de privés par défaut.
Node(unsigned short xx,unsigned short yy)
{_x=xx;_y=yy;}
Question de gout moi ici j'aurai utilisé les listes d'initialisation, mais
ca c'est bien sûr pas universel, chacun fait ce qu'il veut.
donc :
Node(unsigned short _x, unsigned short _y):_x(_x),_y(_y) { }
~Node(){}
Si le destructeur est trivial c'est pas la peine de l'écrire :-)
};
void in_aux(char data[LAB_WIDTH][LAB_HEIGHT],unsigned long
dist[LAB_WIDTH][LAB_HEIGHT],list<Node*> *Fermer,unsigned long prof)
{
list<Node*> *Ouvert = new list<Node*>();
C'est là que commence mes vraies remarque, pourquoi utiliser des pointeurs
et des new lorsque ca n'a aucune utilité ? (enfin dans le code que l'on a
je ne la vois pas).
un simple list<Node*> Ouvert; aurait suffit non ?
Et vu la taille de Node, je ne vois pas l'interet de travailler sur des
pointeurs (sauf si Node est une hierarchie de classe et que l'on peut ainsi
manipuler des élements différents selon les cas)
Pour moi un list< Node > Ouvert; serait suffisant et éviteerai ainsi tous
ces delete.
list<Node*>::iterator i;
int j=0;
for(j=0,iþrmer->begin();i!þrmer->end();++i)
{
unsigned short x=(*i)->_x,y=(*i)->_y;
Ca rend assez bien comme ligne ca, et c'est surement aussi pour ca le
public, pour pouvoir accéder aux membres de la class un peu partout,
cependant ca enlève un peu la notion d'encapsulation des données du C++, en
clair n'importe qui peut mettre la classe dans n'importe quel état, même un
étant incohérent, à un moment donné.
avec ce que j'ai mis au dessus :
Ouvert.push_back(Node(x+k, y+l));
}
delete *i;
et ceci devient inutile.
//cout << "j="<<j<<" .n";
}
delete Fermer;
Ca aussi, et cf la fonction du dessous pour quelques explications sur ca
justement.
if (!Ouvert->empty()) in_aux(data,dist,Ouvert,++prof);
}
/*La fonction principal declarer dans l'interface.*/
void inondation(char data[LAB_WIDTH][LAB_HEIGHT],unsigned long
dist[LAB_WIDTH][LAB_HEIGHT],unsigned short t_x,unsigned short t_y)
{
for(int i=0;i<LAB_WIDTH;i++)
for(int j=0;j<LAB_HEIGHT;j++)
dist[i][j]=MAX_LONG;
list<Node*> *Ouvert = new list<Node*>();
Là comme au dessus je ne vois pas l'interet de toutes ces * et de ce new
dans la ligne. Si l'interêt est de le passer par pointeurs à la fonction
in_aux() juste en dessous, alors il aurait été possible de le déclarer
normalement, donc sans new, et de passer son adresse avec un & à la
fonction, en enlevant bien sûr le delete dans in_aux().
Mais le C++ fait encore mieux avec le passage par référence, il est donc
préférable de recevoir une référence sur une list<Node> ou list<Node*> dans
in_aux() et ceci nous permet de travailler sur la variable déclarée ici,
sans à avoir à manipuler un pointeur. Petit exemple bidon :
#include <iostream>
void ajoute1(int &a) {
a++;
return;
}
int main() {
int varlocale = 42;
ajoute1(varlocale);
std::cout << varlocale << std::endl;
}
Ceci affichera 43. En passage par référence il n'y a pas de copie de la
variable comme en passage normale, on travaille donc sur l'original sans
avoir la notation pointeur et donc le déréférencement à chaque opération.
Après il y a peut etre une raison valable que l'on ne voit pas ici pour
utiliser des list<Node*>*, pour le Node* ca serait de travailler sur des
types dérivés de Node sans perte d'information sur le type réel, en clair
de manipuler une liste de classe d'une même hierarchie, chaque item de la
liste ayant un type réel qui peut etre différent de celui de l'élement
d'avant ou d'après, et pour le list<>* je ne vois pas trop mais bon on ne
sait jamais.
Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27
#include "iterator" #include "list" #include "iostream" // Pour le debugage.
Si ceci compile il a fallut soit mettre le .cpp (ou .cc ou autre) dans le repertoire d'include de l'environnement de développement, ou déplacer les includes standard.
Il faut donc écrire : #include <iterator> #include <list> #include <iostream>
using namespace std;
class Node { public: unsigned short _x; unsigned short _y;
pourquoi ces membres sont publics ? dans ce cas, autant utiliser le mot clé struct, si tous les membres sont publics il est plus clair et permet la même chose que class, la seule différence étant que les membres sont publics par défaut à la place de privés par défaut.
Node(unsigned short xx,unsigned short yy) {_x=xx;_y=yy;}
Question de gout moi ici j'aurai utilisé les listes d'initialisation, mais ca c'est bien sûr pas universel, chacun fait ce qu'il veut.
donc :
Node(unsigned short _x, unsigned short _y):_x(_x),_y(_y) { }
~Node(){}
Si le destructeur est trivial c'est pas la peine de l'écrire :-)
};
void in_aux(char data[LAB_WIDTH][LAB_HEIGHT],unsigned long dist[LAB_WIDTH][LAB_HEIGHT],list<Node*> *Fermer,unsigned long prof) { list<Node*> *Ouvert = new list<Node*>();
C'est là que commence mes vraies remarque, pourquoi utiliser des pointeurs et des new lorsque ca n'a aucune utilité ? (enfin dans le code que l'on a je ne la vois pas). un simple list<Node*> Ouvert; aurait suffit non ? Et vu la taille de Node, je ne vois pas l'interet de travailler sur des pointeurs (sauf si Node est une hierarchie de classe et que l'on peut ainsi manipuler des élements différents selon les cas)
Pour moi un list< Node > Ouvert; serait suffisant et éviteerai ainsi tous ces delete.
list<Node*>::iterator i; int j=0; for(j=0,iþrmer->begin();i!þrmer->end();++i) { unsigned short x=(*i)->_x,y=(*i)->_y;
Ca rend assez bien comme ligne ca, et c'est surement aussi pour ca le public, pour pouvoir accéder aux membres de la class un peu partout, cependant ca enlève un peu la notion d'encapsulation des données du C++, en clair n'importe qui peut mettre la classe dans n'importe quel état, même un étant incohérent, à un moment donné.
avec ce que j'ai mis au dessus : Ouvert.push_back(Node(x+k, y+l));
} delete *i;
et ceci devient inutile.
//cout << "j="<<j<<" .n"; } delete Fermer;
Ca aussi, et cf la fonction du dessous pour quelques explications sur ca justement.
if (!Ouvert->empty()) in_aux(data,dist,Ouvert,++prof); }
/*La fonction principal declarer dans l'interface.*/ void inondation(char data[LAB_WIDTH][LAB_HEIGHT],unsigned long dist[LAB_WIDTH][LAB_HEIGHT],unsigned short t_x,unsigned short t_y) { for(int i=0;i<LAB_WIDTH;i++) for(int j=0;j<LAB_HEIGHT;j++) dist[i][j]=MAX_LONG;
list<Node*> *Ouvert = new list<Node*>();
Là comme au dessus je ne vois pas l'interet de toutes ces * et de ce new dans la ligne. Si l'interêt est de le passer par pointeurs à la fonction in_aux() juste en dessous, alors il aurait été possible de le déclarer normalement, donc sans new, et de passer son adresse avec un & à la fonction, en enlevant bien sûr le delete dans in_aux(). Mais le C++ fait encore mieux avec le passage par référence, il est donc préférable de recevoir une référence sur une list<Node> ou list<Node*> dans in_aux() et ceci nous permet de travailler sur la variable déclarée ici, sans à avoir à manipuler un pointeur. Petit exemple bidon :
#include <iostream>
void ajoute1(int &a) { a++; return; }
int main() { int varlocale = 42; ajoute1(varlocale); std::cout << varlocale << std::endl; }
Ceci affichera 43. En passage par référence il n'y a pas de copie de la variable comme en passage normale, on travaille donc sur l'original sans avoir la notation pointeur et donc le déréférencement à chaque opération. Après il y a peut etre une raison valable que l'on ne voit pas ici pour utiliser des list<Node*>*, pour le Node* ca serait de travailler sur des types dérivés de Node sans perte d'information sur le type réel, en clair de manipuler une liste de classe d'une même hierarchie, chaque item de la liste ayant un type réel qui peut etre différent de celui de l'élement d'avant ou d'après, et pour le list<>* je ne vois pas trop mais bon on ne sait jamais.
Anthony -- It's a bird.. It's a plane.. No, it's KernelMan, faster than a speeding bullet, to your rescue. Doing new kernel versions in under 5 seconds flat.. -- Linus, in the announcement for 1.3.27
kanze
Anthony Fleury wrote in message news:<40bb0492$0$21557$...
daneel wrote:
[...]
#include "iterator" #include "list" #include "iostream" // Pour le debugage.
Si ceci compile il a fallut soit mettre le .cpp (ou .cc ou autre) dans le repertoire d'include de l'environnement de développement, ou déplacer les includes standard.
Tu l'as essayé ?
Selon la norme :
A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
# include <h-char_sequence> new-line
with the indentical contained sequence (including > characters, if any) from the original directive.
Donc, s'il n'y a pas de fichier « iterator » dans le répertoire courant, c'est comme s'il avait écrit <iterator>.
N'empêche que c'est effectivement préferrable de les mettre en <...>. Parce que si par hazard quelqu'un crée un fichier avec le nom "iterator", ce n'est pas ce fichier qu'on veut.
-- James Kanze GABI Software 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
Anthony Fleury <fleury_anthony@_hotmail_.com> wrote in message
news:<40bb0492$0$21557$626a14ce@news.free.fr>...
daneel wrote:
[...]
#include "iterator"
#include "list"
#include "iostream" // Pour le debugage.
Si ceci compile il a fallut soit mettre le .cpp (ou .cc ou autre) dans
le repertoire d'include de l'environnement de développement, ou
déplacer les includes standard.
Tu l'as essayé ?
Selon la norme :
A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of
the source file identified by the specified sequence between the "
delimiters. The named source file is searched for in an
implementation-defined manner. If this search is not supported, or
if the search fails, the directive is reprocessed as if it read
# include <h-char_sequence> new-line
with the indentical contained sequence (including > characters, if
any) from the original directive.
Donc, s'il n'y a pas de fichier « iterator » dans le répertoire courant,
c'est comme s'il avait écrit <iterator>.
N'empêche que c'est effectivement préferrable de les mettre en <...>.
Parce que si par hazard quelqu'un crée un fichier avec le nom
"iterator", ce n'est pas ce fichier qu'on veut.
--
James Kanze GABI Software
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
Anthony Fleury wrote in message news:<40bb0492$0$21557$...
daneel wrote:
[...]
#include "iterator" #include "list" #include "iostream" // Pour le debugage.
Si ceci compile il a fallut soit mettre le .cpp (ou .cc ou autre) dans le repertoire d'include de l'environnement de développement, ou déplacer les includes standard.
Tu l'as essayé ?
Selon la norme :
A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
# include <h-char_sequence> new-line
with the indentical contained sequence (including > characters, if any) from the original directive.
Donc, s'il n'y a pas de fichier « iterator » dans le répertoire courant, c'est comme s'il avait écrit <iterator>.
N'empêche que c'est effectivement préferrable de les mettre en <...>. Parce que si par hazard quelqu'un crée un fichier avec le nom "iterator", ce n'est pas ce fichier qu'on veut.
-- James Kanze GABI Software 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
kevin_sejourne
Merci beaucoup pour cette r'eponce d'etaill'e. Je vais pouvoir m'am'elirer en C++.
K'evin
Merci beaucoup pour cette r'eponce d'etaill'e. Je vais pouvoir
m'am'elirer en C++.
Petite remarque en passant, si on veut produire du code 'joli' (esthétiquement parlant), C++ n'est peut-être pas le meilleur choix...
Trop gros, passera pas...
James Kanze
Christophe de VIENNE writes:
|> > Petite remarque en passant, si on veut produire du code 'joli' |> > (esthétiquement parlant), C++ n'est peut-être pas le meilleur |> > choix...
|> Trop gros, passera pas...
Et puis, il y a des contre-exemples. C'est du C, mais je trouve http://www.ioccc.org/1986/marshall.c très joli.
L'esthétique, c'est là où on la trouve.
-- James Kanze 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
Christophe de VIENNE <cdevienne@alphacent.com> writes:
|> > Petite remarque en passant, si on veut produire du code 'joli'
|> > (esthétiquement parlant), C++ n'est peut-être pas le meilleur
|> > choix...
|> Trop gros, passera pas...
Et puis, il y a des contre-exemples. C'est du C, mais je trouve
http://www.ioccc.org/1986/marshall.c très joli.
L'esthétique, c'est là où on la trouve.
--
James Kanze
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
|> > Petite remarque en passant, si on veut produire du code 'joli' |> > (esthétiquement parlant), C++ n'est peut-être pas le meilleur |> > choix...
|> Trop gros, passera pas...
Et puis, il y a des contre-exemples. C'est du C, mais je trouve http://www.ioccc.org/1986/marshall.c très joli.
L'esthétique, c'est là où on la trouve.
-- James Kanze 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
Jean-Noël Mégoz
"James Kanze" a écrit dans le message de news:
Et puis, il y a des contre-exemples. C'est du C, mais je trouve http://www.ioccc.org/1986/marshall.c très joli.
L'esthétique, c'est là où on la trouve.
Excellent ! ;)
"James Kanze" <kanze@gabi-soft.fr> a écrit dans le message de
news:m2r7swz7vn.fsf@thomas-local.gabi-soft.fr...
Et puis, il y a des contre-exemples. C'est du C, mais je trouve
http://www.ioccc.org/1986/marshall.c très joli.
Et puis, il y a des contre-exemples. C'est du C, mais je trouve http://www.ioccc.org/1986/marshall.c très joli.
L'esthétique, c'est là où on la trouve.
Excellent ! ;)
BlueR
Bonjour
J'ai ecrie ce morceau de code en C++ qui semble fonctionne correctement. Mais je me demande s-il y a des choses que je peux ameliorer dedans
Je me souviens encore de ce qu'on me disait quand j'ai commencé le Pascal une ligne de code ==> une ligne de commentaire.
Je sais, ça ne concerne pas le code lui-même, mais quel temps gagné quand on doit reprendre des procédures plusieurs semaines plus tard (voire mois ou années).
-- BlueR
Bonjour
J'ai ecrie ce morceau de code en C++ qui semble fonctionne
correctement. Mais je me demande s-il y a des choses que je peux
ameliorer dedans
Je me souviens encore de ce qu'on me disait quand j'ai commencé le Pascal
une ligne de code ==> une ligne de commentaire.
Je sais, ça ne concerne pas le code lui-même, mais quel temps gagné quand on
doit reprendre des procédures plusieurs semaines plus tard (voire mois ou
années).
J'ai ecrie ce morceau de code en C++ qui semble fonctionne correctement. Mais je me demande s-il y a des choses que je peux ameliorer dedans
Je me souviens encore de ce qu'on me disait quand j'ai commencé le Pascal une ligne de code ==> une ligne de commentaire.
Je sais, ça ne concerne pas le code lui-même, mais quel temps gagné quand on doit reprendre des procédures plusieurs semaines plus tard (voire mois ou années).
-- BlueR
Michel Michaud
Dans news:,
Je me souviens encore de ce qu'on me disait quand j'ai commencé le Pascal une ligne de code ==> une ligne de commentaire.
S'il faut commenter chaque ligne c'est que le code n'est pas assez clair. Il faut le récrire, pas le commenter.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:930gc0t1nidej7h8l99hpgijc3q6e9iv77@4ax.com,
Je me souviens encore de ce qu'on me disait quand j'ai commencé
le Pascal une ligne de code ==> une ligne de commentaire.
S'il faut commenter chaque ligne c'est que le code n'est pas
assez clair. Il faut le récrire, pas le commenter.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Je me souviens encore de ce qu'on me disait quand j'ai commencé le Pascal une ligne de code ==> une ligne de commentaire.
S'il faut commenter chaque ligne c'est que le code n'est pas assez clair. Il faut le récrire, pas le commenter.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Jean-Noël Mégoz
"Michel Michaud" a écrit dans le message de news:of0yc.43642$
Dans news:,
Je me souviens encore de ce qu'on me disait quand j'ai commencé le Pascal une ligne de code ==> une ligne de commentaire.
S'il faut commenter chaque ligne c'est que le code n'est pas assez clair. Il faut le récrire, pas le commenter.
Ce n'est pas faux ! Mais admet que, dans l'ensemble, les programmeurs pêchent par lacune que par excès de commentaires... Sans aller à commenter chaque ligne, commenter chaque fonction me paraît un minimum, avec quelques petits plus sur les pièges à éviter.
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:of0yc.43642$sS2.1555976@news20.bellglobal.com...
Dans news:930gc0t1nidej7h8l99hpgijc3q6e9iv77@4ax.com,
Je me souviens encore de ce qu'on me disait quand j'ai commencé
le Pascal une ligne de code ==> une ligne de commentaire.
S'il faut commenter chaque ligne c'est que le code n'est pas
assez clair. Il faut le récrire, pas le commenter.
Ce n'est pas faux !
Mais admet que, dans l'ensemble, les programmeurs pêchent par lacune que par
excès de commentaires... Sans aller à commenter chaque ligne, commenter
chaque fonction me paraît un minimum, avec quelques petits plus sur les
pièges à éviter.
"Michel Michaud" a écrit dans le message de news:of0yc.43642$
Dans news:,
Je me souviens encore de ce qu'on me disait quand j'ai commencé le Pascal une ligne de code ==> une ligne de commentaire.
S'il faut commenter chaque ligne c'est que le code n'est pas assez clair. Il faut le récrire, pas le commenter.
Ce n'est pas faux ! Mais admet que, dans l'ensemble, les programmeurs pêchent par lacune que par excès de commentaires... Sans aller à commenter chaque ligne, commenter chaque fonction me paraît un minimum, avec quelques petits plus sur les pièges à éviter.
