Discussion :

[Invité]

Pourquoi n'a t'on pas le fait de savoir écrire correctement en français et en anglais ?

C'est pourtant important pour le nommage des méthodes, variables, écrire une documentation concise et précise ...

[Bubonik software]

Si le développeur aime son métier (comme le disait zecreator) et code en gardant à l’esprit les besoins et contraintes de son client (un peu comme le disait leternel), je pense que c’est déjà beaucoup. Bien sûr, il faut aussi qu’il sache (au moins un peu) coder, débuguer, documenter, expliquer, simplifier, tester, optimiser…

[Pierre Fauconnier]

Au vu de certaines discussions, notamment sur le forum VBA Excel, je dirais qu'une qualité d'un programmeur, c'est de pouvoir se remettre en question lorsqu'on lui met le nez dans son caca parce qu'il a codé comme un goret

[djames]

Je préciserais dans la liste proposée :
- écrire du code lisible et compréhensible

=> notamment des noms de variables longs et explicites

- écrire du code simple

=> notamment découper en fonctions à mono responsabilité

Je rajouterais cette petite technique efficace :
- avant d'écrire le code, écrire en commentaire l'algorithme en pseudo code

=> cela permet d'économiser pas mal de retouches, de trouver des optimisations à l'avance et à la fin on a déjà les commentaires

Quand c'est possible
- relire et se faire relire

=> on découvre chez les autres ou chez soi des bonnes/mauvaises pratiques qu'on ne voit pas tout seul

- utiliser un framework qui 'impose' de bien coder (ex: angular en js)


Par contre je suis plutôt réservé sur :
- écrire des tests unitaires

=> dans la pratique trop long à maintenir.

- veille technologique

=> attention à ne pas tomber dans le travers d'utiliser des technos pas assez mûre et de se retrouvé planté

[champy]

Surtout varier ces développements et ces langages quitte à la faire chez soi.

