BisounoursEnvoyé par SimonDecoline
Bisounours!
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Bisounours
Bisounours!
Ce n'est valable que si c'est ton code et qu'il est formaté pour VIM (donc des lignes ultra-courtes et le moins d'allers et venues possibles entre les lignes et fichiers). Quand tu ne sais pas exactement ce que tu cherches, c'est un cauchemar.
??? Des lignes courtes? Il m'arrive régulièrement d'en avoir à 120 et des bananes. Mais il est vrai que la norme, enfin les normes qualité sont à 80 en général. Celles que je me pose c'est que je sois capable de voir côté à côté un fichier .h et son fichier .cpp d'implémentation. Avec les écrans en 16/9e, ça fait dans les 100 colonnes avec la résolution que j'ai choisie. Au delà... il faut bien reconnaître que les études qui regardent l'aspect cognitif de nos capacités à correctement traiter des textes larges nous disent que les lignes longues, c'est pas efficace. Après, il y a un côté subjectif.
Au pire il y a un paramètre de 'wrapping' qui dit d'afficher les suites des lignes en dessous.
Ah! Et je triche, je n'utilise pas vim (mauvaise gestion des couleurs et des claviers), mais gvim qui ne borne pas l'affichage à une console.
Il ne le prétend pas, certains en interne le réfutent, et pourtant c'en est un depuis le tout début car depuis le tout début il a la coloration syntaxique et l'intégration de l'appel au compilateur. Il n'en faut pas plus pour être un environnement de développement intégré.Vim ne prétend pas être un IDE
Vu le manque de praticité de VIM, on se retrouve vite à multiplier les écrans et les lignes "longues" deviennent un problème. J'ai travaillé avec un type qui avait 8 terminaux VIM sur un écran.
C'est l'esprit minimaliste de vim qui pousse à ça. Beaucoup ont cette approche.
A contrario, j'ai une seule session/instance de vim que je peux garder des mois durant depuis laquelle je fais tout, avec de multiples sous-fenêtres en parallèle -- les onglets, c'est assez inférieur en qualité de confort.
Mais c'est bien parce que l'esprit minimaliste pousse à faire ça que je dis qu'il pousse à de mauvaises pratiques
Vim n'est pas minimaliste mais configurable. De base, il n'y a que le strict nécessaire car il faut installer ce dont on a besoin et le configurer comme on le veut. Beaucoup d'éditeurs de texte modernes fonctionnent plus ou moins de cette façon, par exemple visual studio code. Mais tu vas peut-être nous dire que visual studio code aussi pousse à de mauvaises pratiques...Mais c'est bien parce que l'esprit minimaliste pousse à faire ça que je dis qu'il pousse à de mauvaises pratiques
Praticité pour faire quoi ? Si c'est encore ton histoire de fichiers multiples et de lignes longues, on t'a déjà répondu que c'était faux. Non seulement, tu ne connais rien à l'outil hormis d'avoir vu un stagiaire l'utiliser n'importe comment mais en plus tu te fiches complètement des réponses qu'on te donne. Trolldi c'est demain.
Praticité pour travailler sur un gros projet, factorisé en de nombreuses fonctions courtes et classes. VIM n'est pas adapté à ça, c'est tout. Il est bien pour travailler sur un seul gros fichier par des power programmers qui se masturbent l'ego en pondant des instructions les plus courtes possibles mais incompréhensibles.
Soyons constructif, quel est ton editeur/IDE mastubatoire préféré qui doit certainement permettre à son utilisateur d'être moins con dans le développement d'un projet ?
Effectivement, aujourd'hui c'est trolldi donc tu peux dire toutes les conneries que tu veux. Bon Troll.
Dans le temps c'était Sublime Text, mais il faut bien reconnaître que VSCode l'écrase sur plus ou moins tous les points.
Ah oui, sublime text et vscode... C'est pas ces éditeurs qui affichent un petit aperçu de ton fichier pour savoir où tu en es quand ton fichier fait 30 000 lignes ?
Je ne comprends pas vraiment ton argument ni même si c'est censé en être un...
Il n'est pas si minimaliste que cela. En revanche il y a une volonté de certains de le cantonner à un aspect minimaliste: je dirai que c'est les admin sys qui l'utilisent à raison dans un cadre minimaliste et qui font croire à certains dev que leur conf doit aussi l'êtreMais c'est bien parce que l'esprit minimaliste pousse à faire ça que je dis qu'il pousse à de mauvaises pratiques
Maintenant je ne suis pas d'accord sur plusieurs autres points.
- avec des fonctions longues, il est au contraire peu agréable. Alors qu'il est si simple avec lui de naviguer. Mais vraiment. Donc vers des fonctions courtes, il me pousse. Si tu as croisé des gens qui n'ont aucun intérêt pour le SRP, ce n'est pas en les mettant sur une usine à gaz qui tu changeras quoique ce soit. Mon expérience est même à l'opposé vu que je suis celui qui utilise vim au boulot et que je vois beaucoup de codes bien trop longs faits par certains de mes petits camarades.
- Un IDE n'est pas forcément mieux côté qualité. Il ne faut pas tomber dans le piège inverse de l'over-engineering ou de suivre chaque conseil qui est au contraire exécrable. Cf les "Why setters are evil" et les IDE qui les génèrent à tour de bras.
PS: je travaille sur des gros projets C++ avec Vim et n'ais aucun soucis.
Pour moi le premier point important d'un IDE c'est de pouvoir naviguer facilement dans les fichiers et script d'un projets lorsque l'on ne sait pas ce que l'on cherche, et c'est le point principal sur lequel VIM se vautre lamentablement.
Pour le reste, je fais une utilisation plutôt limitée des fonctionnalités "IDE", correction de la syntaxe et interprétation des classes et méthodes accessibles dans le script ainsi navigation en SSH vers mon serveur.
Je n'utilise absolument pas les fonctionnalités d'auto-remplissage, je trouver notamment ridicule d'avoir une annotation /** @param string**/ quand la fonction en elle-même indique ce qu'elle attend en paramètres et ce qu'elle renvoie.
VSCode affiche un aperçu du fichier en miniature pour voir oú on est dans le code. Cela incite les programmeurs à mettre tout leur code dans un seul fichier énorme. VSCode pousse donc à de mauvaises pratiques de programmation. D'ailleurs la config de base de VSCode permet juste de bricoler des fichiers de conf ou javascript mais quand on veut faire de la vraie programmation, VSCode est complétement à la ramasse, même en installant quelqu'unes des 40 000 extensions de son marketplace, qui, de toute façon, sont toutes aussi buggées les unes que les autres. Et je ne parle même des informations de télémétries qui sont directement envoyées chez microsoft, avec tous les abus que l'on connait. D'ailleurs trés peu de dev java/c#/c++ utilisent VSCode, ce n'est pas pour rien...
Oui d'accord... si tu n'as rien à dire, ne dis rien, ça t'évitera de te fatiguer.
a- Comme je le disais, la navigation par les tags est fonctionnelle. De plus, les serveurs LSP sont ce qui est au coeur des IDE contemporains. Ils ont compris, ils délèguent. Microsoft a poussé sa bonne idée au bon moment. C'est au coeur de VSCode et cela a pris. Les autres outils ont compris l'intérêt de la chose.
De fait, les noyaux d'analyse sont indépendants des IDEs aujourd'hui. Donc, pour un langage donné on va pouvoir avoir le même analyseur et indexeur de code pour Vim et pour VSCode (et ...). Il n'y a aucun raison d'observer des différences (hors ergonomie: i.e. souris VS raccourcis clavier) entre Vim et VSCode.
Mais, il faut installer un plugin et potentiellement le configurer. De même qu'avec VSCode on va dans leur markerplace.
b- Pareil pour la correction auto, c'est pris en charge par le Protocole Langage-Server
c- Ah. La génération de doc, je dois avoir ça depuis une 15aine d'année avec Vim. C'est sûr que rappeler les types est une faible plus-value. Il faut viser les choses importantes comme les contrats. Avec des langages à pointeurs il est facile d'en suggérer quelques uns, c'est plus complexe à automatiser sinon.
Bref. Tout ça pour dire que si jamais tu te retrouves un jour coincée avec vim, tente d'installer un plugin qui supporte le LSP. Celui qui a le vent en poupe aujourd'hui s'appelle COC.
Ne cherche pas à noyer le poisson. Vim est incapable de naviguer dans un code ou d'ouvrir plusieurs fichiers, un point c'est tout. Sodium l'a démontré par A - B. Vim est donc responsable de la mauvaise programmation et certainement aussi du réchauffement climatique.
mmmmh, je ne sais pas pourquoi ça se fritte. Vim correspond aux besoins de certains, pas d'autres. Pour les autres, il y a d'autres outils sur le marché. Pourquoi s'écharper?
Plus généralement, j'ai l'impression que tout le monde n'utilise pas son cerveau de la même façon, et suivant qu'on a une logique qui passe d'un fichier à l'autre, ou une logique qui préfère les garder tous sous la main, Vim sera - ou ne sera pas - l'outil adapté. Pas de quoi en faire un fromage. Moi, ça ne me convient pas. Ca n'en fait pas un mauvais produit pour autant.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager