Visual Studio Code- kod hva du vil, hvor du vil

Mye har skjedd de siste årene i Microsoft innenfor utvikling og ikke minst tanken om kryss platform. .NET rammeverket samt runtime har blitt open sourcet og tilpasset å kunne kjøre på bade Linux og Mac i tillegg til Windows. Med i dette følger også introduksjonen av en IDE som er døpt Visual Studio Code. Det er ikke et produkt som per nå kan sammenlignes med Visual Studio 2015 i funksjonalitet, men heller noe som følger trenden med mer lettvekts IDEer og mer vanlige tekst editorer med litt smarthet. Visual Studio Code er gratis og tilgjengelig for nedlastning her.

Visual Studio Code er bygget på toppen av eksisterende Open Source løsninger som Atom og OmniSharp for .NET relatert smarthet som intellisense og refactoring støtte. Fokuset er å bygge en IDE med integrerte produktivitets verktøy som gjør hverdagen for en utvikler enklere. Med ting som GIT integrert vil man lett kunne committe kode. I tillegg til dette er det også bygget inn støtte for debugging i noen språk.

Visual Studio Code ser helt lik ut og oppfører seg også likt på alle 3 plattformene (Mac OSX, Linux og Windows). Noe som gjør at et team kan gjerne bestå av utviklere fra de nevnte plattformene og fremdeles dele utviklingsmiljø. De eneste unntakene er noen tastatur snarveier som gjerne reflekterer hva som er mer vanlig på den gitte plattform (Eksempelsvis CMD+<tast> på Mac kontra Alt+<tast) for en del kommandoer).

 

 

I bildene over ser man den samme kodesnutten kjørende på kryss av 3 platformer (OSX, Linux og Windows). Bildene over viser Java kode. Det finnes en del språkstøtte, med ulik grad av hva som er støttet. Java blant en del andre spark tilhører den delen som har syntax støtte. Dvs. at editoren skjønner forskjellen på de ulike elementene som gjør opp språket og gir fargekoder deretter. I tillegg gir den også text-completion for språk elementene. Men det er språkene med litt dypere støtte som viser hva som er gjort for å utvide funksjonaliteten til Atom. Med JavaScript, TypeScript og C# ser vi mye mer av det fulle potensiale.

Den største forskjellen mellom typisk vanlige Visual Studio og editorer som Visual Studio Code, Atom, Sublime og lignende er at de ikke er orientert rundt en fil som beskriver prosjektet, men heller at den viser filene som er i den katalogen man har åpnet. Man beskriver heller da i en prosjekt fil hva som skal ekskluderes av filer. Man vil kunne ekskludere alt og gå tilbake til en inkluderende modell, hvis ønskelig. Nedenfor ser man bilde av Visual Studio Code sin fil explorer.

 

Intellisense

Produktivitet for utviklere er ofte knyttet til å kunne slippe å gå rundt å huske alle API kall som er mulig, i Visual Studio sammenheng har dette blitt kalt Intellisense – dette er også kjent som code completion. I Visual Studio Code er det støtte for nettopp i en del språk og i konfigurasjonssammenhenger. Når man f.eks. jobber med pakker – f.eks. NuGet, Bower eller Node pakker får man completion direkte i editoren etterhvert som man skriver inn pakkenavn. Den vil til og med gi dette på versjon av pakken. Alt dette hentes da live fra de ulike pakkesentrene.

 

GIT

Støtte for GIT er bygget inn direkte. Til venstre er det et eget ikon for GIT. Trykker man på dette vil man se hva som har endret seg av filer og muligheten for å gjøre en commit og andre GIT kommandoer. Trykker man på filene som er markert som endret vil man lett kunne se hva som er endringen i selve editoren:

Full diff i forhold til forrige innsjekket utgave:

Øverst i høyre hjørne kan man velge en “inline” visning av differansen:

Med dette vil den samle endringene sammen i en smeltet visning som viser hva som har endret seg med farger.

I GIT delen har man muligheten til å gjøre en del kommandoer fra menyen:

Debugging

En annen viktig del for å kunne kalles en IDE er muligheten for å kunne debugge gjennom kode i en integrert opplevelse. Dette er noe som støttes for Node og Mono apps i dag.

Debugging skjer ved å benytte Command Paletten, eller en tastatur snarvei (F5).

Dersom applikasjonen ikke er satt opp for dette vil Visual Studio Code lage en launch.json fil under .vscode katalogen som inneholder konfigurasjon for netttopp dette. For en NodeJS applikasjon vil denne default filen være helt grei og du kan bare prøve å debugge en gang til.

Man vil da kunne sette breakpoints (tastatur snarveien er F9). Til venstre får man en del runtime ting synliggjort, som f.eks. variabler i det scopet man er i. Man får se call stack og ikke minst alle breakpoints man har.

Ved å la musepekeren være over en variabel i editoren får man opp detaljer om hva denne inneholder, som kan være veldig nyttig.

 

 

ECMAScript 6 (7) støtte

Visual Studio Code er fremtidsrettet og forstår seg også på ES6/7. Hvis man legger til en ny JavaScript fil.

Og deretter benytter ES6 ting som f.eks. class og extend, så får man underlinjer som sier at noe er feil. Holder man musepekeren over disse ser man at den gjenkjenner dette som ES6 syntax og forteller hva vi kan gjøre for å løse problemet.

Ved lage en jsconfig.json fil som nedenfor, vil den forstå denne syntaxen.

Vi kan da fortsette å skrive kode som nedenfor, og få intellisense for de tingene som vi allerede har lagd.

