Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quels sont vos astuces pour passer outre les limitations des EDI ?
Comme marquer des arrêts dans un code volumineux sans points d'arrêt

Le , par Hinault Romaric

31PARTAGES

3  6 
Les applications contenant des fichiers de source avec des lignes de code volumineux sont très souvent sujet à des dysfonctionnements. Les développeurs souhaitent alors retrouver rapidement le bloc ou la ligne qui ne s'exécute pas correctement.

Plusieurs techniques et outils permettent d'effectuer le débogage d'un programme et d'observer son fonctionnement pour apporter des corrections de bugs ou faire des optimisations.

Parmi eux, les points d'arrêt (breakpoints) sont très utilisés. Un point d'arrêt peut être vu comme un signal qui indique au débogueur de suspendre temporairement l'exécution d'un programme à un certain point (tout en gardant les variables, objets et autres en mémoire). Les points d'arrêt sont donc indispensables pour examiner les états à la recherche de violations ou de bugs. Ils sont surtout très pratiques pour l'analyse des codes volumineux.

Cependant, il arrive que certains EDI aient des limitations. Visual Studio par exemple, ne prend plus en compte les points d'arrêt sur les lignes après la 64.000ième ligne de code.

Une limitation assez contraignante pour les développeurs .NET, en particulier les développeurs C++, et également pour du code généré qui s'avère le plus souvent assez volumineux, et dont l'on souhaiterait comprendre le fonctionnement.

Pour la contourner, on peut cependant se tourner vers des astuces comme l'utilisation de l'instruction goto en C++ ou encore l'instruction « Stop » en Visual Basic.

D'autres techniques peuvent encore être utilisées pour réduire et optimiser le code contenu dans un fichier source.

A vous de nous dire celles que vous utilisez.

La notification de Microsoft sur la limitation du debogueur Visual Studio

Et vous ?

Quelles sont vos astuces pour réduire/optimiser le nombre de lignes de code contenu dans un fichier source, ou pour marquer des temps morts et analyser votre code sans passer par des points d'arrêt ?

Que conseillez-vous dans ce cas ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de gbdivers
Inactif https://www.developpez.com
Le 28/06/2011 à 19:40
64000 lignes de code dans 1 fichiers ??? Utiliser des goto en C++ ???
C'est une limitation des EDI ou un bug chez le développeur ?
C'est compatible avec les bonnes pratiques de codage ?
16  1 
Avatar de cs_ntd
Membre éprouvé https://www.developpez.com
Le 28/06/2011 à 20:37


J'approuve totalement la remarque de gbdivers.
64,000 lignes de codes dans un seul fichier, il faut etre completement stupide (disons inconscient). Et meme si par un hasard fou, il y avait une seule classe dans ce fichier qui requiert effectivement plus de 64,000 lignes, c'est quand meme pas si compliqué d'utiliser 2 fichiers (ou plus).

Et en .NET c'est de l'abrutissement complet
Code : Sélectionner tout
Une limitation assez contraignante pour les développeurs .NET
Me faites pas rire, les 'partial class' rendent l'utilisation de multiples fichiers pour une seule classe parfaitement transparente pour le développeur... Donc le coup du Stop en VB ...

En C++ c'est moins "évident", mais en jouant 2 secondes avec des includes on fait très bien 2 fichiers aussi

Bon je veux bien croire que c'est une limite étrange, mais si en plus les gens qui font des fichiers de 64,000 lignes de code utilisent des goto et des Stop, non mais franchement
6  1 
Avatar de Nanocom
Nouveau membre du Club https://www.developpez.com
Le 28/06/2011 à 20:26
Pour moi, un nombre trop élevé de lignes de code indique un problème de conception.
5  1 
Avatar de zeyr2mejetrem
Membre chevronné https://www.developpez.com
Le 29/06/2011 à 9:32
  • >64000 lignes de codes dans un seul fichier
  • Balancer un GOTO ou un STOP pour faire caler l'appli


