J'ai développé il y a quelques années avec Microsoft Visual C++ (4,5) et
Borland C++ (4.5,5.02) et me suis arrété sur Borland ayant constaté des
choses pas trés catholiques dans le compilateur de microsoft (surtout son
environnement standard). Aujourd'hui le compilateur et surtout l'IDE (que je
trouvais trés bien) de Borland me bloque dans le développement d'un projet
volumineux car ce dernier plante systématiquement dés que le projet atteint
une certaine taille (j'ai déjà scindé le projet en deux il y a quelques
années pour les mêmes raison).
Ma question est que je ne vois pas (ou ne connais pas) d'autre environnement
de développement capable de rivaliser avec ces deux là. Quel environnement
me conseillez-vous permettant de suivre des projets dans le long terme ?
Quels sont les faiblesses et points forts de chacun ?
J'imagine que tu es en haute résolution ? En 1024x768, Visual Studio est totalement inutilisable. Je préfère l'IDE de BC++ 5.02, pur "MDI" (i.e. à l'intérieur de la fenêtre du logiciel, plusieurs petites fenêtres totalement indépendantes -- projet, message, machin.cpp, truc.cpp, etc. -- que tu peux agrandir sur presque toute la surface de l'écran, en passant de l'une à l'autre par Ctrl-Tab).
On 08 Jan 2006 09:37:38 GMT, John Deuf <nomail@dontuseit.com>:
ecran 21"
J'imagine que tu es en haute résolution ?
En 1024x768, Visual Studio est totalement inutilisable. Je préfère
l'IDE de BC++ 5.02, pur "MDI" (i.e. à l'intérieur de la fenêtre
du logiciel, plusieurs petites fenêtres totalement indépendantes --
projet, message, machin.cpp, truc.cpp, etc. -- que tu peux agrandir
sur presque toute la surface de l'écran, en passant de l'une à l'autre
par Ctrl-Tab).
J'imagine que tu es en haute résolution ? En 1024x768, Visual Studio est totalement inutilisable. Je préfère l'IDE de BC++ 5.02, pur "MDI" (i.e. à l'intérieur de la fenêtre du logiciel, plusieurs petites fenêtres totalement indépendantes -- projet, message, machin.cpp, truc.cpp, etc. -- que tu peux agrandir sur presque toute la surface de l'écran, en passant de l'une à l'autre par Ctrl-Tab).
loic.actarus.joly
Visual Studio possède aussi un mode ou tout est dans une fenêtre différente type MDI. Pour ma part, chez moi je suis en 1152*864, et l'interface dockable me semble utilisable sans problèmes, même si le 1280*1024 au boulot est plus agréable.
Visual Studio possède aussi un mode ou tout est dans une fenêtre
différente type MDI. Pour ma part, chez moi je suis en 1152*864, et
l'interface dockable me semble utilisable sans problèmes, même si le
1280*1024 au boulot est plus agréable.
Visual Studio possède aussi un mode ou tout est dans une fenêtre différente type MDI. Pour ma part, chez moi je suis en 1152*864, et l'interface dockable me semble utilisable sans problèmes, même si le 1280*1024 au boulot est plus agréable.
kanze
John Deuf wrote:
Christian PANEL :
Ma question est que je ne vois pas (ou ne connais pas) d'autre environnement de développement capable de rivaliser avec ces deux là. Quel environnement me conseillez-vous permettant de suivre des projets dans le long terme ?
Des editeurs de sources C++ il doit y en avoir une centaine.
Quels sont les faiblesses et points forts de chacun ?
Sous Windows, j'utilise Visual C++ derniere version avec Visual Assist, et franchement c'est un regal !
Avec la fonction IntelliSense, il te suggere les noms de fonctions, les parametres, les namespace, les membres, etc.
Là, tu m'intrigues. Normalement, le nom de la fonction doit être fonction de ce que fait la fonction. Comment Visual C++ sait ce que va faire la fonction ? En termes de l'application ?
Les fautes de frappe, de casse ou de parametres sont reduites a zero.
S'il s'agit d'un nom qui est déjà présent ailleurs dans l'éditeur, en quoi est-ce que ça diffère de l'achevement du nom, tel qu'il existe en emacs ou en vim depuis au moins une quinzaine d'années ?
De plus, avec la "DynamicHelp" tu vois directement la documentation de ce que tu es en train de taper. Tres utile si tu ne connais pas la STL par coeur.
Vim a bien quelque chose comme ça, mais je n'ai pas pris la peine de le configurer. Parce qu'en général, il faut que je régarde la doc *avant* de commencer à taper -- en ce qui concerne la STL, je ne sais même pas tout ce qui existe par coeur.
Visual Assist rajoute plein d'ameliorations aux sus-cites, avec en plus la correction orthographique de tes commentaires et de tes chaines de caracteres en cours de frappe.
Là, en revanche, ça me semble intéressant. Pas toujours, mais souvent. Je suppose qu'il est multilingue. Est-ce qu'il détecte aussi les fautes du genre ?
-- 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
John Deuf wrote:
Christian PANEL :
Ma question est que je ne vois pas (ou ne connais pas)
d'autre environnement de développement capable de rivaliser
avec ces deux là. Quel environnement me conseillez-vous
permettant de suivre des projets dans le long terme ?
Des editeurs de sources C++ il doit y en avoir une centaine.
Quels sont les faiblesses et points forts de chacun ?
Sous Windows, j'utilise Visual C++ derniere version avec
Visual Assist, et franchement c'est un regal !
Avec la fonction IntelliSense, il te suggere les noms de
fonctions, les parametres, les namespace, les membres, etc.
Là, tu m'intrigues. Normalement, le nom de la fonction doit être
fonction de ce que fait la fonction. Comment Visual C++ sait ce
que va faire la fonction ? En termes de l'application ?
Les fautes de frappe, de casse ou de parametres sont reduites
a zero.
S'il s'agit d'un nom qui est déjà présent ailleurs dans
l'éditeur, en quoi est-ce que ça diffère de l'achevement du nom,
tel qu'il existe en emacs ou en vim depuis au moins une
quinzaine d'années ?
De plus, avec la "DynamicHelp" tu vois directement la
documentation de ce que tu es en train de taper. Tres utile si
tu ne connais pas la STL par coeur.
Vim a bien quelque chose comme ça, mais je n'ai pas pris la
peine de le configurer. Parce qu'en général, il faut que je
régarde la doc *avant* de commencer à taper -- en ce qui
concerne la STL, je ne sais même pas tout ce qui existe par
coeur.
Visual Assist rajoute plein d'ameliorations aux sus-cites,
avec en plus la correction orthographique de tes commentaires
et de tes chaines de caracteres en cours de frappe.
Là, en revanche, ça me semble intéressant. Pas toujours, mais
souvent. Je suppose qu'il est multilingue. Est-ce qu'il détecte
aussi les fautes du genre ?
--
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
Ma question est que je ne vois pas (ou ne connais pas) d'autre environnement de développement capable de rivaliser avec ces deux là. Quel environnement me conseillez-vous permettant de suivre des projets dans le long terme ?
Des editeurs de sources C++ il doit y en avoir une centaine.
Quels sont les faiblesses et points forts de chacun ?
Sous Windows, j'utilise Visual C++ derniere version avec Visual Assist, et franchement c'est un regal !
Avec la fonction IntelliSense, il te suggere les noms de fonctions, les parametres, les namespace, les membres, etc.
Là, tu m'intrigues. Normalement, le nom de la fonction doit être fonction de ce que fait la fonction. Comment Visual C++ sait ce que va faire la fonction ? En termes de l'application ?
Les fautes de frappe, de casse ou de parametres sont reduites a zero.
S'il s'agit d'un nom qui est déjà présent ailleurs dans l'éditeur, en quoi est-ce que ça diffère de l'achevement du nom, tel qu'il existe en emacs ou en vim depuis au moins une quinzaine d'années ?
De plus, avec la "DynamicHelp" tu vois directement la documentation de ce que tu es en train de taper. Tres utile si tu ne connais pas la STL par coeur.
Vim a bien quelque chose comme ça, mais je n'ai pas pris la peine de le configurer. Parce qu'en général, il faut que je régarde la doc *avant* de commencer à taper -- en ce qui concerne la STL, je ne sais même pas tout ce qui existe par coeur.
Visual Assist rajoute plein d'ameliorations aux sus-cites, avec en plus la correction orthographique de tes commentaires et de tes chaines de caracteres en cours de frappe.
Là, en revanche, ça me semble intéressant. Pas toujours, mais souvent. Je suppose qu'il est multilingue. Est-ce qu'il détecte aussi les fautes du genre ?
-- 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
kanze
Fabien LE LEZ wrote:
On 08 Jan 2006 09:48:32 GMT, John Deuf :
et qui permettent un débogage interactif,
Effectivement, pour cette option, le choix est plus reduit.
D'autant que les différents débogueurs ont des interfaces différentes. Donc un éditeur compatible Borland ne sera pas compatible Microsoft, etc.
Mais ça doit se configurer, non ? Je sais qu'emacs a une mode spéciale pour tous les programmes intéractifs, à commencer par le shell, et que son mode de déboggage n'en est qu'une spécialisation de cette mode plus général. Mais j'avoue ne pas en savoir plus ; je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
-- 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
Fabien LE LEZ wrote:
On 08 Jan 2006 09:48:32 GMT, John Deuf <nomail@dontuseit.com>:
et qui permettent un débogage interactif,
Effectivement, pour cette option, le choix est plus reduit.
D'autant que les différents débogueurs ont des interfaces
différentes. Donc un éditeur compatible Borland ne sera pas
compatible Microsoft, etc.
Mais ça doit se configurer, non ? Je sais qu'emacs a une mode
spéciale pour tous les programmes intéractifs, à commencer par
le shell, et que son mode de déboggage n'en est qu'une
spécialisation de cette mode plus général. Mais j'avoue ne pas
en savoir plus ; je ne vois pas vraiment l'intérêt de
l'utilisation d'un déboggueur la plupart du temps.
--
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
Effectivement, pour cette option, le choix est plus reduit.
D'autant que les différents débogueurs ont des interfaces différentes. Donc un éditeur compatible Borland ne sera pas compatible Microsoft, etc.
Mais ça doit se configurer, non ? Je sais qu'emacs a une mode spéciale pour tous les programmes intéractifs, à commencer par le shell, et que son mode de déboggage n'en est qu'une spécialisation de cette mode plus général. Mais j'avoue ne pas en savoir plus ; je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
-- 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
Fabien LE LEZ
On 9 Jan 2006 01:21:04 -0800, "kanze" :
S'il s'agit d'un nom qui est déjà présent ailleurs dans l'éditeur, en quoi est-ce que ça diffère de l'achevement du nom, tel qu'il existe en emacs ou en vim depuis au moins une quinzaine d'années ?
J'imagine qu'il parle des fonctions membres : Si x est un Machin, et Machin a une fonction membre foo(), l'éditeur te proposera foo() quand tu tapes "x.f".
On 9 Jan 2006 01:21:04 -0800, "kanze" <kanze@gabi-soft.fr>:
S'il s'agit d'un nom qui est déjà présent ailleurs dans
l'éditeur, en quoi est-ce que ça diffère de l'achevement du nom,
tel qu'il existe en emacs ou en vim depuis au moins une
quinzaine d'années ?
J'imagine qu'il parle des fonctions membres : Si x est un Machin, et
Machin a une fonction membre foo(), l'éditeur te proposera foo() quand
tu tapes "x.f".
S'il s'agit d'un nom qui est déjà présent ailleurs dans l'éditeur, en quoi est-ce que ça diffère de l'achevement du nom, tel qu'il existe en emacs ou en vim depuis au moins une quinzaine d'années ?
J'imagine qu'il parle des fonctions membres : Si x est un Machin, et Machin a une fonction membre foo(), l'éditeur te proposera foo() quand tu tapes "x.f".
Fabien LE LEZ
On 9 Jan 2006 01:24:59 -0800, "kanze" :
je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
La plupart du temps, effectivement. Mais parfois, tu tombes sur un bug particulièrement difficile à cerner, et un bon débogueur, capable d'afficher l'évolution de la valeur d'une variable au cours de l'exécution pas à pas, peut faire gagner beaucoup de temps.
Par contre, on peut choisir d'avoir deux éditeurs différents : un pour taper le code, et un pour le débogage.
On 9 Jan 2006 01:24:59 -0800, "kanze" <kanze@gabi-soft.fr>:
je ne vois pas vraiment l'intérêt de
l'utilisation d'un déboggueur la plupart du temps.
La plupart du temps, effectivement.
Mais parfois, tu tombes sur un bug particulièrement difficile à
cerner, et un bon débogueur, capable d'afficher l'évolution de la
valeur d'une variable au cours de l'exécution pas à pas, peut faire
gagner beaucoup de temps.
Par contre, on peut choisir d'avoir deux éditeurs différents : un pour
taper le code, et un pour le débogage.
je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
La plupart du temps, effectivement. Mais parfois, tu tombes sur un bug particulièrement difficile à cerner, et un bon débogueur, capable d'afficher l'évolution de la valeur d'une variable au cours de l'exécution pas à pas, peut faire gagner beaucoup de temps.
Par contre, on peut choisir d'avoir deux éditeurs différents : un pour taper le code, et un pour le débogage.
JM
J'imagine qu'il parle des fonctions membres : Si x est un Machin, et Machin a une fonction membre foo(), l'éditeur te proposera foo() quand tu tapes "x.f".
Oui. Et en cas de plusieurs fonction commençant par la même lettre par exemple, tu as une boite qui apparait et qui permet de sélectionner la bonne fonction
J'imagine qu'il parle des fonctions membres : Si x est un Machin, et
Machin a une fonction membre foo(), l'éditeur te proposera foo() quand
tu tapes "x.f".
Oui.
Et en cas de plusieurs fonction commençant par la même lettre par
exemple, tu as une boite qui apparait et qui permet de sélectionner la
bonne fonction
J'imagine qu'il parle des fonctions membres : Si x est un Machin, et Machin a une fonction membre foo(), l'éditeur te proposera foo() quand tu tapes "x.f".
Oui. Et en cas de plusieurs fonction commençant par la même lettre par exemple, tu as une boite qui apparait et qui permet de sélectionner la bonne fonction
SerGioGio
"kanze" a écrit dans le message de news:
je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
Bonjour!
Simple curiosité mais, si votre programme bugge constamment sur la même entrée... le débuggeur peut permettre de résoudre le problème rapidement non? Ou bien vous arrangez vous toujours pour ne jamais tomber dans de telles situations (preuves de code?).
SerGioGioGio
"kanze" <kanze@gabi-soft.fr> a écrit dans le message de news:
1136798698.986240.316740@g49g2000cwa.googlegroups.com...
je ne vois pas vraiment l'intérêt de
l'utilisation d'un déboggueur la plupart du temps.
Bonjour!
Simple curiosité mais, si votre programme bugge constamment sur la même
entrée... le débuggeur peut permettre de résoudre le problème rapidement
non?
Ou bien vous arrangez vous toujours pour ne jamais tomber dans de telles
situations (preuves de code?).
je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
Bonjour!
Simple curiosité mais, si votre programme bugge constamment sur la même entrée... le débuggeur peut permettre de résoudre le problème rapidement non? Ou bien vous arrangez vous toujours pour ne jamais tomber dans de telles situations (preuves de code?).
SerGioGioGio
kanze
Fabien LE LEZ wrote:
On 9 Jan 2006 01:24:59 -0800, "kanze" :
je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
La plupart du temps, effectivement. Mais parfois, tu tombes sur un bug particulièrement difficile à cerner, et un bon débogueur, capable d'afficher l'évolution de la valeur d'une variable au cours de l'exécution pas à pas, peut faire gagner beaucoup de temps.
Je n'ai pas trop trouvé ce cas-là, au moins dans le code que j'écris professionnellement. L'instrumentation (les sorties vers le log) doit suffire -- en fin de compte, si le problème se présente chez l'utilisateur, c'est tout ce que tu vas avoir. (Mais je crois que tu travailles dans une contexte différente que moi -- surtout, que ton rapport avec les utilisateurs n'est peut-être pas le même.)
C'est effectivement parfois utile dans les petits utilitaires qu'on écrit pour soi-même, où on n'a pas pris la peine d'instrumenter.
C'est surtout utile quand on te file 100 mille lignes de spaghetti, non documenté, pour trouver dans quelles modules tu passes dans le cas qui t'intéresse. (Mais nous sommes d'accord que dans une boîte bien gérée, ça n'arrive jamais, n'est-ce pas:-).)
Par contre, on peut choisir d'avoir deux éditeurs différents : un pour taper le code, et un pour le débogage.
Je ne comprends pas trop la rôle d'un éditeur lors de déboggage. Emacs, et je crois vim aussi, le supporte, mais pourquoi faire ?
Au moins, peut-être, que tu as un IDE qui permet de continuer après modification (et récompilation) du code. (C'est le cas de l'IDE de Sun, par exemple. Mais étant donné que je n'utilise pas le déboggueur sur le code que j'ai écrit moi-même, je ne l'ai jamais essayé.)
-- 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
Fabien LE LEZ wrote:
On 9 Jan 2006 01:24:59 -0800, "kanze" <kanze@gabi-soft.fr>:
je ne vois pas vraiment l'intérêt de l'utilisation d'un
déboggueur la plupart du temps.
La plupart du temps, effectivement.
Mais parfois, tu tombes sur un bug particulièrement difficile
à cerner, et un bon débogueur, capable d'afficher l'évolution
de la valeur d'une variable au cours de l'exécution pas à pas,
peut faire gagner beaucoup de temps.
Je n'ai pas trop trouvé ce cas-là, au moins dans le code que
j'écris professionnellement. L'instrumentation (les sorties vers
le log) doit suffire -- en fin de compte, si le problème se
présente chez l'utilisateur, c'est tout ce que tu vas avoir.
(Mais je crois que tu travailles dans une contexte différente
que moi -- surtout, que ton rapport avec les utilisateurs n'est
peut-être pas le même.)
C'est effectivement parfois utile dans les petits utilitaires
qu'on écrit pour soi-même, où on n'a pas pris la peine
d'instrumenter.
C'est surtout utile quand on te file 100 mille lignes de
spaghetti, non documenté, pour trouver dans quelles modules tu
passes dans le cas qui t'intéresse. (Mais nous sommes d'accord
que dans une boîte bien gérée, ça n'arrive jamais, n'est-ce
pas:-).)
Par contre, on peut choisir d'avoir deux éditeurs différents :
un pour taper le code, et un pour le débogage.
Je ne comprends pas trop la rôle d'un éditeur lors de déboggage.
Emacs, et je crois vim aussi, le supporte, mais pourquoi faire ?
Au moins, peut-être, que tu as un IDE qui permet de continuer
après modification (et récompilation) du code. (C'est le cas de
l'IDE de Sun, par exemple. Mais étant donné que je n'utilise pas
le déboggueur sur le code que j'ai écrit moi-même, je ne l'ai
jamais essayé.)
--
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
je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
La plupart du temps, effectivement. Mais parfois, tu tombes sur un bug particulièrement difficile à cerner, et un bon débogueur, capable d'afficher l'évolution de la valeur d'une variable au cours de l'exécution pas à pas, peut faire gagner beaucoup de temps.
Je n'ai pas trop trouvé ce cas-là, au moins dans le code que j'écris professionnellement. L'instrumentation (les sorties vers le log) doit suffire -- en fin de compte, si le problème se présente chez l'utilisateur, c'est tout ce que tu vas avoir. (Mais je crois que tu travailles dans une contexte différente que moi -- surtout, que ton rapport avec les utilisateurs n'est peut-être pas le même.)
C'est effectivement parfois utile dans les petits utilitaires qu'on écrit pour soi-même, où on n'a pas pris la peine d'instrumenter.
C'est surtout utile quand on te file 100 mille lignes de spaghetti, non documenté, pour trouver dans quelles modules tu passes dans le cas qui t'intéresse. (Mais nous sommes d'accord que dans une boîte bien gérée, ça n'arrive jamais, n'est-ce pas:-).)
Par contre, on peut choisir d'avoir deux éditeurs différents : un pour taper le code, et un pour le débogage.
Je ne comprends pas trop la rôle d'un éditeur lors de déboggage. Emacs, et je crois vim aussi, le supporte, mais pourquoi faire ?
Au moins, peut-être, que tu as un IDE qui permet de continuer après modification (et récompilation) du code. (C'est le cas de l'IDE de Sun, par exemple. Mais étant donné que je n'utilise pas le déboggueur sur le code que j'ai écrit moi-même, je ne l'ai jamais essayé.)
-- 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
kanze
SerGioGio wrote:
"kanze" a écrit dans le message de news:
je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
Simple curiosité mais, si votre programme bugge constamment sur la même entrée... le débuggeur peut permettre de résoudre le problème rapidement non?
Il faut mettre les choses en contexte. S'il s'agit d'un test unitaire, j'ai bien choisi les entrées pour tester un cas précis. D'après le résultat, c'est en général évident où est l'erreur.
Dans l'application, j'instrumente les interfaces entre les modules. À partir du log, je vois grosso modo quelle module a une sortie incorrecte pour une entrée correcte. Alors, j'ajoute le cas aux tests unitaire. Il faut que le test unitaire échoue avant d'entreprendre la moindre modification dans le code de la module -- sinon, comment savoir que j'ai corrigé l'erreur. Et évidemment, une fois qu'on a un test unitaire qui échoit, on se rétrouve dans le premier cas.
Ou bien vous arrangez vous toujours pour ne jamais tomber dans de telles situations (preuves de code?).
C'est vrai que les revues de code bien menées (pas forcément des preuves au sens mathématique, mais les collègues doivent bien être convaincu de sa correction) élimine énormement d'erreurs. Réalistiquement, en revanche, il faut compter avec la possibilité qu'une ou deux erreurs passent à travers (à peu près une par 100 KLOC dans une boîte moyenne).
-- 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
SerGioGio wrote:
"kanze" <kanze@gabi-soft.fr> a écrit dans le message de news:
1136798698.986240.316740@g49g2000cwa.googlegroups.com...
je ne vois pas vraiment l'intérêt de l'utilisation d'un
déboggueur la plupart du temps.
Simple curiosité mais, si votre programme bugge constamment
sur la même entrée... le débuggeur peut permettre de résoudre
le problème rapidement non?
Il faut mettre les choses en contexte. S'il s'agit d'un test
unitaire, j'ai bien choisi les entrées pour tester un cas
précis. D'après le résultat, c'est en général évident où est
l'erreur.
Dans l'application, j'instrumente les interfaces entre les
modules. À partir du log, je vois grosso modo quelle module a
une sortie incorrecte pour une entrée correcte. Alors, j'ajoute
le cas aux tests unitaire. Il faut que le test unitaire échoue
avant d'entreprendre la moindre modification dans le code de la
module -- sinon, comment savoir que j'ai corrigé l'erreur. Et
évidemment, une fois qu'on a un test unitaire qui échoit, on se
rétrouve dans le premier cas.
Ou bien vous arrangez vous toujours pour ne jamais tomber dans
de telles situations (preuves de code?).
C'est vrai que les revues de code bien menées (pas forcément des
preuves au sens mathématique, mais les collègues doivent bien
être convaincu de sa correction) élimine énormement d'erreurs.
Réalistiquement, en revanche, il faut compter avec la
possibilité qu'une ou deux erreurs passent à travers (à peu près
une par 100 KLOC dans une boîte moyenne).
--
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
je ne vois pas vraiment l'intérêt de l'utilisation d'un déboggueur la plupart du temps.
Simple curiosité mais, si votre programme bugge constamment sur la même entrée... le débuggeur peut permettre de résoudre le problème rapidement non?
Il faut mettre les choses en contexte. S'il s'agit d'un test unitaire, j'ai bien choisi les entrées pour tester un cas précis. D'après le résultat, c'est en général évident où est l'erreur.
Dans l'application, j'instrumente les interfaces entre les modules. À partir du log, je vois grosso modo quelle module a une sortie incorrecte pour une entrée correcte. Alors, j'ajoute le cas aux tests unitaire. Il faut que le test unitaire échoue avant d'entreprendre la moindre modification dans le code de la module -- sinon, comment savoir que j'ai corrigé l'erreur. Et évidemment, une fois qu'on a un test unitaire qui échoit, on se rétrouve dans le premier cas.
Ou bien vous arrangez vous toujours pour ne jamais tomber dans de telles situations (preuves de code?).
C'est vrai que les revues de code bien menées (pas forcément des preuves au sens mathématique, mais les collègues doivent bien être convaincu de sa correction) élimine énormement d'erreurs. Réalistiquement, en revanche, il faut compter avec la possibilité qu'une ou deux erreurs passent à travers (à peu près une par 100 KLOC dans une boîte moyenne).
-- 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