Faire de la POO pendant 10 ans et passé de force au JavaScript (bas oui tu comprends l'application est desktop mais faut la faire en web) sa en déroute beaucoup qui ne peuvent plus remettre en cause les paradigmes de programmation qu’ils ont appris et tenterons coûte que coûte de les reproduire avec les conséquences que l'on connait (la création de FrameWork perso pour faire de la POO en JavaScript, l'horreur absolue).
Exemple criant de vérité lorsque l'on lit les joutes emballées POO vs JS présente sur ce site
L'inverse est vrai aussi un développeur JavaScript qui se met au C aie, aie, aie ça fait mal.

Le point le plus délicats pour moi c'est le chiffrage, bien chiffré son projet c'est avoir pris conscience de tous les pans de l’application, cahier des charges, analyse, développement, technologies utilisées, migration de données, commentaire, guide utilisateur, intégration dans l'usine logiciel, et j'en passe. Le problème étant que ton chiffrage tu dois le faire vite, souvent à l'oral, alors qu'il faudrait presque faire une maquette pour ce rendre réellement compte de tous se qu'implique le projet. Je pense que je vais finir par chiffrer le chiffrage

Car derrières, on a les décideurs et leur dead line commerciale qui de toute façon ont été décidé avant ton chiffrage
Toujours envoyer un chiffrage par mails pour pouvoir rétorquer quand on te dit 'ce n’est pas finit !! Mais c'est déjà vendu !!!' , 'bas il y a encore 6 mois de développement dans le chiffrage'

Les tests, LE sujet, anecdote récente, personne ne fait de TDD dans notre équipe en fait je suis le seul à faire des tests, je développe tous ce qui est Web et il faut bien avouer que du Web sans test c'est la catastrophe (je parle de grosse WebApps pas de site E-Commerce ou autre WordPress).

On développe un gros projet de gestion de patrimoine autoroutier orienté SIG (état des ponts, de la chaussée, camion de patrouille en live sur la carte, indicateur de performance , gestion de la maintenance, des incidents, des interventions ... ), les décideurs vendent, je chiffre les modules , et un mois après on me dit , on vas faire de la qualité , on vas développer tous les modules en TDD et bien multiplie le chiffrage par 4, je suis le seul à avoir une culture du test (pour développer des tests notamment unitaire le code doit être orienté, finit les méthodes qui font 50 trucs même pour l’algorithme) , du coup abandon du TDD pour les premiers modules (et à mon avis pour les suivant)

Mais quand je lis sa

Ils ne garantissent pas de la qualité du code, et n'empêchent en rien la présence de bugs.

et tu le sort comment ton indicateur qualité (ou alors tu le sort pas du tout, quand même pas !) ?
A la limite en étant très (trop) pragmatique et uniquement sur des Dead line ultra serré pas de test lors du développement (je sais ce n’est pas bien mais pas le temps) en revanche au premier bug, test de non régression OBLIGATOIRE car la résurgence d'un bug déjà corrigé est ce qu'il y a de pire pour l'expérience utilisateur.

Par contre tout le monde parle de test unitaire, c'est bien, mais pour moi les tests fonctionnels doivent être privilégié, ils sont beaucoup moins chronophage et peuvent être ajouté à un projet sans modifier le code.

Pour les commentaires, je me rappelle de cette époque :

Code :

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

1
2
3
4
5
/// <summary>
/// Chaine de connexion pour se connecter à la base de données
/// </summary>
public String ConStr { get; private set; }

Qu'est-ce que sa servait à rien, ha si aucun Warning pendant la génération de la documentation

Maintenant je ne documente que ce qui as besoin de l’être, les algorithmes, les interactions internes et externes, mais surtout je nomme beaucoup mieux mes variables.
Je me fiche de l’orthographe une collection ou un tableau prend toujours un s, j'utilise du Franglais volontairement quand la notion métier derrière la variable est plus difficile à comprendre en anglais.
Bon c'est un peu de la vengeance j'ai brûle mon bled après le collège.

L'autre pan certainement le plus important les relations humaines , cela vas du respect de ses collègues ,aider les gens moins compétent mais sans leur reprocher leur lacune (car on as tous des lacunes), communiquer sur ce que l'on fait et demander aux autres ce qu'il font pour mutualiser le tout , garder à l'esprit que tu dois transmettre aussi des compétences métier et pas uniquement informatique.

Mais surtout savoir être intraitable avec ta direction (en restant courtois et intelligent), c'est ton job, il ne connaisse pas la programmation (je bosse dans un grand groupe) et planifierons les livraisons sur des besoins commerciaux si tu ne leur dit rien, il ne faut pas hésiter et ne pas se sentir inférieur (le complexe col blanc col bleu est à bannir)

Exemple : sa doit être compatible IE6 pour cibler le plus de client possible tu comprends on cible l’internationale, la tu dis non et tu proposes une prestation de migration vers au moins IE X (même irréaliste) dans leurs yeux les dollars brillent, le client refuseras peut être car son parc d'application à besoin d'IE6 mais ça c'est plus ton problème, ça devient le leurs

[Invité]

et tu le sort comment ton indicateur qualité (ou alors tu le sort pas du tout, quand même pas !) ?

Les outils d'intégration continue sont là pour ça (Jenkins, sonar...).

Et je maintiens qu'un dev qui sache pas écrire sans faire une faute tous les deux mots est un problème, n'en déplaise à certains.

[George W. Bush]

Je suis d'accord avec la première moitié de la liste. Cependant, j'aurais aimé voir :

.) Considérer la robustesse d'une application comme une priorité.

.) De flexibilité de code. (MVC, N-Tier, ne pas etre oubligé de tout réécrire de A-Z, et tout d'un coup, si l'on change d'interface, de DB, de plateform.)

.) De capacité a produire des solutions avec une grande durée de vie.

.) De globalisation. (combien de fois j'ai vue des solutions pour grande entreprise, avec du hard-codage, des centaines de fichiers de parametres pelle-mèles, des shares qui pointent n'importe ou, rendant la solution très difficile a administrer)

