Ah, désolé. Mon post était purement informatif, je ne te prenais pas de haut.
Que veux tu dire ?
Utiliser le nom de l'objet avec celui de son namespace devant, en utilisant l'opérateur de portée « :: ».
M'enfin, c'est une lib à usage plutôt "interne" à plusieurs applis d'un projet
Et c'est très bien ! Mais justement, pour le coup, cela vaut le coup de la chiader un poil. En général, les listings des mes applications sont écrits au rythme de croisière normal (un minimum de commentaires, des fonctions implémentant ce dont j'ai besoin et rien d'autre), quand mes bibliothèques tentent, autant qu'elles le peuvent, de faire figure d'exemple :Toutes les indentations qui vont bien, tous les objets déclarés et initialisés proprement, un souci d'exhaustivité (si je fais une classe Rond, j'en profite pour faire la classe Carré à coté, et au final développer tout un toolkit de gestion de formes), un commentaire pratiquement à chaque ligne, disposés à la mode « assembleur » (le code à gauche, les commentaires à droite), etc. Et également :Une suite de tests. C'est probablement la partie la plus pénible à écrire, mais ô combien utile. On détecte toujours trois à quatre fois plus de bugs que l'on ne l'aurait estimé.
Certes, je mets beaucoup plus de temps à écrire une lib qu'une simple application, mais c'est un investissement car elle n'est en général plus à faire par la suite, et surtout, il ne manque plus grand chose à la fin pour pouvoir être diffusée dans le public comme projet open-source.
[^] # Re: Oubli
Posté par Obsidian . En réponse au message Déclencher et capturer une exception. Évalué à 3.
Ah, désolé. Mon post était purement informatif, je ne te prenais pas de haut.
Que veux tu dire ?
Utiliser le nom de l'objet avec celui de son namespace devant, en utilisant l'opérateur de portée « :: ».
M'enfin, c'est une lib à usage plutôt "interne" à plusieurs applis d'un projet
Et c'est très bien ! Mais justement, pour le coup, cela vaut le coup de la chiader un poil. En général, les listings des mes applications sont écrits au rythme de croisière normal (un minimum de commentaires, des fonctions implémentant ce dont j'ai besoin et rien d'autre), quand mes bibliothèques tentent, autant qu'elles le peuvent, de faire figure d'exemple :Toutes les indentations qui vont bien, tous les objets déclarés et initialisés proprement, un souci d'exhaustivité (si je fais une classe Rond, j'en profite pour faire la classe Carré à coté, et au final développer tout un toolkit de gestion de formes), un commentaire pratiquement à chaque ligne, disposés à la mode « assembleur » (le code à gauche, les commentaires à droite), etc. Et également :Une suite de tests. C'est probablement la partie la plus pénible à écrire, mais ô combien utile. On détecte toujours trois à quatre fois plus de bugs que l'on ne l'aurait estimé.
Certes, je mets beaucoup plus de temps à écrire une lib qu'une simple application, mais c'est un investissement car elle n'est en général plus à faire par la suite, et surtout, il ne manque plus grand chose à la fin pour pouvoir être diffusée dans le public comme projet open-source.