For å faktisk kompilere ES6 koden vår til ES5 kompatibel JavaScript som er det som de fleste nettleserne støtter, trenger vi noe som kalles en transpiler. Min favoritt er da det som heter Babel. Installer denne via NPM som nedenfor:

En av de geniale tingene i Visual Studio Code er konseptet om tasks. Dette gjør det veldig enkelt å sett opp et hvilket som helst byggsystem og gjøre dette let tilgjengelig for bygg. Tasks.json filen kan du lage i .vscode katalogen og legge til for Babel følgende:

Denne setter opp Babel basert på at det er en local installasjon av Babel. Hvis du kjører en global installasjon, må path fikses. Denne gjør også en output til noe som heter ../nodeDemoOutput som folder. Dette kan styres selv. Babel kan kjøres med argumentet –w, som betyr at den vil kjøre kontinuerlig og se etter endringer i filer og deretter kjøre Babel på filen som endret seg. Det betyr at når vi kjører CMD+SHIFT+B (på Mac, Windows/Linux = CTRL+SHIFT+B), så trenger vi bare å gjøre det en gang og den vil transpile alt som er. Som output kan vi se nede i venstre hjørne at det har skjedd noe:

Trykker man på dette får man opp de faktiske feilene:

 

Etter at man har fikset disse feilene og går tilbake til koden som vi har laget, så er det fremdeles understreker på koden. Den gjenkjenner til og med ting som er vanlig innenfor de ulike språkene i forhold til navngivning. I JavaScript har det om man har upper-case eller lower-case blitt noe som har betydning for utviklerne som jobber med JavaScript, noe som avgjør om hvorvidt en ting kan instansieres eller er bare et statisk object. Tar man musen over der hvor den markerer, så sier den nettopp dette:

Korrigert utgave vil da ikke ha noen feil knyttet til seg:

Øvers til høyre har man en knapp som gjør det mulig å splitte vinduet opp.

I det nye splittede vinduet kan man f.eks. legge det som er som resultat fra oppgaver vi kjører som bygging:

Ved å velge Tasks i nedtrekksmenyen kan vi se hva som skjer til enhver tid.

Hva med .NET?

Visual Studio Code støtter selvfølgelig .NET og C# prosjekter. Den støtter det å åpne Visual Studio .SLN filer hvor den gjenkjenner .CSPROJ filer i denne og laster dem. I tillegg støtter den DNX project.json filer. Og ettersom at Visual Studio Code er 100% fleksibel, kan man egentlig plugge inn hva som helst. For enkelhetens skyld skal vi benytte MONO for kompilering og debugging, men med DNX project.json fil for prosjektet. Ofte har man eksisterende Visual Studio prosjekter, og disse kan også settes opp til å bygge. På windows kan man sette opp med MSBuild direkte, mens på OSX og Linux med Mono, vil man benytte xbuild til å bygge de same SLN / VSPROJ filene.

Som med JavaScript får vi en del hjelp, faktisk enda mer enn for JavaScript takket være OmniSharp som kjører i bakgrunnen og analyserer det som skjer etterhvert som man skriver kode. Eksempel nedenfor viser at man har med using statements som ikke trengs.

Beveger man skrive markøren dit hvor det oppstår slike forslag får man ofte opp et ikon av en lyspære som vil gi muligheten til å kunne fikse problemet.

Ved å klikke på ikonet eller benytte tastekombinasjonen CTRL+. – får man opp forslag til løsning. Trykker man på dette (eller ENTER), vil den gjøre det som den foreslår.

Intellisense er også på plass for C#:

Tilsvarende som vi gjorde for JavaScript og bruk av Babel som transpiler kan man knytte opp bygg oppgaver i tasks.json filen. Nedenfor er et naivt eksempel som benytter Mono sin compiler og tar alle C# filer i katalogen man er i – bare for enkelhetens del. Her kunne man også ha benyttet DNX compileren (Roslyn) også.

Som i JavaScript eksempelet, compiler feil er lett å forstå og navigerbare:

For å kunne benytte debuggeren til Mono, så er dette også en ganske grei ting å sette opp. Nedenfor setter opp det å kunne debugge rett inn og muligheten for å kunne attache til en kjørende debug-bar prosess:

Man får da som i JavaScript breakpoints med variable, call stack alt som man forventer av en moderne debugger.

Det finnes også et debug console som minner om immediate vinduet man har i den vanlige Visual Studio:

Her kan man da kjøre kode ad-hoc i forhold til den konteksten man befinner seg i.

 

 

Konklusjon

Visual Studio Code er langt unna å kunne være det som den vanlige Visual Studio er i dag – men det er heller ikke formålet per dags dato. Målet er å ha en lettvekts IDE som lar deg fokusere på koden din og veldig lite annet. Det er Visual Studio Code veldig flink til. Bygget på ting som allerede er godt etablert og godt vedlikeholdt i Open Source communitien, vil det være lettere for våre utviklere å fokusere på å lage ekstra funksjonalitet på toppen og ikke minst kunne gjøre det så raskt som mulig. Jeg personlig har ventet lenge på at dette skulle skje. Selv om jeg har gjennom årene benyttet meg av ulike andre editorer som Sublime Text og TextMate på Mac, og har også brukt MonoDevelop / Xamarin Studio når jeg har hatt behov for å gjøre .NET på andre plattformer enn Windows, så har allikevel det vært en liten underbevisst lengsel om å få Visual Studio over fremfor å benytte disse. Jeg merker at jeg smiler for hver dag som går som jeg blir mer og mer kjent med denne lille krabaten og kommer nok til å benytte mer av min tid her enn andre steder fremover.