.) De gestion des erreurs. (trop souvent minimisé, et implenté en fin de projet, plutot qu'en début)

Au plaisir,
Voila.

[popo]

et tu le sort comment ton indicateur qualité (ou alors tu le sort pas du tout, quand même pas !) ?

Les outils d'intégration continue sont là pour ça (Jenkins, sonar...).

Et bien justement, sonar, pour ne citer que lui mesure une partie de l'indicateur qualité avec le code coverage.

Mon nouveau test sert à garantir que le bug est bien corrigé et les tests déjà existants m'assurent que je n'ai rien cassé ailleurs.

Il ne garantit en rien que tu ais écrit un code de qualité, intelligent et que tu ais réellement couvert toutes les situations.
Le test par un tiers avec de l'intégration continue restent très efficaces.

En effet, il ne garantissent en rien la qualité du code. Mais j'ai également évoqué SRP et le nommage entres autres, qui même s'il ne font pas tout permettent néanmoins d'améliorer les choses.
Quand a couvrir toute les situations, c'est justement le rôle du test unitaire... quand un cas n'est pas couvert, on écrit un nouveau test, on corrige et se base sur les tests existant pour la non régression. Après si pour une même fonctionnalité, il y a trop souvent un nouveau cas de bug découvert, c'est un bon indicateur pour savoir que soit l'analyse ne correspond pas au besoin (bref qu'on a pas compris ce qu voulais le client), soit qu'elle a été baclée. Dans les deux cas il faudra revoir le client. Et en passant, le test effectué par un tiers non plus ne garantit ni la qualité du code ni la couverture de tous les cas. Si un cas a été oublié dans l'analyse, ce cas sera oublié aussi bien dans les tests unitaires, que dans les tests manuels ou par les robots de tests.

Pyramidev, il y a de nombreuse manières d'éviter un commentaire.
Pour ton exempler avec "FaireUnTrucA, FaireUnTrucB". Il suffit de déclarer ces méthodes en dessous de uneFonction, il aura tout directement sous les yeux.
Pour le cas des chaines de format je suis d'accord qu'un commentaire peut être utile. Quoique, certain diraient qu'on peux également renvoyer une exception et expliquer le format à l'intérieur.
Pour le findIndex, là je ne suis pas d'accord. En règle général, il existe déjà de telles méthodes dans le framework ou dans les librairies et les développeurs savent que ce genre de méthodes est sensée renvoyer l'indice de l'élément à partir de 0, ou -1 si non trouvé.
Pour le findElement, là encore, je ne suis pas d'accord. Ton Objet est dépendant d'un autre qui a potentiellement sa vie propre et tu n'ai pas en mesure de garantir sa longévité. Pour moi cette classe ne respecte ni principe d'encapsulation, ni le SRP. Il te faut une classe dédiée pour la gestion des configurations, une classe qui contiendra sa propre liste et dont la méthode findElement renverra une copie de l'item.

[Invité]

Et bien justement, sonar, pour ne citer que lui mesure une partie de l'indicateur qualité avec le code coverage.


En effet, il ne garantissent en rien la qualité du code. Mais j'ai également évoqué SRP et le nommage entres autres, qui même s'il ne font pas tout permettent néanmoins d'améliorer les choses.
Quand a couvrir toute les situations, c'est justement le rôle du test unitaire... quand un cas n'est pas couvert, on écrit un nouveau test, on corrige et se base sur les tests existant pour la non régression. Après si pour une même fonctionnalité, il y a trop souvent un nouveau cas de bug découvert, c'est un bon indicateur pour savoir que soit l'analyse ne correspond pas au besoin (bref qu'on a pas compris ce qu voulais le client), soit qu'elle a été baclée. Dans les deux cas il faudra revoir le client. Et en passant, le test effectué par un tiers non plus ne garantit ni la qualité du code ni la couverture de tous les cas. Si un cas a été oublié dans l'analyse, ce cas sera oublié aussi bien dans les tests unitaires, que dans les tests manuels ou par les robots de tests.

Pyramidev, il y a de nombreuse manières d'éviter un commentaire.
Pour ton exempler avec "FaireUnTrucA, FaireUnTrucB". Il suffit de déclarer ces méthodes en dessous de uneFonction, il aura tout directement sous les yeux.
Pour le cas des chaines de format je suis d'accord qu'un commentaire peut être utile. Quoique, certain diraient qu'on peux également renvoyer une exception et expliquer le format à l'intérieur.
Pour le findIndex, là je ne suis pas d'accord. En règle général, il existe déjà de telles méthodes dans le framework ou dans les librairies et les développeurs savent que ce genre de méthodes est sensée renvoyer l'indice de l'élément à partir de 0, ou -1 si non trouvé.
Pour le findElement, là encore, je ne suis pas d'accord. Ton Objet est dépendant d'un autre qui a potentiellement sa vie propre et tu n'ai pas en mesure de garantir sa longévité. Pour moi cette classe ne respecte ni principe d'encapsulation, ni le SRP. Il te faut une classe dédiée pour la gestion des configurations, une classe qui contiendra sa propre liste et dont la méthode findElement renverra une copie de l'item.

C'est tout l'intérêt de faire appel à un tiers - n'ayant pas de lien direct avec ton dev - pour tester. Le défaut récurrent chez le dev étant lors de ses tests de ne pas se mettre dans la peau d'un utilisateur "lambda".

Les tests unitaires peuvent être intéressants pour garantir l'intégrité de données, mais le test unitaire technique à tout va non, non et encore non.
C'est très long, fastidieux, c'est lourd.

Plutôt que de sauter et de se rassurer avec le tout test unitaire technique, on a plus intérêt à se concentrer sur la maitrise réelle du langage tout en appliquant les bonnes pratiques. L'impact est bien plus important sur la qualité intrinsèque et plus globale.

[Pyramidev]

Il te faut une classe dédiée pour la gestion des configurations

Pourrais-tu développer ce point ?

Je vais prendre le scénario suivant :
Une certaine configuration est lue en début de programme depuis un fichier (s'il n'existe pas, le fichier est créé).
En cours d'exécution du programme, la configuration peut changer suite à des actions de l'utilisateur.
Lors d'une sauvegarde, la configuration est sauvegardée dans le fichier.

Pour implémenter cela en C++, j'ai pensé à la solution suivante :
Vers le début du programme, je construis un objet de type Config qui représente le contenu du fichier.
Ensuite, en cours d'exécution du programme, dans les objets que je construis dont le comportement dépend de la config, je sauvegarde dans chaque objet un handler qui permet d'accéder à l'objet config en lecture, par exemple un const Config& ou un std::reference_wrapper<const Config>. D'où mon exemple :

Code :

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

1
2
3
4
/*!
 * \param config Cet objet doit exister tant que Foo existe.
 */
Foo(const Config& config);

Quand la config sera modifiée, la prochaine fois que Foo lira la config, il lira la config à jour.
En fin de programme, je laisse se détruire tous les objets encore vivants qui lisaient la config.
Ensuite, je laisse cet objet de type Config se détruire.
(En C++, dans pas mal de cas, les objets sont détruits dans l'ordre inverse de leur création.)

Remarques :

• Pour respecter le principe de la ségrégation d'interface (ISP), Config pourrait hériter de différentes petites interfaces.
  

  Code :

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

  1
  2
  3
  4
  /*!
   * \param config Cet objet doit exister tant que Bar existe.
   */
  Bar(const InterfaceImplementeeParConfig& config);

  Je n'ai pas trop insisté dessus pour que l'exemple reste simple. De toute façon, ça ne change pas la gestion de la mémoire.
• Dans chaque objet, j'aurais pu mettre un std::shared_ptr<const Config> qui gère la mémoire de l'objet via un comptage de références. Le dernier qui n'utilise plus la config se charge alors de la détruire. En plus, cela évite de documenter à propos de la gestion de la mémoire. Mais cette solution me semble inappropriée dans cet exemple car je sais déjà quand l'objet de type Config devra être détruit. Ici, le comptage de références serait un surcoût inutile.

[popo]

C'est tout l'intérêt de faire appel à un tiers - n'ayant pas de lien direct avec ton dev - pour tester. Le défaut récurrent chez le dev étant lors de ses tests de ne pas se mettre dans la peau d'un utilisateur "lambda".

Je suis d'accord pour dire qu'un développeur n'arrive pas souvent à se mettre dans la peau d'un utilisateur lambda.
Il n'empêche que quelque soit le tiers qui teste, celui-ci va se baser sur l'analyse pour savoir si un cas qu'il rencontre est correct ou non.
Si ce tiers tombe sur un cas non prévu, il va le dire au dire au développeur (et si je suis ce développeur, je fais d'abord écrire une méthode de test avant de corriger).
Relis bien, je n'ai écrit nulle part qu'un test fonctionnel est inutile, c'est toi qui a interprété.
Evidemment que les tests fonctionnels sont important puisque, justement, ils permettent de lever les loups que le développeur n'a pas vu.

Les tests unitaires peuvent être intéressants pour garantir l'intégrité de données, mais le test unitaire technique à tout va non, non et encore non.
C'est très long, fastidieux, c'est lourd.

Si faire un test unitaire est fastidieux et/ou lourd, cela signifie en général que le code de production l'est également.
Comme le dis si bien ddoumeche :

Mais les test unitaires :
•ne sont pas plus long à écrire que de déboguer son code a la main
•m'obligent a conserver une architecture simple et testable
•me font détecter rapidement les régressions
•surtout s'ils sont fait automatiquement
•permettent d'éviter qu'un nouveau venu ne casse tout en voulant bien faire

Plutôt que de sauter et de se rassurer avec le tout test unitaire technique, on a plus intérêt à se concentrer sur la maitrise réelle du langage tout en appliquant les bonnes pratiques. L'impact est bien plus important sur la qualité intrinsèque et plus globale.

ça fait deux fois que tu me sors l'argument du "tout tester unitairement ne suffit pas".
Et donc, ça fait deux fois que je constate que tu ne prends pas le temps tout lire. Je ne prendrai donc pas la peine de tout réécrire.

Il te faut une classe dédiée pour la gestion des configurations

Pourrais-tu développer ce point ?

Je n'ai jamais fait de C++ donc je ne sais pas si cela représente une difficulté ou non.
En tout cas, je pensais à simple singleton encapsulant l'objet Config.

[Pyramidev]

En tout cas, je pensais à simple singleton encapsulant l'objet Config.

En effet, c'est une autre solution.
Je ne suis pas un grand fan des singletons, mais c'est vrai que ça marche.

Pour ton exempler avec "FaireUnTrucA, FaireUnTrucB". Il suffit de déclarer ces méthodes en dessous de uneFonction, il aura tout directement sous les yeux.

Je modifie légèrement l'exemple. Je vais prendre le cas particulier de Java :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public void uneFonction()
{
    Foo foo1 = null;
    Foo foo2 = faireUnTrucA(foo1);
    Bar bar1 = null;
    Bar bar2 = faireUnTrucB(bar1);
    faireUnTrucC(foo1, foo2, bar1, bar2);
}
private final Foo faireUnTrucA(Foo foo1)
{
   foo1 = du code
   du code
   du code
   return du code
}
private final Bar faireUnTrucB(Bar bar1)
{
   bar1 = du code
   du code
   return du code
}
private final void faireUnTrucC(Foo foo1, Foo foo2, Bar bar1, Bar bar2)
{
   du code
   du code
   du code
   du code
   du code
}

Je pense que le même bout de code sera plus lisible et plus commode à maintenir sous cette forme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public void uneFonction()
{
    // faire un truc A
   Foo foo1 = du code
   du code
   du code
   Foo foo2 = du code

    // faire un truc B
   Bar bar1 = du code
   du code
   Bar bar2 = du code

    // faire un truc C
   du code
   du code
   du code
   du code
   du code
}

Les autres inconvénients qui me viennent à l'esprit sur le code avec les fonctions faireUnTrucX ne sont pas vrais pour tous les langages.

Par exemple, en C++, le temps de recompilation risque d'être en moyenne plus long dans la solution avec les fonctions faireUnTrucX membres de la classe.
En C++, souvent, on déclare les fonctions dans un fichier ".h" et on les implémente dans un fichier ".cpp". Alors, il y a de fortes chances que les fonctions membres faireUnTrucX soient déclarées dans le ".h".
Quand on ne modifie qu'un fichier ".cpp", pour recompiler le projet, on a juste besoin de recompiler ce ".cpp". Par contre, quand on modifie un ".h", il faut recompiler tous les ".cpp" qui incluent, directement ou indirectement ce ".h", ce qui est plus long.
Dans la solution avec les fonctions membres faireUnTrucX, si on modifie le nom ou la liste des paramètres d'une des fonctions membres faireUnTrucX, il faut modifier sa déclaration dans le ".h", donc modifier le ".h".
Dans l'autre solution, par contre, on ne fait que changer le code de uneFonction dans le ".cpp".

[olibiobus]

Un code est de bonne qualité si et seulement s'il est Bien commenté !
Avant même d'écrire le code, je le commente; cela a trois avantages:
1) éviter des oublis, préparer le futur codage
2) permettre la mise à jour plus facile du code y compris par un autre développeur
3) entrer rapidement et de façon globale dans un code, ce qui facilite les optimisations si nécessaire

[popo]

Pyramidev.
Encore une fois, je ne connais pas le C++ alors je me trompe peut être.
Est-ce qu'on est obligé de déclarer chacune des fonctions dans le fichier .h ?
L'idée est de déclarer uniquement les méthodes publiques dans le fichier .h et de découper dans le fichier .cpp
Comme une interface (c'est du Delphi cette fois) :

Code Delphi :

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

1
2
3
4
5
6
7
8
9
10
11
12
IMyInterface = interface
['{D653EBB8-78FD-4F69-A771-B659449A4872}']
  procedure UneMethode;
end;
 
TConfigurationSerializer(TInterfacedObject, IMyInterface)
private
  procedure FaireUnTrucA;
  procedure FaireUnTrucB; 
public
  procedure UneMethode;
end;

Un code est de bonne qualité si et seulement s'il est Bien commenté !
Avant même d'écrire le code, je le commente; cela a trois avantages:
1) éviter des oublis, préparer le futur codage
2) permettre la mise à jour plus facile du code y compris par un autre développeur
3) entrer rapidement et de façon globale dans un code, ce qui facilite les optimisations si nécessaire

