Salut à tous,

Comme certains de mes profs de l'année dernière nous ont bassiné avec leurs "vouiiiiii le code doit être élégaaaant"...

Pour vous, un code "élégant", c'est quoi ?

Deuxième question, je suis sur un projet perso assez conséquent en ce moment (générateur de particules C++ avec Qt&OpenGL). Je me pose une question en rapport avec cette fameuse élégance.

Le programme est structuré en classes évidemment...le problème est que je ne m'arrête pas au stade "composant minimum prêt à l'emploi", comme un DockWidget personnalisé.

Je vais plus loin. Exemple : j'ai codé un "Texture Browser" (une vue qui affiche les images d'un dossier). Absolument tout ce qui est relatif à ce truc est codé directement dans la classe. Je déclare une instance de "TextureBrowser" dans le header de "MainWindow", et c'est tout.Je ne touche pas au code d'un objet de type TextureBrowser dans MainWindow.cpp. A part peut-être un slot.

Chacun reste dans sa classe.

Alors, est-ce que cette manière de faire est élégante ? Pardon est-ce que cette manière ne va pas faire gueuler un développeur avec 20 ans dans le métier ?

Car dans certains exemples de Qt, une classe contient le minimum, le reste est codé dans la classe "principale", le plus souvent une MainWindow. Mais ma façon de procéder me permet de mieux structurer le soft, c'est plus clair quoi.

Je pense que certains se diront "bah il se prend vraiment la tête pour rien" mais bon
Voilà, merci à tous pour vos avis et contributions

Je pense qu'on a tous une idée particulière sur l'élégance du code. Mais je pense qu'on peut facilement trouver des lieux communs.
Pour moi un code élégant est un code que l'on peut lire facilement, sans structure alambiquée et sans grosse "complexité cyclomatique". Par conséquent, oublier les goto et variables globales ou externes, minimiser les break...
Faire des classes faiblement couplées, comme tu sembles le faire, aide a avoir un code élégant, où il n'est pas nécessaire de mettre le museau dans les implémentations de classe pour les comprendre (et encore moins pour les utiliser).
Mettre de la doc dans le code est bien aussi (style Doxygen ou javadoc, par exemple).
Perso, je n'ai jamais vu un codeur, avec 20 ans de métier ou non, râler après un code simple et efficace.

Moi je pense, que chacun a sa personnalité.
Et que chacun à sa façon de coder à lui.
Tant que ton code n'est pas ultra mal optimisé et qu'il fonctionne je ne vois pas le problème

