Discussion :

[eldran64]

Bonjour à tous,

Comme une majorité de débutant , je viens de coder un programme de A à Z sans avoir préparé quoi que soit. Mon code fonctionne et tiens la route.

Mais mon code est surtout devenu un vrai foutoire!! Des fonctions dans tout les sens avec un algo alambiqué.

Bref, c'est pas la joie. Pour mettre un terme à tout cela, je souhaiterai mettre de l'ordre. Et c'est là que le bas blesse puisque j'ai aucune idée de par où commencé.

Si quelqu'un à une idée... cela me sauverai moi et mon code...

Merci pour vos commentaires!!!

[likoudA]

Bonjour,
Déjà, il faut commenter son code. Un bon programmeur doit bien commenter, c'est très important. Ensuite, je te conseille de créer plusieurs classes qui contiendront chacune un certain nombre de fonctions afin de séparer au maximum tes traitements et tes objets. Enfin, il y a un certain nombres de conventions à respecter, voir ici.
bonne chance.

[Philou67430]

Pour ce qui est du code, avant de le commenter, il convient de bien nommer les identifiants (variables, fonctions) : cela réduit d'autant la nécessité de longs commentaires.
Ensuite, les commentaires ne doivent pas simplement "traduire en français littéraire (ou en anglais, ce qui serait encore plus absurde)" le code qu'il explique, mais plutôt l'opération dans le monde réel qu'elle représente.
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# Boucler de 0 à $taille_base
for (i = 0 ; i < taille_base ; i++) ...

ne fournit aucune information, contrairement à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# Parcourir tous les utilisateurs de la base
for (i = 0 ; i < taille_base ; i++) ...

Mais le plus important avant de commenter et de bien nommer les variables, c'est de bien identifier les concepts sous-jacents à tes fonctions/structures de données et à les regrouper/recomposer de manière cohérente au sein de fonctions, modules, d'objets, de classes, ... Cela s'appelle parfois analyse, conception, ou encore modélisation. C'est généralement un préalable, mais cela peut être aussi la suite d'un prototypage (comme on pourrait qualifier ton programme actuel).

Exemple :
Dans ton application, tu disposes d'un tableau contenant des structures d'utilisateurs. Ton application doit mettre à jour le nombre et le temps de connexion d'un utilisateur en fonction de son login.
Tu auras écris une fonction : maj_nb_conn et une autre fonction maj_duree_derniere_conn qui chacune, prendra le login en paramètre (ainsi que des données annexes de traitement).
Dans chacune de ses fonctions, tu réalises la recherche dans la table des structures, de la structure pour le login donné, puis tu réalises l'opération de mise à jour (respectivement du nombre de connexion et de la durée de la dernière connexion).
On voit qu'il y a ici redondance : la recherche dans la table est écrite deux fois. Ce n'est pas très propre, car si la structure la table change, il y a fort à parier qu'il faudra modifier les deux fonctions. Par ailleurs, on peut se dire que la table des utilisateurs est une notion suffisamment importante dans le programme pour qu'elle dispose de son propre module (ou de sa propre classe en modélisation objet), et ainsi, de séparer le traitement de la table des utilisateurs de celui des connexions/déconnexions.
Ainsi, les nouvelles fonctions maj_nb_conn, et maj_duree_derniere_conn se concentreront sur le traitement de la connexion et relègueront la mise à jour de la table d'utilisateurs à un autre module/une autre classe.

[nbenbourahla]

Bonjour

Voici quelques règles que j'applique personnellement, ses règles je les ai apprise dans mon école d'informatique, et finalement je les appliques meme en dehors et je trouve que c'est une bonne chose

