Taille des procédures VBA sous Excel
Fermé
zouzou75005
-
23 juil. 2009 à 19:09
voyageur59 Messages postés 1112 Date d'inscription vendredi 7 décembre 2007 Statut Membre Dernière intervention 10 novembre 2009 - 28 juil. 2009 à 19:31
voyageur59 Messages postés 1112 Date d'inscription vendredi 7 décembre 2007 Statut Membre Dernière intervention 10 novembre 2009 - 28 juil. 2009 à 19:31
Bonjour le forum,
Je me pose une petite question toute simple: sur tous les forums, sites, blogs,.. consacrés à Excel, tout le monde s'accorde à dire qu'une procédure ne doit pas dépasser 100 lignes, 200 grand maximum.
Or, j'ai écrit une procédure qui fait 850 lignes (avec les commentaires), oui j'ai bien dit 850 lignes qui marche parfaitement et s'exécute en 5 secondes. Alors quel est l'intérêt de s'embêter à fractionner son code en plusieurs procédures/fonctions? Y a-t-il une raison subtile qui m'échappe ou est-ce juste une règle arbitraire des programmeurs VBA ?
Merci d'avance pour vos réponses et bonne soirée à tous!
Je me pose une petite question toute simple: sur tous les forums, sites, blogs,.. consacrés à Excel, tout le monde s'accorde à dire qu'une procédure ne doit pas dépasser 100 lignes, 200 grand maximum.
Or, j'ai écrit une procédure qui fait 850 lignes (avec les commentaires), oui j'ai bien dit 850 lignes qui marche parfaitement et s'exécute en 5 secondes. Alors quel est l'intérêt de s'embêter à fractionner son code en plusieurs procédures/fonctions? Y a-t-il une raison subtile qui m'échappe ou est-ce juste une règle arbitraire des programmeurs VBA ?
Merci d'avance pour vos réponses et bonne soirée à tous!
A voir également:
- Taille des procédures VBA sous Excel
- Comment réduire la taille d'un fichier - Guide
- Liste déroulante excel - Guide
- Si et excel - Guide
- Word et excel gratuit - Guide
- Déplacer une colonne excel - Guide
4 réponses
voyageur59
Messages postés
1112
Date d'inscription
vendredi 7 décembre 2007
Statut
Membre
Dernière intervention
10 novembre 2009
132
23 juil. 2009 à 20:12
23 juil. 2009 à 20:12
Bonjour,
Règle arbitraire des programmeurs.
Mais par principe. Pour faire une procédure de 2500 lignes, lances toi plutôt dans VB.net (pour rester dans VB).
C'est pas un logiciel de programmation!
Règle arbitraire des programmeurs.
Mais par principe. Pour faire une procédure de 2500 lignes, lances toi plutôt dans VB.net (pour rester dans VB).
C'est pas un logiciel de programmation!
eriiic
Messages postés
24603
Date d'inscription
mardi 11 septembre 2007
Statut
Contributeur
Dernière intervention
15 décembre 2024
7 255
24 juil. 2009 à 09:59
24 juil. 2009 à 09:59
Bonjour,
D'autres avantages de découper son code :
- faciliter la lecture
- faciliter le déboguage. Si un sub a été parfaitement testé tu sais que tu n'as plus à revenir dessus et tu exécutes cette partie sans te poser de question.
eric
D'autres avantages de découper son code :
- faciliter la lecture
- faciliter le déboguage. Si un sub a été parfaitement testé tu sais que tu n'as plus à revenir dessus et tu exécutes cette partie sans te poser de question.
eric
Et j'ajoute que séparer ses procédures est la seule solution pour éviter le message fatal "Procedure too large", que je viens de voir apparaître :-( J'ai compris la leçon.. Merci à tous!
voyageur59
Messages postés
1112
Date d'inscription
vendredi 7 décembre 2007
Statut
Membre
Dernière intervention
10 novembre 2009
132
28 juil. 2009 à 19:31
28 juil. 2009 à 19:31
Re-
Là quel que soit le langage de programmation, on évite les procédure de plus de 64ko! même si les nouvelles versions supportent plus!
Là quel que soit le langage de programmation, on évite les procédure de plus de 64ko! même si les nouvelles versions supportent plus!