Code élégant : tout les noms sont explicites (variables, membres et classes hors indicateur de boucle, sauf si celle-ci est "complexe").
Pas de GOTO (sauf s'ils sont justifiés), pas de documentation inutile, des commentaires supplémentaires dans les méthodes pour les passages un peu ardu, les hacks divers, les raisons de faire des choses qui ne paraissent pas logique au premier abord ...

Par "documentation inutile", j'entends quelque chose ça (exemple en Java) :
/**

• Getter of the people's age
• @return the age of the people
  • /

public int getAge(){return age;}

Pour ton exemple, je préfère découper les responsabilités des classes. Je préfère créer des classes faisant des choses, et d'autres qui les appels en invoquant les bonnes méthodes des premières.
Ainsi, le code permettant de réaliser et celui permettant de mettre en oeuvre sont différents, et si la mise en oeuvre doit changer, cela nécessite moins de changement.
De plus, dans le cas où la classe est utilisé à plusieurs endroits, cela permet de ne pas impacter les autres par effets de bord (une même classe).

@Gleuh : "Et que chacun à sa façon de coder à lui. "

En équipe, y'a rien de pire que la personne qui ne suit pas la norme, ou ne fait pas d'effort sur la forme pour être aisément compréhensible des autres.
J'en sais quelque chose, vu que mon code est une horreur à lire pour beaucoup d'autres . C'est pour ça que je le reformate selon la norme avant la mise en commun.

Y'a un aspect subjectif, mais faut aussi suivre des conventions de codage basiques, et s'efforcer d'avoir un code qui est clair et qui dévoile son fonctionnement au premier coup d'oeil, sauf si des optimisations complexes le justifie.
Apres le reste a été dit.

Parfois c'est vraiment subjectifs, certains diront que c'est de la merde alors que d'autre diront que c'est l'élégance même

Disons qu'aux premiers abords l'elegance en effet refere a quelque chose de tres subjectif, esthetique. Alors que ca n'a rien a voir.
Dans la pratique ca n'a pas grand chose a voir je dirais, comme l'a tres bien dit Bunyan je parlerais plutot de code propre et de code degueulasse. (Lire Effective C++ sur le sujet par exemple: The Holy Bible)

C'est un peu comme une recette de cuisine si tu veux, ma mere m'a toujours dit : "Etre un bon cuisinier c'est deja etre organise et soigne". Peu importe la qualite du plat final si a la fin t'as une cuisine dans le desordre, pas rangee et avec pleins de choses en trop qui sert a rien alors ton plat aura bon etre bon (e.g. ton code fonctionner), tes capacites en cuisine resteront tres amateurs.

• qui servent
• aura beau etre bon
• avec plein
• amatrices

Je dois bien te dire que je parlais d'évidemment en solo, c'est sûr que si quelqu'un fait un code illisible, même si fonctionnelle, ça n'aide pas beaucoup l'équipe ...

Pourquoi faire "élégant" ?

Quelle est l'utilité ? Exemples :
- Saura tu relire ton code dans un an ou plus pour le mettre à jour, le déboguer ou le faire évoluer ?
- une autre personne que toi serait elle capable de maintenir et faire évoluer ton code ?

Quel sont les moyens utiles pour attendre ce but ?

Gleuh, même sen solo, si un jour t'as un problème et que tu dois envoyer ton code a quelqu'un, même si toi t'arrive a le lire et que tu comprends très bien, c'est pas dis que l'autre aussi.

"Comme certains de mes profs de l'année dernière nous ont bassiné avec leurs "vouiiiiii le code doit être élégaaaant"...

Pour vous, un code "élégant", c'est quoi ? "

Pour moi un code élégant c'est :
- le strict minimum en nombre d'instructions pour accomplir une tâche
- une bonne séparation des concepts (une fonction fait une seule et unique tâche, pas deux ; une variable n'est pas réutilisée plusieurs fois avec des significations différentes ; une classe représente un seul et unique concept)
- un max de généricité (utilisation des interfaces et des templates dès que possible)
- des commentaires détaillant précisément TOUTES les fonctions exposées (façon Javadoc)
- le respect des conventions de nommage (par exemple en Java : une classe commence par une majuscule, une variable ou une fonction par une minuscule et les autres mots sont marqués chacun par une majuscule)

"- des commentaires détaillant précisément TOUTES les fonctions exposées (façon Javadoc) "

Je pense que c'est plutôt à éviter perso.

Javadoc le fait très bien pour ce genre de chose, mais en C++, non, je pense pas.

Large Scale C++ Software Design, John Lakos

La "beaute" du code au niveau textuel, ca ne sert pas a grand chose ; la "beaute" de l'architecture, en termes de flexibilite, modularite, maintenabilite, etc. c'est deja plus interessant.

on sait ce que c'est: on commence propre et ça deviens le bordel

La première chose qui me vient à l'esprit avec "élégant" c'est justement la "beauté" du texte, et non la complexité de l'architecture.

J'entends par "beauté" du texte qu'il n'y ai pas d'espaces inutiles, des accolades non alignées, des parenthèses inutiles et tout ce genre de chose

La beauté du texte j'appellerait plutôt ça la lisibilité...
En ce qui concerne l'élégance c'est très subjectif. C'est en partie pour ça qu'on a inventé les design patterns et UML je pense, pour mettre tout le monde d'accord et pouvoir travailler en équipe sans que chacun y aille de son élégance perso.

@Gleuh/Hello250

Par élégant on ne veut pas dire présentation du code mais bien élégance de la solution mise en œuvre. (Enfin dans mes études ainsi que dans les bouquins qui parlent de développement c'est comme ça en tout cas )

Que ça soit au niveau de la conception (exemple, préférer des dépendances vers des interfaces plutôt que des classes concrètes, préférer la composition à l'héritage) ou du codage en lui même (pas de break (sauf pour un switch évidement), d'algo inutilement compliqué ou pire, d'horreurs genre les exceptions pour faire du contrôle de flux normal).

Une indentation correcte où ce genre de chose, c'est sensé être obligatoire de toute façon, la base de la base, code crade ou pas. Mais c'est pas ça qui fait l’élégance.

Tu auras beau faire une indentation niquel et du texte bien présenté, si ton programme est mal conçu, c'est mauvais, point à la ligne.

Les codes donnés par le SDZ ont une indentation nickel et respectent les conventions de nommage, ça ne les empêchent pourtant pas d'être assez souvent du grand n'importe quoi.

Si vous voulez savoir ce que l'on veut dire par "code non élégant", vous trouverez quelques exemples (liste non-exhaustive) ici: http://www.odi.ch/prog/design/newbies.php#30

"- des commentaires détaillant précisément TOUTES les fonctions exposées (façon Javadoc) "

Tu veux dire quoi exactement par "détailler précisément"?

Normalement, la JavaDoc ne doit détailler que ce que FAIT la méthode, mais surtout pas COMMENT elle le fait, vu que le développeur risque d'être tenté d'adapter son code en fonction de ce "comment", du coup le jour où l'implémentation change, ça lui posera problème.

Cependant, pour répondre à LOKILOK:
"Je pense que c'est plutôt à éviter perso."

+1, cependant, il me semble que parfois, dévoiler certains détails d'implémentations à l’extérieur peut-être justifié. L'API java le fait sur certaines choses, en particulier sur les classes destinées à être héritées. (Vu qu'une classe qui hérite devient dépendante de l'implémentation de la classe mère.) Comme autre exemple, les collections en Java décrivent souvent leur utilisation interne des méthodes hashCode/equals/compareTo.

La lisibilite doit necessairement etre irreprochable, mais ca c'est une question de coding standards, pas de "beaute".

Debattre sur le format des commentaires en

//-----
// MyClassBidule
//-----

ou en

// ·····
// .oO : MyClassBidule : Oo.
// ·····

Ca ca par contre ca ne sert a rien. Un coding standard propre et minimaliste, si besoin il en existe plein, et on s'y tient. Ca n'est pas meme une question de "oui ou non", c'est une question de "quel standard".

La lisibilite c'est une chose, mais la "beaute" du code, c'est l'archi implementee, et la proprete de l'execution dans les details.

Ah tiens j'ai poste sous le mauvais compte ; erreur de ma part, c'est de LGV