Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Est-ce qu'il est jolie mon code?

Est-ce qu'il est jolie mon code?

14 réponses
Avatar
kevin_sejourne
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);
}

kevin.
Signaler un problème avec ce contenu

4 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Matthieu Moy
"Jean-Noël Mégoz" writes:

Ce n'est pas faux !
Mais admet que, dans l'ensemble, les programmeurs pêchent par lacune que par
excès de commentaires...


Ca, c'est variable. J'ai déjà vu

// explicit call to destructor
delete foo;

Dans du code donné en exemple de code bien commenté. Les commentaires
qui répètent le nom de la fonction (en supprimant les '_' et en
mettant un point à la fin pour faire une phrase) genre

// Faire quelque chose.
faire_quelque_chose();

Et le grand classique;

int i; // On déclare une variable entière i

...

i++; // On incrémente i.

Qui se retrouve souvent dans les TP d'étudiants débutants à qui on a
expliqué que les commentaires, c'est bien. Code qui devient après
quelques couches de débuggage;

int j; // On déclara une variable entière i

...

j--; // On incrémente i.

Parce que si il fallait maintenir les commentaires en même temps que
le code, on ne s'en sortirait pas ;-)

--
Matthieu

Avatar
Jean-Noël Mégoz
"Matthieu Moy" a écrit dans le message
de news:
"Jean-Noël Mégoz" writes:


Parce que si il fallait maintenir les commentaires en même temps que
le code, on ne s'en sortirait pas ;-)



Mdr ! ;)

Avatar
Michel Michaud
Dans news:40c8b838$0$26902$, Jean-Noël
"Michel Michaud" a écrit dans le message de
news:of0yc.43642$

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.


Je crois que le manque de commentaires n'est pas exactement le
vrai problème... C'est plutôt la qualité des commentaires. Si
tu demandes à quelqu'un de commenter obligatoirement tout (à un
niveau ou à un autre), il finira par devoir écrire des commentaires
« idiots » et pourra prendre l'habitude d'écrire n'importe quoi
partout... Ceci dit, pour les débutants et pendant l'apprentissage,
il faut imposer des contraintes sur ce qu'il faut commenter. Tant
qu'il est facile d'écrire quelque chose d'utile, ce ne sont pas
des contraintes qui vont donner des mauvaises habitudes...

Ainsi je mettrais un bémol à tes deux minimums. Dans la façon
moderne de programmer, on a plusieurs très petites fonctions qui,
si elles portent un nom significatif, sont assez claires pour ne
pas avoir besoin de commentaires. Un de mes critères pour un bon
commentaire est qu'il ne doit pas répéter ce qui est écrit (plus)
clairement et exactement dans le code. Arbitrairement, le standard
de programmation que j'utilise indique qu'il n'est pas nécessaire
de commenter les fonctions de moins de 10 lignes (mais il dit aussi
qu'on peut le faire si nécessaire ou utile...).

Pour ce qui est des « pièges à éviter », si tu veux parler de
pré-conditions ou de limites d'utilisation, je suis d'accord
qu'il faut commenter (et probablement mettre des assert !). Par
contre, si tu parles d'une mauvaise interprétation du code ou
du nom/rôle d'une fonction ou d'un bout de code, il faut revenir
à la réécriture avant de penser aux commentaires...

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/


Avatar
kanze
BlueR wrote in message
news:...


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 me souviens encore qu'on m'a dit que s'il faut commenter le code, il
n'est pas assez simple.

Dans la pratique, je ne suis pas tout à fait d'accord, et des
commentaires du genre : « implémente un arbre rouge-noire, voir Sedgwick
pp. ... », ou « invariantes de la boucle : ... » ne sont pas toujours
dépourvus d'intérêt. Mais sans exagérer non plus, si j'écris :

for ( int i = 0 ; ! i < v.size() && v[ i ] != cible ; ++ i ) {
}

je trouve l'algorithme assez évident qu'on peut très bien se passer du
commentaire du genre « implémente récherche linéaire » ou « invariante
de la boucle : i >= 0 , i < v.size(), v[ j ] != cible pour tout j >= 0,
j < i ».

En revanche, un commentaire qui explique *pourquoi* on a choisi un
vecteur et la récherche linéaire, plutôt qu'un std::set ou un vecteur
trié et la récherche dicotomique serait parfois utile. Si, par exemple,
je sais qu'en fait, v.size() ne serait jamais supérieur à 10, c'est
quelque chose que le code ne dit pas, et ça vaut la peine d'être dit.

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).


Le commentaires les plus intéressants sont :

- La spécification des classes : rôle, responsibilités, modèles de
conception, invariantes...

- La spécification des fonctions : pré- et post-conditions, conditions
d'erreurs, sémantique des paramètres et de la valeur de retour (bien
que les noms suffisent la plupart du temps pour ces deux derniers).

- Les commentaires sur ce que tu n'as pas fait. Voir ci-dessus : ce
qui est intéressant, ce n'est pas de dire que c'est une récherche
linéaire ; c'est évident que c'est une récherche linéaire. Ce qui
est intéressant, c'est pourquoi ce n'est pas une récherche
dicotomique, ou pourquoi tu ne t'es pas carrément servi de std::set,
étant donné qu'il faut trouver les éléments selon leur valeur. Le
code implique prèsque toujours des choix. On voit bien d'après le
code le choix que tu as fait. On ne voit pas pourquoi tu n'as pas
choisi l'un des alternatifs.

--
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


1 2