C'est tout le contraire selon moi, un code de bonne qualité est un code où tout est limpide sans avoir besoin de commentaires
1) Pour préparer le futur codage on a jamais fait mieux que le papier et le crayon (et les commentaire n'empêchent pas les oublis). Le mieux est de le mettre au propre pour les futurs collègues qui reprendront le code (y compris nous même).
2) La plupart des développeurs effectuant de la maintenance ou une correction vont modifier le code, voire le déplacer, et en grande majorité (en tout cas c'est ce que j'ai pu constater) le commentaire restera tel quel. On aboutit à un commentaire complètement hors de propos à l'endroit où il est resté et ça ne facilite pas vraiment les choses.
3) Se reporter à mon commentaire 1. Car si ce document existe et qu'il est facile d'accès, le prochain développeur n'aura aucun mal à s'y retrouver.

[DonQuiche]

Encore une fois, je ne connais pas le C++ alors je me trompe peut être.
Est-ce qu'on est obligé de déclarer chacune des fonctions dans le fichier .h ?
L'idée est de déclarer uniquement les méthodes publiques dans le fichier .h et de découper dans le fichier .cpp

Oui et non. Toute fonction doit avoir été déclarée avant d'être appelée.

Tu peux à la rigueur organiser l'ordre des fonctions dans ton cpp pour éviter d'avoir une déclaration redondante (en imposant un ordre de lecture du bas niveau vers le haut niveau), ou tu peux placer la déclaration en haut du cpp plutôt que dans le header. Mais tu es quand même en général obligé de te farcir des déclarations distinctes à cause de ce modèle de compilation anachronique, datant d'une époque où l'AST ne pouvait pas tenir en mémoire.

