Pour outrepasser la limite des 64000 lignes... Il suffit de modifier le code de ceci :
en cela:Code:
1
2
3
4 int main() { return 0; }
:aie:Code:int main(){return 0;}
(c'est quoi la limite de VS en ce qui concerne la largeur des lignes?)
Version imprimable
Pour outrepasser la limite des 64000 lignes... Il suffit de modifier le code de ceci :
en cela:Code:
1
2
3
4 int main() { return 0; }
:aie:Code:int main(){return 0;}
(c'est quoi la limite de VS en ce qui concerne la largeur des lignes?)
Oui tu peux même aller plus loin en créant des types abrégés et en raccourcissant tes variables
:aie:Code:
1
2
3
4
5
6
7
8 typedef int i;typedef String S; // ancien code: //int nombreDeFactures = 0; //String nomDuClient = "Dupont et Fils"; //nouveau code: i n=0;S N="Dupont et Fils";
Je ne connais pas le résultat en .NET, mais dans une application Windows native (C, Delphi...), on peut mettre DebugBreak dans le code (Entouré de ifdef _DEBUG par exemple ou conditionnel suivant une variable d'environnement).
Cela revient à utiliser l'instruction int 3 du processeur.
Après soit on lance l'appli depuis l'EDI, soit on la lance toute seul avec un PC ou le just in time debugging est correctement configuré vers windbg ou visual.
Honnetement, je suis encore étudiant, donc je ne m'imagine pas vraiment, mais est-ce que quelqu’un à déjà écris un code de plus de 64 000 lignes? o_O
Parce que je vois pas bien comment on pourrai ne serait-ce que parcourir le code...
à ce niveau là, il vaut mieux créer plusieurs fichiers!
Il vaudrait mieux que les gens écrivant 64000 lignes de code se mette à lire Coder Proprement ou Code Complete xD
Heu... les 64 000 c'est pour une classe ou un fichier ?
(la différence est notable, ne pas oublier les partial)
De plus, une classe de 64 000 lignes, je pense que il y a un problème de conception, ça sent pas mal la classe "foure tout"...
Tout à fait d'accord. Déjà, il est aberrant de ne pas factoriser son code et de ne pas créer des classes dédiées fonctionnalités ou métiers externalisées sous forme de projets (Visual Studio). Les méthodes des événements par exemple ne devrait comporter que quels lignes de codes nécessaires pour appeler des méthodes externalisées et aucun code fonctionnel.
Pour ma part, la plus longue classe que j'ai écrite devait faire 2500 lignes de codes et mon code était très aéré et très commenté et la solution comportait au moins une demi-douzaine de projets. Pour deux bugs en tout et pour tout en prod !
Concentrer son code ou être avar dans sa lisibilité est également une grosse erreur. Cela empêche la relecture du code pour une future évolution et malheureusement pour la maintenance/debug toujours nécessaire voire indispensable lorsque l'on repasse derrière un confrère.
Il faut d'abord et toujours penser à bien coder et laisser le moins de bugs le plus de commentaires et à bien factoriser avant de penser à des problèmes de limitation de lignes de codes qui sont immanquablement des preuves de mauvaise méthode de travail.
La factorisation amène également une extrême rapidité des process !
La seule problématique est celui des pages web, principalement en asp.net très gourmande en lignes de codes. Plus particulièrement le code-behind ou l'emploi des controls tels le repeater, control de binding à sens unique, alourdit considérablement le code nécessaire.
Mais heureusement JQuery est maintenant là pour le coté page et permet de ne plus mettre, ou presque, de code javascript dans celles-ci lorsque l'on encore obligé de faire des pages asp. 8-)
Entity Framework des fois génère des trucs assez impressionnants.
Une trentaine de tables ca represente pas loin de 9000 lignes de code dans un seul fichier. Je sais pas si au dela il coupe en plusieurs partials class, mais cela m'étonnerait.
Donc en pratique, je n'ai jamais été limité par mon IDE.