- Commenter tes fonctions
- Fixer une limite de taille par fonction (par exemple en C je fais en sorte qu'aucune fonction ne dépasse 25 lignes)
- Limiter le nombre de fonction par fichier (a par en objet bien sur lol)
- Espacer un peu tes fonctions
- Mettre toujours tes déclarations de variable au début des fonctions (a par nécessite) car je trouve sa moche plein de variable au milieu du code alors qu'on pourrait bien les mettre au début
- Espacer ton code
...

Après tu peux t'imposer toi même d'autre regle pour que ton code soit propre et compréhensible pour une autre personne

De rien
Bonne continuation

[Philou67430]

- Mettre toujours tes déclarations de variable au début des fonctions (a par nécessite) car je trouve sa moche plein de variable au milieu du code alors qu'on pourrait bien les mettre au début

Je ne suis pas d'accord avec cette règle : lorsque c'est possible (C++, car en C, ce n'est pas toujours possible), je préconiserais plutôt de déclarer les variables au plus près de leur utilisation, et ce pour plusieurs raisons :
- éviter les effets de bord en limitant au maximum la portée d'une variable
- pour rendre "lisible" cette déclaration lorsque l'on lit le code qui l'utilise (notamment pour voir son type et sa valeur initiale).

[Mac LAK]

Je ne suis pas d'accord avec cette règle : lorsque c'est possible (C++, car en C, ce n'est pas toujours possible), je préconiserais plutôt de déclarer les variables au plus près de leur utilisation, et ce pour plusieurs raisons :
- éviter les effets de bord en limitant au maximum la portée d'une variable
- pour rendre "lisible" cette déclaration lorsque l'on lit le code qui l'utilise (notamment pour voir son type et sa valeur initiale).

Si c'est dans une boucle simple, et exclusivement pour son indice, éventuellement. Sinon, c'est un beau nid à bugs introuvables, notamment et surtout par masquage d'une variable existante...



Sinon, pour un code propre :
- Commenter intelligemment : un commentaire qui décrit le code, ça ne sert à rien, on n'est pas idiots et on sait lire du code... L'exemple de Philou67430 est très significatif.
- Indenter de façon régulière : respecter une indentation constante dans le projet, et non pas un coup avec 2 espaces, un coup sans, un coup une tabulation, etc...
- Quelle que soit la norme de codage que tu appliques, suis-la SANS EXCEPTIONS.
- Modulariser son code, mais éviter les dépendances façon "poulpe plein de tentacules". Si chaque fonction que tu implémentes dépends de dizaines d'autres fonctions plus ou moins interdépendantes, tu vas créer un code tentaculaire difficile à maintenir et à comprendre.
- Éviter les lignes vides "pour rien", tout comme les fonctions trop longues ou les blocs inutilement éclatés.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
if (condition)
{
	variable = valeur1 ;
}
else
{
	variable = valeur2 ;
}

Ceci est très laid, ça prends une place infernale à l'écran, et ça nuit plus à la lisibilité qu'autre chose...
Une version plus lisible est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (condition)
	variable = valeur1 ;
else
	variable = valeur2 ;

Déjà plus compact, tout aussi lisible... Et, dans le cas précis qui nous occupe, on a encore mieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

variable = (condition) ? (valeur1) : (valeur2) ;

Il ne faut certes pas exagérer sur les opérateurs ternaires, mais il ne faut pas non plus les rejeter pour rien.
Ceci étant dit, il faut quand même éviter ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(condition1) ? (variable1) : (variable2) = (condition2) ? ( (condition3) ? (valeur1) : (valeur2)) : ( (condition4) ? (valeur3) : (valeur4)) ;

Certes, c'est du code "légal", mais c'est pas facile à suivre...

[Philou67430]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (condition)
	variable = valeur1 ;
else
	variable = valeur2 ;

De nombreux recueils de règles de codage interdisent cette construction sans bloc, source de bug potentiel lors d'une maintenance.

Je ne veux pas lancer une polémique sur l'usage des accolades, mais pour une bonne lisibilité, je préfère utiliser cette forme de bloc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if (condition) {
  variable = valeur1;
}
else {
  variable = valeur2;
}

qui permet de "gagner" en hauteur, sans perdre en lisibilité. L'autre avantage est que la condition est située juste au dessus du traitement (l'accolade ouvrante n'apportant guère d'information étant donné que l'indentation de la ligne suivante indique clairement qu'un bloc à démarré).

[Philou67430]

Ceci étant dit, il faut quand même éviter ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(condition1) ? (variable1) : (variable2) = (condition2) ? ( (condition3) ? (valeur1) : (valeur2)) : ( (condition4) ? (valeur3) : (valeur4)) ;

Certes, c'est du code "légal", mais c'est pas facile à suivre...

Attention, l'usage d'une expression conditionnelle est tant que lvalue est obsolète :

gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
a.c: In function `main':
a.c:3: warning: use of conditional expressions as lvalues is deprecated

[Mac LAK]

Tant qu'à ajouter des accolades "de force", je préfère cette syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if (condition) {
  variable = valeur1;
} else {
  variable = valeur2;
}

Une ligne en moins... C'est du moins la syntaxe que j'utilise en blocs multilignes.
Toutefois, dans le cas de blocs constitués d'une seule ligne, je trouve au contraire que ça alourdit le code : l'absence d'accolades permet, justement, de voir que c'est un traitement "simple"...

Toutefois, j'ai tendance à considérer que si un programmeur indente correctement, et qu'il est assez idiot pour rajouter des instructions dans un "bloc" sans en vérifier les bornes, faudrait qu'il envisage de changer de métier... S'il n'indente pas, il est URGENT qu'il change de métier...

Faut pas pousser non plus : s'il faut toujours faire les programmes (et les normes de codage) de façon à ce que le débutant lambda et/ou les non-informaticiens arrivent à suivre, on ne s'en sort pas... Ce sont quand même des "professionnels" qui sont censés tripoter le code, donc des gens qui ont des notions fondamentales comme les blocs, la portée, etc. !

Si c'est un débutant pur jus, il est censé avoir de bonnes bases d'algorithmique, et connaitre au minimum la syntaxe du langage... Si c'est le cas, il ne tombera pas dans le "piège". Si ce n'est pas le cas... alors avant de "coder proprement", il faudrait penser à "apprendre proprement", tu ne crois pas ?

Attention, l'usage d'une expression conditionnelle est tant que lvalue est obsolète :

De nombreux compilateurs acceptent ce genre de construction, notamment des compilateurs spécifiques (pour microcontrolleurs notamment)... De plus, cela reste un "simple" warning, et juste un deprecated qui plus est. Je prends les paris qu'il sera résolu dans 90% des cas en décochant l'affichage du warning en question...
Toutefois, je le re-dis, les imbrications d'opérateurs ternaires (avec ou sans L-values) sont à éviter le plus possible.

Râler sur UN opérateur ternaire en R-Value, c'est ne pas savoir lire un code. Râler sur une imbrication de 3 ou 4 OT, c'est avoir envie d'un code maintenable...