No comment
Le titre du topic aurait pu être "Quels sont vos bidouilles pour faire tomber en marche votre trash-code ?"

Personnellement, si un de mes dévs en arrive là, je l'abats pour éviter qu'il souffre
5  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 29/06/2011 à 8:31
Citation Envoyé par Nanocom Voir le message
Pour moi, un nombre trop élevé de lignes de code indique un problème de conception.
Ce genre de problème arrive malheureusement souvent quand on a recours a des générateurs de code automatique qui s’embarrassent rarement de ce genre de concept

Certes c'est moche, mais tu n'as malheureusement pas toujours la maitrise de tout ça. Souvent tu es obligé de faire avec ce qu'on te donne.
1  0 
Avatar de Louis-Guillaume Morand
Rédacteur https://www.developpez.com
Le 29/06/2011 à 10:00
Je fais tout simplement un fonction de log et je trace les infos dont j'ai besoin et qui me permettrait de trouver mon problème.
Dans le cas de .Net, je fais souvent une méthode ToString() dans mes classes pour récupérer toutes les infos.
beurk. Il faut utiliser des debug/trace et les activer/desactiver on-demand par fichier de config.

Mais bon, déjà quand le fichier frôle les 500 lignes, je me dis qu'il y a un problème de conception
500 lignes?! utilise des patterns genre MVVM et tu verras que rien qu'une classe modèle avec 20 propriétés fait déjà la moitié de ta "limite".
De la meme façon, lorsque l'on créé une interface pour un service, qui gère par exemple un seul objet métier, ca sert à rien d'en faire plusieurs classes et encore moins de le découper en classe partielle si c'est pour passer plus de temps à chercher dans quel fichier se trouve ta méthode. Les gros fichiers ont parfois une raison d'être. Mais s'ils sont bien organisés, tu retrouves ce dont tu as besoin en deux secondes, qu'il fasse 10 ou 100000 lignes.
1  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 29/06/2011 à 14:35
Pour outrepasser la limite des 64000 lignes... Il suffit de modifier le code de ceci :
Code : Sélectionner tout
1
2
3
4
int main()
{
    return 0;
}
en cela:
Code : Sélectionner tout
int main(){return 0;}


(c'est quoi la limite de VS en ce qui concerne la largeur des lignes?)
2  1 
Avatar de Cyrilange
Membre averti https://www.developpez.com
Le 28/06/2011 à 23:12
La dernière fois que j'ai approché les 60000 lignes de code c'était en GFA Basic sur un Atari 1040 ST pour un logiciel calculant les mutations génétiques d'oiseaux.

Merci la programmation orientée objet et VB.NET qui nous évite ce genre de sac de noeuds.

Je trouve ce sujet sans fondement ou alors je veux voir un exemple concret où il n'y a pas d'autres possibilités de que mettre 60000 lignes de codes dans une classe.
0  0 
Avatar de Reward
Membre confirmé https://www.developpez.com
Le 29/06/2011 à 8:56
Hinault Romaric, le jour où vous verrez en .NET une classe comportant plus de 64 000 lignes de code (), ça vaudra le coups d'en faire une news, car ça ne sera pas demain la veille...

Parce qu'atteindre ça pour une classe, c'est vraiment un problème de conception, mais bon, admettons, comme dit plus haut, le mot clé "partial" résoud ce problème très simplement, et du coup, ce n'est pas une contrainte pour les développeurs .NET.

Référence: http://msdn.microsoft.com/fr-fr/libr...v=VS.100).aspx
1  1 
Avatar de r0ots
Membre averti https://www.developpez.com
Le 29/06/2011 à 9:20
Un moyen de s'arrêter dans l'application? (C,C++)

Code : Sélectionner tout
1
2
int *i=0;
i[0]=0;
Et voila, c'est arrêté
0  0