Coder en C++ c'est comme se faire un gang-bang dans une maison de retraite : ça sent la naphtaline et tu risques de contracter une saleté.

[foetus]

Pour préciser ce que dit DonQuiche , on peut effectivement mettre des "forward declarations" en premier/ haut dans son fichier source .cpp.
Et ensuite, coder leurs définitions où on veut dans ce fichier.

Et une autre méthode qui fonctionne avec les fonctions/ procédures mais pas avec une classe/ méthodes.
On peut faire 2 entêtes .h: une XXX.h et une XXX_private.h

Dans l'entête XXX.h on place tout ce qui est public.
Dans l'entête XXX_private.h, on fait un #include "XXX.h" et on y ajoute tout ce qui est privé

Et dans le source XXX.c on fait un #include "XXX_private.h"

[Pyramidev]

Dans un programme, les commentaires qui me semblent les plus importants sont ceux qui décrivent, pour chaque classe, en quelques lignes, quel est le rôle de cette classe dans le programme. Quand un nouveau développeur débarque sur le projet, ça lui permet d'être moins perdu les premiers temps.

Est-ce qu'on est obligé de déclarer chacune des fonctions dans le fichier .h ?
L'idée est de déclarer uniquement les méthodes publiques dans le fichier .h et de découper dans le fichier .cpp

