J’utilise VSCode
J’ai vraiment du mal à m’en remettre, et j’ai des proches qui utilisent Vim et ne sont pas toujours encore à l’aise avec l’idée. J’ai refusé d’utiliser Visual Studio à de nombreuses reprises, alors tester son petit frère était déjà un pas osé. Un truc Microsoft. Un truc écrit en Javascript.
Mais bon, j’aime ça, et il faut pas avoir honte de qui on est.
Le fait que ce soit libre et multiplateforme pour un produit Microsoft est surprenant, néanmoins c’est le maintien continu de l’excellent comportement de la team derrière qui est le plus bluffant: respectueux, proche des utilisateurs, sans bullshit…
Le fait que ce soit facile à installer et utiliser pour un projet javascript est surprenant, néanmoins c’est l’excellente performance du produit qui est le plus bluffant: temps démarrage, réactivité du scroll, gestion de gros projets…
Alors j’ai continué à le garder sous le coude, en parallèle à Sublime Text.
Et quelque chose de subtil a changé, chaque jour, sublime dont j’ai pourtant payé la licence, me faisait de moins en moins bander. Je sollicitais de plus en plus VSCode. Jusqu’à ce que ça devienne mon éditeur par défaut.
Oh, ST et moi on se voit toujours. Pour ouvrir un petit fichier vite fait, taper un article, tester un truc.
En revanche dès que c’est un projet, j’ai un éditeur Electron made in Redmond pour ça, et il me rend heureux.
L’ergonomie de la bestiole
Les auteurs de VSCode ont pompé tous les éditeurs les plus populaires, goulûment. Ils ont optimisé le temps de démarrage à mort, et même si on n’a pas la vitesse d’un ST ou d’un Vim, ça reste moult fois plus rapide que la vaste majorité de la concurrence. Pas de splash screen à rallonge et ce moment de doute où on n’est pas sûr d’avoir vraiment cliqué sur le bouton. J’aime bien Jetbrain mais le startup de PyCharm me fout les boules à chaque fois.
Côté apparence, on retrouve des lignes épurées avec peu de boutons, des tabs, la fameuse bird view du code de ST, un Head Up Display, une statut-bar très riche et le “go to anywhere” que tout le monde adore depuis Mate.
La force de VSCode c’est l’expérience de son équipe : ils ont bien compris ce que les utilisateurs faisaient le plus souvent, et l’ont mis à porter de main. Un clic pour faire un split view ou afficher le terminal intégré. Mais pas de fonction “Imprimer”. Une barre latérale donne l’accès à 4 autres modes, un pour la recherche dans tout le projet, un pour git (et rien d’autre), un pour le debuggeur intégré, et un pour installer des extensions.
Une foule de choses sont configurables, avec une interface qui mélange fichiers de config et aide à la saisie. C’est étrange la première fois qu’on met le nez dans “paramètres de l’utilisateur” ou “ouvrir les raccourcis clavier”. Ni vraiment une fenêtre avec des formulaires. Ni vraiment un JSON à éditer à la main. Un peu des deux. Et c’est super bien fait.
Ceci dit, comme les réglages par défaut sont assez sains, un junior n’aura pas à s’en soucier et pourra tout de suite commencer à introduire des bugs dans votre projet.
L’éditeur
Aucune innovation. Aucune tentative de faire différent de la concurrence. C’est du classique, c’est propre, et ça marche. On peut bien entendu choisir entre plusieurs mode de saisie (mode VI, Emarcs, Sublime, etc), mais perso je reste avec le mode original et quelques raccourcis custo.
Derrière, toutes les fonctionnalités modernes sont là: multi-curseur, sélection/recherche incrémentale, snippets (emmet inclus !), complétion des mots les plus utilisés, navigation par symbole, hot exit. L’avantage, c’est que comme VSCode joue la carte de l’interface minimaliste, on n’a pas besoin de connaitre tout ça, et on peut juste commencer à taper, tout en apprenant chaque feature au fur et à mesure de ses progrès. C’est un excellent éditeur pour débutant en ce sens. Mais les powers users qui aiment malgré tout la souris et les onglets y trouveront leur compte.
La coloration syntaxique est irréprochable (heureusement), mais on voit qu’ils ont du faire des concessions. Par exemple au démarrage, seule la partie de votre viewport est colorée. Il faut attendre une à deux secondes sur les gros projets pour que le reste du fichier le soit, histoire de pas freezer tout le bouzin.
Le bon côté de ça c’est que c’est très fluide. Bon évidemment j’ai 8 coeurs et 32Go de RAM. J’ai tenté l’aventure sur une VM avec 2 de rames et un tout petit coeur, et c’est pénible. Au repos avec quelques tabs ouverts, le truc s’engouffre quand même ses 700Mo de mémoire vive. N’oubliez pas que c’est du V8 derrière.
En comparaison ST en bouffe 300, et Vim, heu, LOL.
Intégration Git
L’intelligence de cette feature, c’est qu’ils se sont limités aux opérations simples et courantes. Permettre de naviguer dans l’espace temps ou de lancer son merge --rebase, c’est dur à faire correctement. Donc VSCode n’essaye pas.
Il affiche juste la liste des fichiers qui sont modifiés et/ou en staging, permet de les bouger de l’un à l’autre ou annuler les modifications, et de faire un commit rapidement. Un clic sur un fichier l’ouvre en mode diff avec HEAD. C’est tout.
C’est pas 1% de ce que permet de faire Git.
Mais c’est facilement 69% de mon usage de Git. Du coup c’est super pratique. Combiné avec le terminal intégré, et vous pouvez gérer presque tout le repo sans sortir de l’éditeur.
Le debuggeur
Je ne l’utilise jamais et je préfère ipdb. Pour le moment, en Python, il est trop lent. Les devs JS en disent du bien, vu qu’apparemment il est capable de se connecter directement au navigateur et comprend TypeScript de manière transparente.
La recherche
Rien à dire. C’est rapide. Ça marche. Ça supporte les trucs les plus importants: case insensitive (activé par défaut), regex, in sélection, dans tous les fichiers, filtrés par extension, et tout le bordel. Cliquer sur le résultat ouvre le fichier à la bonne ligne. Pas de modale qui bloque l’UI.
Pas de surprise, donc. Mais pas de mauvaises surprises.
L’indexage est configurable par projet, ce qui est indispensable dès que vous avez quelque chose d’un peu complexe.
La recherche de fichiers par nom est absente puisque ferait doublons avec “Go To Anywhere”.
Intégration des langages
Là, on attaque la partie intéressante. VSCode est neutre dans son traitement des langages, et toutes les features avancées se font donc via des extensions. L’astuce, c’est que l’équipe supporte officiellement certaines extensions, et elles sont donc d’excellente qualité.
Le support de Python est phénoménal. C’est simplement le meilleur après celui de PyCharm (et de pas beaucoup), ce qui n’est pas peu dire, vu que Jetbrain fait probablement des messes noires et des sacrifices à Quetzalcoatl pour obtenir ce résultat.
Python est notoirement difficile à outiller de par son très grand dynamisme.
Mais là, c’est beau.
Pylint est activé par défaut, et flake8 ainsi que mypy sont optionnellement activables. Leurs préréglages sont de bonne qualité, particulièrement celui de mypy qui est normalement inutilisable out of the box. L’éditeur vous prompte pour l’installation quand il détecte qu’ils sont absents, et lance tout ça pour vous.
Tout est configurable par projet, et donc si vous spécifiez un virtualenv pour votre projet (ce qui vous devriez toujours faire), VSCode va détecter que les outils ne sont pas dedans, vous proposer de les installer, et le faire pour vous.
Du coup, bénéficier des types hints, de la détection des erreurs de syntaxes, des variables non déclarées et des imports manquants ou inutiles est beaucoup plus facile que sur n’importe quel compétiteur. Ok, sauf PyCharm. Mais personnellement je l’appelle PyChiderme.
Si VSCode ne supporte pas nativement un outil, il existe probablement une extension pour ça. Par exemple, il y a une extension pour black, qui est à Python ce que Gofmt est à Go, et que j’installe donc maintenant à chaque nouveau projet.
L’intégration de ces outils est excellente :
- Les linters de Python sont naturellement lents, mais VSCode les lance en asynchrone et ça ne ralentit pas son UI.
- L’affichage des erreurs est claire, mais discret. Ça limite l’effet sapin de Noël.
- à côté du terminal intégré existe une fenêtre qui liste toutes les erreurs par fichier. On peut ainsi parcourir son projet erreur par erreur.
VScode m’a même surpris à détecter mes tests unitaires, m’a proposé d’installer pytest puis de lancer tout ça.
Cependant, pour vraiment parler de l’intégration de Python dans VSCode, il me faut mentionner IntelliSense. C’est un terme marketing inventé par MS pour caractériser toutes les fonctionnalités autour de la compréhension que l’éditeur à du code, et des opérations qu’il propose dessus.
Ok, ok, c’est un mot 100% bullshit.
Mais bordel, ça marche.
La complétion du code est excellente, et marche sans aucun réglage. Avec la lib standard bien entendu, mais aussi avec votre code, et toutes les libs installées dans votre virtualenv (si vous avez précisé le chemin vers ledit env dans les settings du projet, of course, il est pas devin).
VSCode affiche les docstrings, les params et propose d’aller à la définition de n’importe quoi en un clic.
Et si comme moi vous avez passé un temps fou à essayer d’obtenir le même résultat sous ST/Vim/Whatever en chargeant what mille plugins et en changeant 600 valeurs de configs, vous comprendrez que c’est juste, topissime.
Quelques infos
Les réglages de VSCode de base sont bons. C’est vraiment une partie de ce qui fait la force du projet: moins de bordel à faire soi-même. Mais comme il est bien configurable, il ne faut pas s’en priver. Quelques trucs que je fais toujours:
Installer une police avec des ligatures
Genre Fira-Code.
Et activer les settings:
"editor.fontFamily": "'Fira Code', 'Droid Sans Mono', 'Courier New', monospace, 'Droid Sans Fallback'", "editor.fontLigatures": true, |
Exclure plein de fichiers
J’ai pas du tout envie que “Go to anywhere”, la recherche des fichiers ou l’indexage git charge des trucs inutiles. Donc j’ai des settings de base de nazi:
"files.exclude": { "**/.git": true, "**/.svn": true, "**/.hg": true, "**/.DS_Store": true, "**/dist": true, "**/build": true, "**/env/**": true, "**/venv/**": true, "**/virtualenv/**": true, "**/node_modules": true, "**/bower_components": true, "**/vendors": true, "**/__pycache__": true, "**/**/*.pyc": true }, "files.watcherExclude": { "**/.git/objects/**": true, "**/node_modules/**": true, "**/build/**": true, "**/dist/**": true, "**/env/**": true, "**/venv/**": true, "**/virtualenv/**": true, "**/bower_components/**": true, "**/vendors/**": true, "**/__pycache__": true, "**/**/*.pyc": true }, |
Mes settings par projet sont généralement encore plus restrictifs.
Je change les params de zoom
"window.zoomLevel": 2, "editor.mouseWheelZoom": true, "editor.fontSize": 10, |
Je vire la télémétrie
Je suis pas sous Windows 10, merde.
"telemetry.enableCrashReporter": false, "telemetry.enableTelemetry": false, |
Je mets des barres verticales
"editor.rulers": [ 79, # PEP8 88, # Black 120 # Javascript ], |
Ergonomie perso
"editor.renderWhitespace": "none", # overridé par projet "editor.renderIndentGuides": true, "editor.minimap.enabled": true, "editor.minimap.renderCharacters": true, "editor.autoIndent": true, "window.restoreWindows": "all", "window.openFoldersInNewWindow": "on", "editor.acceptSuggestionOnEnter": "off", "editor.tabCompletion": true, "emmet.triggerExpansionOnTab": true, |
Pour un Python heureux
"python.venvPath": "~/.local/share/virtualenvs/", "python.linting.mypyEnabled": true, "python.linting.enabled": true, "python.pythonPath": "/usr/bin/python3.6", # je l'override dans les settings de projet "black.path": "/home/user/.local/bin/black", # black a besoin de Python 3.6 "python.formatting.provider": "none", # pour black "editor.formatOnPaste": true, "files.associations": { ".pylintrc": "ini" }, "python.linting.flake8Enabled": true, "python.unitTest.pyTestEnabled": true, "python.linting.pylintEnabled": true, |
J’installe généralement ces extensions
- Python. Logique.
- Color highlight pour que les code hexa soient surlignés avec la couleur qu’ils représentent.
- Black, parce que je ne veux plus jamais reformater du code manuellement de ma vie.
- Django template et jinja, pour un meilleur support des templates django et jinja en coloration syntaxique.
- Editor config parce que j’ai toujours un .editorconfig à la racine de mes projets.
- gitignore, systemd-init-file, restructured text afin d’avoir la coloration syntaxique pour eux aussi
- path intellisense, comme ça j’ai la complétion sur les chemins de fichier.
- Rainbow CSV, qui affiche chaque colonne d’un CSV dans une couleur différente.
- git history pour afficher l’historique d’un fichier ou d’une ligne.
Astuces utiles
VSCode vient avec les raccourcis traditionnels des éditeurs graphiques:
Il possède aussi quelques trucs sympas dont on parle moins dans les tutos:
- clic milieu active la sélection verticale
- Dans un shell,
code -rouvre un fichier dans la fenêtre en court, etcode -ndans une nouvelle fenêtre.code --diff foo barouvre les deux fichiers en mode comparaison. - Dans un projet, le fichier
.vscode/tasks.jsoncontient la configuration des taches à lancer. Compilation, tests unitaires, debuggage, serveur… On peut lui faire faire n’importe quoi. - “Join line” n’a aucun shortcut par défaut. C’est une opération courante, donc je vous conseille de la mapper. Perso je la mets sur
ctrl +j . Ctrl +Shift +O permet de se déplacer vers n’importe quel symbole. C’est pratique, mais personne ne s’en souvient jamais. Plus facile à retenir: faire un “go to anywhere” (ctrl +P ) et commencer la recherche par@. Ou@:pour regrouper les symboles par nature (classes, fonctions, etc). Le “go to symbole” marche sur tout le projet avecCtrl +T , mais c’est lennnnnnnnnnnnt.- De la même manière, on peut aller à un numéro de ligne avec
Ctrl +G :. Ou depuis un terminalcode file.ext:numligne Ctrl +U ctrl +d de trop”.Ctrl +k +ctrl +f appliquer le formateur à la sélection. Pour les gens qui ont des TOC.- VSCode a une preview pour le markdown. Facile à lancer depuis le HUD
- Une fois que vous avez pris l’habitude d’utiliser “go to definition” dans le menu contextuel, sachez que
ctrl + clic fait pareil :)
Un snippet perso que je rajoute également (dans $HOME/.config/Code/User/snippets/python.json):
"wrap_in_try_except": { "prefix": "try", "body": [ "try:", "\t${0}${TM_SELECTED_TEXT}", "except ${1:Exception}:", "\t${2:import pdb; pdb.set_trace()}" ], "description": "Wrap in try/except" }, |
Ça permet de sélectionner un truc, de taper try puis tab et avoir le tout wrappé dans un try/except.
Le futur
Depuis sa sortie, l’éditeur est en constante amélioration. Les mises à jour sont toujours une excellente surprise, avec des tas de goodies, y compris dans les extensions.
Mais là, dans la dernière version instable (qui a la bonne idée de ne pas overrider la stable à l’installation), VSCode vient avec une preview de l’édition collaborative. Genre Google doc, mais pour le code, et dans tout l’éditeur.
La partie chiante, c’est qu’il faut un compte (Microsoft évidemment), et donc que ça passe par leurs serveurs.
La partie amazing par contre, c’est que ça envoie du poney nucléaire. L’ouverture des onglets, l’écriture, le scroll… Tout se synchronise proprement. Si on décide de faire sa vie, VSCode désynchronise la navigation, et permet à tout le monde de travailler en parallèle sur le projet (et même optionnellement donner accès à son terminal). Si on veut de nouveau voir la navigation de l’autre, on peut demander de le suivre à nouveau, et pouf, on suit ce qu’il fait en live.
Testé avec des clients à des milliers de borne. C’est bluffant.
Cool… je voulais l’utiliser pour d’autres langages que Python (go, c, c++…), ça doit pas être mal non plus.
Pas de raison réelle de changer pour les charmeurs de serpents donc.
Une fois que tu as tout setup, tu veux synchroniser tes settings (y compris tes extensions et leurs configs) entre tes différentes machines, eh bah il y a une extension pour ça (basé sur les gists, donc compte github obligatoire), et elle marche superbement bien, c’est indécent:
https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync
Ce qui me dérange, ce n’est pas tant le logiciel en lui même qui m’a l’air bien mais plutôt Crosoft et sa politique de confidentialité et sa licence dans laquelle on peut lire :
“DATA. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. There may also be some features in the software that enable you to collect data from users of your applications. If you use these features to enable data collection in your applications, you must comply with applicable law, including providing appropriate notices to users of your applications. You can learn more about data collection and use in the help documentation and the privacy statement at http://go.microsoft.com/fwlink/?LinkID=528096&clcid=0x409. Your use of the software operates as your consent to these practices. ”
Ça me gène quelque peu aux entournures…
Ouai, c’est pour ça que je désactive la télémétrie. Vu que VSCode est open source, on sait ce qui entre et ce qui sort, et que ce switch fait ce qu’il dit. Par contre, si tu compile quelque chose avec Visual Studio (qui a la même clause licence) et .net, ton executable va inclure leur code de télémétrie par défaut. Chaud.
Faut pas se leurrer, Microsoft s’est pas soudainement greffé une morale.
Effectivement, tant de réticence avant d’essayer, et finalement tellement bien, ce VSCode (mais effectivement, MS ne se refait pas ; par exemple avoir l’audace d’appeler l’exécutable « code » — dans la version Linux, en tout cas — ça m’a bizarrement et sans raison chiffonné) !
Et pour le contenu de cet article :
Oh !
Ctrl+ U.Ctrl+ U!Merci merci merci….
Ancien utilisateur convaincu de vim, je l’ai relégué à un usage ponctuel quand je dois passer par ssh ou éditer un fichier très rapidement en sudo par exemple, parce que c’est incroyable à quel point vscode (ou code, ou code-oss) est bon, et sur ce quasiment tous les points.
Avec l’extension Vim installée, cela va de soit.
Et merci pour le Ctrl + U, celui là il fait plaisir à apprendre.
ça me rassure de voir que je ne suis pas le seul à avoir flashé sur cet éditeur ! Par contre pour python je n’ai pas encore fais le switch pycharm => vscode. Par flemme avant tout de devoir tout paramétrer (ouais le confort d’une usine qui te bouffe la moitié de ta ram ne se discute pas). Pour le reste et faisant beaucoup de vuejs, je dois dire que de base sans rien paramétrer ça marche juste !
Question naïve mais le fait que ce soit MS derrière tout ça ce n’est pas la porte ouverte à une restriction petit à petit des possibilités et de la maintenance pour migrer à terme vers quelque chose de payant ?
On peut prétendre au fork avant privatisation vu que c’est ‘open source’ mais la fiabilité dépendra de l’équipe qui forkera.
Merci pour le retour.
Lors de la formation “Apprendre Python – Qualité de code et maintenance” je suis tombé de ma chaise quand j’ai compris qui était derrière l’éditeur.
Je débute en Python, j’ai longtemps utilisé Geany pour passer à Atome.
Merci pour vos articles et formations qui font références pour moi.
Bonne continuation.
Je suis tombé raide dingue des performances et il y a de bonnes idées dans cet IDE comme l’onglet de fichiers modifiés. Le loading ne peut faire que bander comparé à Pycharm… Mais… Quand on s’est habitué à l’intégration git de Pycharm, la gestion des dbs (et ne me dite pas y’a un plugin, car j’ai essayé les 2 proposés pour mysql et c’est le moyen âge) , la possibilité de commiter partiellement un fichier, le reformatage de code, la recherche… Très difficile de faire le retour arrière même en cherchant des équivalences souvent inexistantes ou pas encore très abouti. Pycharm offre la version pro pour les projets opensource, et sans ça vu le niveau du soft ça fait juste kiffer de donner de l’argent pour un tel produit. Pour moi qui fait 10h de Python et de TS (Angular) par jour, difficile de me passer de l’artillerie Pycharm… Ou alors c’est parce que je vieillis… :p
Je comprends pas l’argumentation du temps d’ouverture du soft pour PyCharm.
J’ouvre mon PyCharm une seule fois, et j’ouvre ensuite les 2 (ou max 3) projets sur lesquels je bosse.
Ensuite mon mac n’est jamais éteint (sauf soucis), et PyCharm reste ouvert.
J’ai un mac Retina 2013, 8Go de RAM. Ca tourne proprement.
Je fais du Django et de l’Angular.
Y’a t’il donc une VRAIE raison de faire l’effort de switcher sur VS code ? (j’veux dire, un truc que vraiment PyCharm ne fait pas ou fait trop mal) si j’en ai rien à battre que PyCharm consomme plus de RAM qu’un autre ?
PS : je suis totalement contre utiliser des plugins externes car pour l’avoir fait sur Sublime, ça finit toujours par merde (untel ne met plus à jour son paquet, tel plugin fait merder tel autre, etc.)
Avoir tout géré par un éditeur (sérieux) est selon moi bien plus intéréssant.
@Abject: oui.
@JC: :)
@Johaven: non, tu ne vieillis pas, pycharm est tout simplement un excellent produit.
@Walt: c’est le boulot de personne de te convaincre. Tu as les infos, maintenant à toi de voir si tu testes ou pas. Nous on s’en branle un peu en fait, notre tache c’est juste de partager ce qu’on sait.
Ça a l’air très cool effectivement, mais comme le dit Jerry Wham, le EULA a l’air douteux, et je pense que désactiver la télémétrie n’est pas suffisant.
Il va falloir attendre qu’une âme charitable fasse un build nettoyé de toutes les cochonneries de Microsoft !
@Sam: Tu sais parler aux gens :D
@Sam: Justement je reste un peu sur ma faim, même si j’en apprends beaucoup dans l’article. En gros, pour résumer, je lis “ça c’est stylé, mais comme dans PyCharm”, ou bien “ça c’est presque aussi stylé que PyCharm”.
D’où ma question qui en était vraiment une : au delà des performances (on est tous d’accord que c’est le point noir de PyCharm), y’a t-il selon vous une raison majeure de faire le switch ? Vous pouvez répondre “NON”, je veux juste savoir si je passe à côté d’un point essentiel.
“T’as qu’à essayer” me dira t-on. Mais justement, si j’investis plusieurs jours pour apprendre à utiliser un nouvel IDE, idéalement ça serait pour le garder in fine. C’est pour ça que j’essaie d’être convaincu avant utilisation (même si c’est le job de personne, j’en conviens bien).
Bisous quand même hein.
Sérieux, guys, Atom n’est-il pas la réponse à absolument tous nos besoins ? Depuis 20 ans j’ai utilisé tous les éditeurs du monde, avec une grosse douzaine de langages, dans plein d’environnements et pour plein de usecases différents. Atom est pour moi ce qui se fait de plus efficace.productif/élégant/évolutif. VSCode c’est bien, mais on est quand même à des ordres de magnitude derrière…
@Walt : n’etant jamais passé à PyCharm, je ne peux pas te donner de raison de switch. Je n’utilise pas pycharm. Il est trop lent pour moi. Son interface est surcharchée à mon goût. Avoir un support décent pour plus d’un langage est très cher. Je trouve son ergonomie moins bonne, dans son UI, ses menus et ses modes de sélection ainsi que sa symboologie graphique. Je continue de taper ctrl + P et ctrl + shift + p à chaque fois que je l’utilise en vain. Mais quelle importance ? PyCharm est un excellent logiciel, et personne n’a besoin que tu passes à VSCode. Reste sous PyCharm.
Tu fais chier à cause de cet article j’ai installé VSCode.
C’est vrai que c’est pas mal, la masse de plugins est indécente.
Après j’ai testé des plugins vim (on se refait pas, je ne sais plus utiliser que ça), et je comprends pas pourquoi il surcharge mon key mapping. Genre j’ai échangé capslock et esc (un grand classique), et sur VSCode quand j’appuie sur l’une des deux touches ça me fait l’effet des deux. C’est marrant 5 minutes. Puis je suis retourné à vim et à pycharm/IdeaVim (plugin moyen mais qui marche)
C’est bien ce que j’ai toujours dit, les IDE c’est pour les gays. J’en suis désormais certain ;)
Bisous, bande de suceurs de noeuds ;)
Parmi les extensions, une me paraît assez original et utile pour sortir du lot : “Bracket pair colorizer“. Ça met en couleur les parenthèses, crochets, accolades qui sont appairé, c’est plutôt chouette !
Je viens de le tester, ben c’est super sympas.
Merci pour cet article et pour tous les autres.
multiplateform > multiplateforme
ce moment de doute où on n’est pas sur > ce moment de doute où on n’est pas sûr
black, qui est a Python > black, qui est à Python
L’affichage des erreurs est claire > L’affichage des erreurs est clair
sapin de noel > sapin de Noël
git history pour afficher l’histoque > git history pour afficher l’historique
ctrl (+shift) pour se balader (selectioner) > ctrl (+shift) pour se balader (sélectioner)
click milieu active la sélection verticale > clic milieu active la sélection verticale
sachez que ctrl + chlick fait pareil > sachez que ctrl + clic fait pareil
J’utilise vscode pour avoir un IDE decent pour faire du php, PyCharm reste mon IDE de référence en python…
Dans pycharm, on peut mettre un “project root”, qui correspond à la racine des sources “project”: pour moi, c’est dans un dossier “src”.
Comment on fait ça dans vscode ?
Hello,
Quels sont sous VSCode les raccourcis pour ouvrir/fermer toutes les accolades (brackets)?
Pour la mise en forme automatique du code peut-on choisir/définir sont style?
Moi j’aime bien (pas taper) ça:
else
{
….
Sauf erreur de ma part (les problèmes de licence sont toujours complexes) attention si vous installez les binaires depuis le site officiel, ce que vous utilisez n’est pas open source.
This license applies to the Visual Studio Code product. The source code is available under the MIT license agreement. Additional license information can be found in our FAQ.
Le code source est open source. Le binaire que vous récupérez est sous MICROSOFT SOFTWARE LICENSE TERMS.
@frague : faut une extension. Ex: https://github.com/alefragnani/vscode-project-manager mais y en a d’autres
@Yann : Pour la mise en forme automatique du code peut-on choisir/définir sont style? Tu peux plugger different formatter (autopep8, yapf, black, etc). Black n’a aucune réglage et tu n’as aucune choix (c’est le but affiché), et pour cette raison est mon choix favoris: ça évite que dans les meetings il y ait un débat sur le style. Tout le monde à un goût, et personne n’est le meilleur, donc on froissera forcément quelqu’un. Donc vaut mieux un truc arbitraire pour tout le monde. Si tu travailles tout seul et que ton style est très custo, yapf est très configurable.
J’ai aucune idée de ce que tu veux dire par là. Les accolades sont auto fermées à la saisie.
@Carl Chenet: bien vu
trolldi #PyCharm #mypy c’est BDFL kiledi https://twitter.com/gvanrossum/status/1001869119937961984
D’où ma question qui en était vraiment une : au delà des performances (on est tous d’accord que c’est le point noir de PyCharm), y’a t-il selon vous une raison majeure de faire le switch ? Vous pouvez répondre “NON”,
Non, pas vraiment. Après c’est comme avec ta femme, des fois faut aller voir ailleurs pour se rendre compte qu’en fait c’est pas si mal.
@=°.°= j’utilise aussi de plus en plus vscode et je viens d’emacs. J’ai mappé ma touche CapsLock en touche de crontrôle supplémentaire et ça ne fonctionnait pas jusqu’à ce que je rajoute la clé de config suivante :
"keyboard.dispatch": "keyCode"
Merci @Nicolas je vais essayer pour ma culture
Bonjour,
je suis toujours intrigué par les gens qui arrivent à coder sur leur machine en local. J’ai toujours eu plein de contrainte. Principalement les données, sync de la db, flux uniquement sur la plateforme en ligne. Mais aussi l’idée d’avoir sur mon laptop du code potentiellement confidentiel me stresse. Bref j’ai toujours codé en remote. Au moins je suis sur que tout est bien backupé aussi. Malheureusement le seul éditeur de code qui permet de faire ça c’est vim. Et vim un peu tuné c’est quand même vraiment top. J’aurais bien partagé ma conf mais j’ai fermé mon compte github récemment :)
bien à vous
oau
Si tu dois coder sur un env live, il y a un problème plus grave que le choix d’un éditeur.
La majorité des codes ne sont pas confidentiels. Mais même si c’est le cas, une partition chiffré et un repo git sont de toute façon une bonne pratique.
Sous linux n’importe quel server remote peut devenir une partition locale, et donc permettre à n’importe quel éditeur de travailler en remote.
Vim est un bon éditeur, personne ne le nie. Mais aucune de tes raisons d’utiliser vim n’a quoique ce soit à voir avec vim.
Ce n’est pas l’endroit pour le faire.
Il y a moult pastebins
Nulle part je dis que je code sur un environnement live. Quand je dis “flux de données uniquement en ligne” c’est seulement que je reçois les données à un seul endroit. Flux de données qui arrive en temps réel sur des serveurs d’interfaces qui ventilent les données sur 3 env. Dev, recette et prod et chaque dev à sa propre vm avec son flux de données (mqtt pour l’annonce de l’arrivé des fichiers et fichiers stocké dans ceph). On merge en dev. Les fonctionnels recettent en recette et après on passe en prod. On a donc 3 env exactement identiques. Même conf, même os, même environnement. Seul change la taille et le nombre des vm et l’adressage réseau. Pas de surprise de passage en production.
Notre code est notre valeur ajouté donc on préfère le garder secret. Et effectivement il est dans un git interne et sur une partition chiffré. (gitlab et ceph)
Encore faut il que les données soient sur une partition. La plupart de mes données sont en base et je n’ai pas envie de rsync plusieurs giga de données pour faire tourner notre code. Le reste arrive en mqtt et stocké dans l’object store de ceph
Quand j’ai un nouveau dev qui arrive je lui clone la machine type (vive ceph) et il a son env de dev configuré et prêt à bosser.
J’ai effectivement des dev qui préfère Sublime Text et VSCode ou les data scientist qui utilisent RStudio ou Anaconda. Eux passe par une session X2Go. Mais je trouve que même avec la fibre ça rame.
Et enfin la machine en remote sera toujours plus puissante, moins chère, plus perenne (c’est pas moi qui change les disks) que une machine en local qui est dans ce cas juste un terminal. Comme mon téléphone d’ailleurs. Et de n’importe ou, j’ai accès à tout mon env de travail.
Après j’ai cette habitude depuis toujours et j’aurais mal à m’en passer. Peut être devrais je.
ma conf vim.
https://0bin.net/paste/jGOmC-iCvmbYB2Hn#C3iywEQ3XRTAoOA0yzSxfnL8V3lmx+Ear6Afk5fYCLd
Bon, je fais mon coming out aussi !
J’utilise Atom.io propulsé par github lui-même racheté par Microsoft dernièrement.
Shameless plug: Juste pour la petite histoire, j’en ai eu marre du support de la syntaxe approximative des templates Django, donc je me suis sorti le plug du cul et je me suis penché sur le tmLanguage jusqu’à arriver à un truc satisfaisant. La syntaxe des tag/variable/filters est maintenant meilleure et dispo dans plus de contextes (par exemple dans les “id” et “class” HTML).
Je vais ajouter plus de snippets et autres goodies cette semaine.
https://marketplace.visualstudio.com/items?itemName=batisteo.vscode-django
Pour ma part je l’ai trouvé génial jusqu’au moment où je remarque un certain pylinterjsaispasquoi qui me prend 101% du CPU et 16gb de RAM, je passe.
j’ai perso rajouté un
"editor.wordWrap": "on",Pour que le texte aille à la ligne tout seul, je préfère ^^.
@batisteo: superbe
@Phrk : si un linter t’emmerde, le bug est indépendant de VSCode (tous les linters sont des projets Python celèbres). Deux solutions, soit trouver la cause (ça peut être vite relou, mais c’est souvent un dossier de projet mal configuré et donc trop gros), soit disable le linter (3 secondes dans la conf de vscode, et y a 2 autres linters alternatifs si envie/besoin).
Bon bah voilà… merci samémax hein… :-P
:-*
à porter de main -> à portée de main
plusieurs modeS de saisie
avec 2 de rames -> avec 2 Go de RAM
L’affichage des erreurs est claire -> L’affichage des erreurs est clair
compréhension que l’éditeur à du code -> compréhension que l’éditeur a du code
dans la fenêtre en court -> dans la fenêtre en cours
taches -> tâches
milliers de borneS
ça devrait s’améliorer encore: https://blogs.msdn.microsoft.com/pythonengineering/2018/07/18/introducing-the-python-language-server/
Intellisense est probablement la partie la plus chouette de VS, alors c’est beau de l’open sourcer.
J’essaie d’utiliser pylint mais il me sort beaucoup trop d’output qui ne sert à rien (par exemple il me dit de mettre une docstring à mes fonctions main). Après je suppose que c’est fantastique une fois que c’est pris en main (idée d’article potentielle ?). Par curiosité, tu pourrais partager ton fichier .pylintrc, histoire d’avoir une idée de quels codes d’erreurs tu ignores typiquement ?
Je custo le pylintrc sur chaque projet car ca depend de la team et de la forme du code.
Petite précision: black est maintenant auto-inclus dans l’extension python, plus besoin de l’installer. Il faut donc mettre “python.formatting.provider: ‘black'”. Et je suis particulièrement fan de “editor.formatOnSave: ‘true'” pour ne plus jamais avoir à penser au formattage de sa vie.
Également, comme extensions que beaucoup de personnes trouveront utiles:
-coderunner pour lancer n’importe quel snippet (au milieu d’un fichier, dans la barre d’exploration, la sélection curseur, etc.) à la volée
-vs-icons pour faire joli
-importmagic pour ne plus jamais avoir d’ImportError
-le language pack français
Je ne suis pas développeur (ingénieur système Linux) mais je code régulièrement en plusieurs langages (en ce moment Flask) pour divers projets personnels ou professionnels (shell, Ansible, Saltstack, Python, PHP, etc…). Du coup j’utilise VSCode (j’ai laissé VIM) et j’ai développé l’outil VSCode-Anywhere qui permet l’installation de VSCode sur Linux / Windows sans être administrateur du serveur et de façon portable (sur un périphérique USB par exemple).
Ce outil va télécharger / installer pour vous un écosystème pour faire fonctionner votre langage préféré.
Par exemple pour Python il suffit d’activer Python (et vos paramètres si besoin) dans le fichier de configuration et de relancer une installation. L’outil va alors installer Python2/3, les modules pip, configurer les settings dans VSCode, télécharger la documentation associée, etc…
Il ne vous reste plus qu’à coder ;)
L’outil n’est pas parfait mais je l’améliore dès que j’ai un peu de temps ;)
En espérant que ça puisse aider certains :)