Dans ce cas, une solution est d'utiliser la méthode dite du pointeur opaque / de l'idiome pimpl.
En gros, on a une classe FooImpl qu'on déclare et qu'on définit entièrement dans Foo.cpp.
Dans Foo.h, on définit une autre classe, Foo, qui ne contient qu'un pointeur vers FooImpl et des méthodes publiques. Dans Foo.cpp, on définit ces méthodes de Foo.
Alors, chaque fois qu'on touche à un détail d'implémentation, on n'est pas obligé de toucher à Foo.h. Pour le temps de recompilation, c'est super.
Mais le code est un peu plus lourd à écrire et il y a un petit coût supplémentaire à l'exécution car on a ajouté une indirection entre les méthodes de Foo et les données. Donc la méthode dite du pointeur opaque n'est pas systématiquement utilisée en C++.

[zulad]

Je crois que le café n'est pas si bon que ça pour un développeur quand il prend une pause. Par contre, je pense que dans ce métier on se doit de faire plus de pause que dans d'autres...

[progfun]

Lorsque je développe un logiciel, je ressens toujours une grande satisfaction lorsque j'écris des procédures qui peuvent s'appliquer à presque n'importe quel logiciel. Bien sût cette universalité est relative au champ d'application. Par exemple une procédure pour la gestion de l'affichage à l'écran peut être utilisée dans n'importe quel logiciel dans les capacités limites de cet affichage. Les procédures souvent universelles sont des solutions mathématiques. Mais les procédures en lien avec la réalité humaine comme la gestion et l'administration sont plus difficiles à rendre universelles car il y a tellement de possibilités, et souvent on arrive pas à tout prévoir au moment de la conception. Quoiqu'il en soit, construire des procédures le plus universelles possibles est l'une des caractéristiques qui contribuent à faire de la programmation un outil puissant.

[Saverok]

Quoiqu'il en soit, construire des procédures le plus universelles possibles est l'une des caractéristiques qui contribuent à faire de la programmation un outil puissant.

Si et seulement si tu références tes procédures "universelles" dans une API que tu peux importer facilement dans un autre projet.
Sinon, je trouve que c'est se prendre la tête pour pas grand chose.

Par expérience, j'ai rarement eu besoin de coder ce genre de procédure car elles existent souvent déjà.
Note : je bosse en Java et vu le nombre de framework existants, c'est vraiment rare de trouver une fonction générique jamais développée ailleurs.