bloghoved sidsel jensen

Hvilken kodeeditor bruger du?

Intet spørgsmål kan vist være mere farligt at starte en diskussion med - det svarer til at træde ind på mineret grund oplyst af store flashende “enter at your own risk“ skilte…

Det er i bund og grund et simpelt spørgsmål, som i IT kredse er topmålet af den store diskussion om hvilken farve cykelskuret skal males i.

Men altså en kodeeditor er et vigtigt værktøj i dagligdagen og kan betyde alpha og omega, når man skal have noget lavet i en ruf. Så nu springer jeg alligevel ud i det og håber ikke det ender i den store ”editor-deathmatch” i kommentar-sporet.

Blandt Sysadmins falder folks editor-valg typisk i 4 kategorier:

  1. Diehard emacs-fanbois
  2. Diehard vim-fanatics
  3. Nyere editorer f.eks. Atom eller Sublime
  4. “Whatever is available”

Fornyelig lavede en af mine gamle venner hvad jeg karakteriserer som et Facebook “klynke” opslag - hans nuværende chef havde formastet sig til at bede ham om at bruge en af de nyere editorer (Atom), fordi resten af teamet brugte den editor. Han har brugt vi(m) i noget der ligner 20 år og han kunne absolut ikke være lige så effektiv i en ny editor, som han skulle bruge tid til at sætte sig ind i.

Han var i “det-kan-man-simpelthen-bare-ikke-bede-sine-medarbejdere-om-rasmus-modsat-humør”.

Det havde den stik-modsatte effekt på mig - jeg blev nysgerrig - og fik kort tid efter installeret Atom, bare for lige at checke ud hvad den kan. Atom er lavet og vedligeholdt af github og det er en fri og open source kodeeditor til OS X, Linux og Windows. For mig ligger vi(m) kommandoerne stadig i fingrene, men Atom er utrolig nem at komme igang med.

Folkene bag kalder den selv for “a hackable text editor for the 21st century”.

Både Atom og Sublime er feature-tunge og de har begge support for utrolig mange forskellige pakker (extensions). Atom er git-aware, så dine filer bliver farve-kodet i din katalog træ-struktur over projektet alt efter om der er rettelser i filerne.

Atom logo
sublime text logo

Du kan også nemt se hvilken branch du arbejder på i status-baren i bunden. Atom har mulighed for multi-line cursor - så du kan rette flere linier på en gang. Den har selvfølgelig support for både Emacs mode og Vi(m) kommandoer.

En niftig feature er muligheden for at få automatisk foldet kode blokke (altså collapse af store blokke), der nogen gange kan forstyrre, mens man laver noget andet. En anden feature jeg har brugt en del, er de forskellige split-window funktioner, som gør det nemt at sammenligne kode-blokke.

Den er også utrolig stærk i sin understøttelse af auto-complete indenfor nogen specifikke sprog, men bliver man irriteret over det, kan man selvfølgelig slå det fra.

Hvis man til daglig arbejder med meget store filer skulle Sublime editoren til gengæld være helt fantastisk. Sublime kan downloades i en evaluerings-udgave, men der er pt. ingen tidsbegrænsing på hvornår man skal købe en licens.

I utallige sammenligninger på nettet mellem Atom og Sublime har Sublime ligget som vinderen de sidste par år, men Atom er en stærk udfordrer og udviklingen er foregået i rasende højt tempo. De nåede 1 mio. aktive brugere i Marts måned i år.

Omvendt hvis man allerede bruger Sublime skulle der ikke være det store incitament til skifte til Atom.

Disclaimer: Jeg har endnu ikke fået testet Sublime, da jeg stadig er igang med at afprøve Atom.

Hvis der er noget, der specifikt kendetegner kodeeditorer, som f.eks. emacs og vi(m) så er det graden af kontrol, du har over dit udviklingsmiljø.

For at en ny editor skal kunne komme i betragtning, skal man kunne customisere sin editor herfra og til Hades og det kriterie må det siges, at både Atom og Sublime opfylder i metermål.

Hvilken kodeeditor bruger du lige for øjeblikket og hvad er dens “killer-feature”, der gør at du holder fast i lige netop den yndlings-editor?

Relateret indhold

Sidsel Jensens billede
Open source-nørd, unix geek og gadget freak. Uddannet Datalog fra Københavns Universitet. Arbejder som Systems Engineer hos one.com. Tidligere arrangør af LinuxForum og Open Source Days konferencerne og nu medarrangør af DrivingIT konferencen.

Kommentarer (73)

Kommentarer (73)
Mikkel Mikjær

Jeg koder en del PHP og er af flere blevet anbefalet PhpStorm, så her for et par dage siden købte jeg den (det er PayWare) og begyndte at sætte mig ind i den ... den kan redigere filerne "direkte" på serveren, den kan forstå mine objekter så den kan lave code-completion på det mest (har fundet enkelte steder hvor den fejler) og så har den et udemærket database interface der lader mig skrive sql queries med tab-completion, og så kan den køre både database og filoverførsel via ssh.

Indtil videre er jeg fan ... og min Vim er røget momentært i skammekrogen. Det piner mig dog lidt at det er payware ... det har jeg det absolut ikke godt med.

Claus Juul

Nu er jeg ikke udvikler, men Operations mand (it-revision som nuværende virke).

Så min kodeeditor er mere min tekst manipulator og til det formål benytter jeg helst Ultraedit (koster) eller Notepad++ (gratis).

De nøgle funktioner jeg skal bruge, er at kunne vælge tekst i kolonner (kolonne mode) og lave regexp.

Da jeg købte licens til Ultraedit, var den vist den eneste der kunne kolonnemode.

Når jeg skal lave lidt smårettelser på Linux, så er det VI(M).

Sebastian Paaske Tørholm

Jamen jeg er en vim-bruger.

Jeg har brugt den i et stykke tid, og har derfor vænnet mig til genvejstasterne og vim-måden at tænke på, og fået lavet en konfigurationsfil der passer til mine behov.

Jeg har ikke rigtig følt behov for at benytte nogle af de nyere editorer, da jeg har vænnet mig til et workflow hvor jeg arbejder i screen på en remote server, og ikke gider X-forwarding. Det skal så også sige, at jeg holder min editor relativt simpel. Autocompletion, automatisk kode-foldning, og så videre har jeg slået fra.

Til små simplere opgaver (notestagning og den slags) åbner jeg ofte en lokal Gedit, omend jeg er ret irriteret på dens nye interface.

Hovedsageligt er der nok tale om, at jeg har investeret en del tid i vim, egentlig meget godt kan lide workflowet, og ikke har set features fra andre editors, der har kunnet lokke mig væk.

That being said, så kan jeg dog sagtens bruge dem, hvis det er; jeg foretrækker bare vim når jeg skal skrive kode. Hvis jeg bruger dem, så løber jeg semi-ofte ind i situationer hvor jeg tænker "åhr, så kunne jeg lige have gjort X hvis det var vim." Igen, tilvænning.

Cristian Ambæk

bruger jeg Vim og har gjort det i en del år efter hånden. Den er altid tilgængelig, nem, effektiv og klare opgaven uden problemer.

Føler ikke der er nogle "nøgle funktioner" jeg absolut bruger. Bruger alle de gængse features som copy paste, delete, delete multiple lines, goto line X, goto head, goto bottom, search and so on.

Interfacet er også (for mig) lige til vs (no thanks) Nano.

Jesper Jarlskov

Melder historien noget om hvorfor nogen har følt sig nødsaget til at bestemme hvilken editor udviklerne skal bruge? Jeg er sådan set ligeglad med hvilken editor folk bruger, men jeg har svært ved at sætte mig ind i hvorfor det skulle give forretningsmæssig værdi at diktere en medarbejders værktøj på den måde. Er der nogen der kan enlighte mig?

Søren Pilgård

De får godt nok kamp til stregen hvis de skal hive Emacs ud af mine hænder.
Jeg må indrømme at jeg på ingen måde forstår hvorfor at din ven skal tvinges til at bruge atom i stedet for vim.
Hvilke fordele er det som virksomheden og resten af holdet opnår ved at han skal bruge en anden editor?
Er det fordi, at når der skal laves pairprogramming så tager det for lang tid at åbne atom op når det er makkerens tur til at taste?

I min verden er det der gør en editor god, hvor godt den kan formes til dig.
Her snakker jeg ikke bare om hvilke settings man kan ændre og hvilke plugins man kan installere.
Fordelen ved f.eks. Emacs er at alt kan ændres. Jeg har f.eks. flere gange været inde og omdefinere selve grundfunktionaliteten.
Når man så har bygget sin egen tilpassede editor betyder det at andre brugere af samme editor dårligt nok kan bruge ens udgave, især når deres tilpasninger jo heller ikke er til stede.

Nicky Thomassen

koder jeg desværre ikke så tit som jeg gerne ville, så ofte er editoren bare Nano over SSH. Den kan søge og erstatte og er ligeglad med filstørrelser osv. og er nem at bygge / installere og sætte op.

Når jeg koder er det med Gedit og et hjemmelavet farveskema. Som nævnt højere oppe, så syntes jeg heller ikke meget om deres nye interface.

Alle værktøjer som git og sFTP bruger jeg så bare manuelt fra den terminal jeg måtte være endt ved. Fordelen er, at når git og alt det andet først er lært, så kan man umiddelbart bruge dem på alle systemer.

Hans Dybkjær

Derhjemme på mac til Javascript/Typescript: WebStorm. Den understøtter sprogene, og har rigtig god og nem regex-replace.

På arbejde til tekster generelt: Notepad++ (let tilfældigt, men den dækker behovet).

På arbejde til c# (og typescript): Visual Studio + Resharper. Ud over selvfølgelige ting som completion, syntaksfarvning og reformat efter en fornuftig kodestandard, har de meget stærk understøttelse af refaktoriseringer af kode, ikke kun den basalt vigtige rename, men også blandt meget andet udtræk og flyt af metoder, klasser, interfaces.

Brugte i mange år emacs og skrev store mængder emacs lisp, men er meget tung at komme i gang med for andre eller ved lejlighedsvis brug (bl.a. pga. installation, tegnsætsproblemer og de mange kryptiske genveje).

Dertil kommer det løse: notepad, textpad, diverse ad hoc i andre programmer, sqlplus, textedit, ed, ...

Mht. om et team bruger samme editor, er det vigtigste at editorerne understøtter samme kodestil (navngivning, indrykninger, refaktoriseringer etc.). Og det er nemmest at opnå ved samme editor og udvidelser. Selvfølgelig, hvis man "bare" skal rette eller se enkeltstående tekstfiler, er god tegnsæthåndtering vigtig, og resten smag og behag.

Ditlev Petersen

En spøjs editor af lidt ældre dato. Der er sikkert fordele ved at skifte til en nyere, men besværet ved at skifte afskrækker mig lidt. Og Dr. E giver mig et fint overblik over programmet.

Torben Mogensen Blogger

Jeg har brugt Emacs i mange år, men jeg er ikke power user -- jeg retter sjældent i opsætningen, og har endnu ikke brugt Emacs Lisp -- så jeg ville ikke protestere det store, hvis jeg blev tvunget til at skifte. Jeg vil nok skulle vænne mig til nye genvejstaster, men det skal nok gå.

Men indtil jeg har en god grund til at skifte, bliver jeg nok med Emacs.

Personligt synes jeg, at syntax highligtning, auto-completion og lignende er overvurderet, når man skal kode. Men det er måske mig, der er gammeldags. :-)

Thomas Alexander Frederiksen

Dr. E
En spøjs editor af lidt ældre dato.

Er det en du har et link til mere information om? Hverken duckduckgo eller google imponeres over mine forsøg på at læse mere om den.

I øvrigt ville jeg også betragte toolchain-micromanagement som en potentielt god grund til såvel at whine som at overveje jobskift. Det er de færreste der er lige effektive i alle editorer, så det lyder også suboptimalt for virksomheden som sådan.

Jn Madsen

Jeg har lavet al mulig IT i mange år,- men besluttede mig for at lære at kode lidt for nogle år siden. Det irriterede mig jeg havde et blankt område der.

Efter at have læst alt for meget om hvad andre syntes,- så startede jeg med Python. Det breder sig jo hurtigt til alle mulige andre ting. Haskell (som ligger lidt stille), rå scripting i Linux, Django, yaml, jinja osv osv.

Editor .. prøvede et hav af de gratis, faldt ikke i svime over nogen af dem. Så snublede jeg over Sublime ... for en amatør som mig, der sidder den lige i skabet. Det er helt vildt hvor "naturligt" tingene falder. Smider alt ind i Sublime, selv router konfigurationer fra Cisco, Juniper, Ubiquiti og de andre. Sublime sætter bare tingene pænt op.
Java ... som jeg aldrig har tænkt mig at røre ved, duer vist ikke med Sublime, - pyt med det.

Ved siden af bruger jeg de indbyggede værktøjer i Anaconda til at arbejde med Python,- Anaconda er fabelagtig (iPython, fed Editor, grafiske værktøjer m.m).

Morten Hartvig

Hvis det er et udviklingsmiljø, kan jeg ikke længere undvære PhpStorm (kører det selvfølgelig i Linux miljø, nu hvor det integrerer mere nativt med Docker + har fuld integration til webserverens xdebug, git, php5/7 interpreter, javascript/typescript + 1000 andre ting).

Skal man rette en config/tekstfil, så er nano/notepad++ at foretrække:)

Henrik Kramshøj Blogger

Hey Sidsel, velkommen til!

Jeg kommer jo fra DIKU så i mange år var der kun EMACS, men med tiden skiftede det til andre ting, eksempelvis Textmate på Mac.

De vigtigste ting for mig er at min editor understøtter de sprog jeg arbejder med, uanset opgave. Det er ekstremt forkortet alt fra web ting CSS/HTML/JS, over præsentationer til større dokumenter med LaTeX.

Samtidig er jeg på vej væk fra Mac OS X, og derfor valgte jeg Atom for noget tid siden, hmm vel snart 2 år siden? og det er en ren fornøjelse. Det er krav at jeg kan skifte OS uden at skifte editor.

Atom ser ens ud på Mac OS X, Qubes, Linux, og hvor jeg ellers kan få den til at køre :-)
og har alle de pakker som jeg kan tænke mig at skulle bruge. NB: jeg er blevet svært glad for Adobe Source Code Pro pakken, så den er nu default også på tværs, det gør alting mere hjemligt. https://github.com/adobe-fonts/source-code-pro

Tobias Tobiasen

Til Java bruger jeg IntelliJ. Den er langt overlegent alt andet jeg har set.
IntelliJ har super god refactoring support, kender alle frameworks, har inspections der laver statisk kodeanalyse mens du koder, fremragende git support, integration med gradle, god code completion, god integration med Java debugger, osv.

Jeg tror det er refactoring support jeg sætter mest pris på. Der er en hel stribe avancerede ting man kan gøre med ganske få tastetryk.

Raf Andersson

Er meget glad for PhpStorm på min mac.
Der var engang hvor PhpStorm var smækfyldt med bugs, det er dog blevet meget bedre nu.

Thomas Nielsen

...men primært Visual Studio med Coderush, Visual Studio Code og vi. De to førstnævnte fordi det er på Windows jeg bruger 90% af min tid og sidstnævnte fordi det er den eneste editor på Linux/Unix jeg kan huske at bruge når det er dér jeg er (og i øvrigt aldrig laver andet end småting). Jeg har igennem mange år prøvet alle mulige smarte editorer, men jeg glemmer at bruge dem, glemmer at installere dem eller også virker de ikke lige til det jeg skal. Vi er altid komplet umulig og på den måde en rar konstant.

Ivo Santos

Jeg er ikke andet end en dum it-nørd og hobby programmør.
Jeg startede med basic på en Commodore 64, dernæst røg jeg ind i Visual Basic programmering i både office og Visual Studio.

For ca. 4 år siden fandt jeg en god online bog om C sproget, kan findes ved at søge på 'the C book', og findes på 'gbdirect.co.uk' side.
Siden da har jeg stort set ikke andet end kodet i C. Jeg burde sikkert have druknet mig i javascript og eller .net, men jeg endte altså med at kode i C, siden hen har jeg lavet et C modul til allokering og deallokering af dynamiske arrays. Jeg har tænkt på at lægge det hele op på git smmen med en hjemmebrygget CD katalog men det er så også det.

Anyway!, jeg har altid brugt Visual Studio til windows programmering. Det jeg syntes er smart ved Visual Studio er at ikke behøver at huske deklarationen for de forskellige funktioner, hvilken må siges at være en såkaldt killer funktion.

Siden hen er jeg også røget over i Linux, og i linux bruger jeg vi(m) editoren. i den fobindelse savner jeg næsten teksteditoren fra Dos 6 da jeg syntes at det er god editor fordi den, på den ene side, er menu baseret, og på den anden side er det enkelt at kopiere og sæt tekst ind, hvilken er lidt mere besværligt med vi(m).
Senest er jeg kastet mig over eclipse på linux, men det virker ikke helt som Visual Studio som jeg syntes er den bedste editor, okay!, den kan så ikke regex edit som f.eks. linux editor og lign. men hvis man ikke har brug for regex så er det også ligegyldigt.

Efter at have læst de øvrigt kommentar kunne det være at jeg også skulle undersøge de øvrigt editor.
Noget af det sidste jeg har læst er at man kan installere en klient på linux og benytte Visual Studio til linux programmering, men det har jeg altså ikke kastet mig ud i, og det kræver sikkert også en del læsning at sætte op, men indtil videre benytter jeg vi(m) til linux programmering.

Gert G. Larsen

vi på unix og sublime med vi-bindings på windows.
Jeg har lige fået den nye Windows 10 med bash på, så inden længe kan den vel også bare køre vi.

PS: Kan man få vi-bindings til Word?? :-)

Povl H. Pedersen

Jeg bruger helst Sublime til det meste. Men det er mere scripting m.m. end kodning. vim er goto editor på Linux og andre unix hvor jeg sjældent har GUI.
Kan dog også finde på at åbne Xcode hvis jeg skal kode på en Mac.
Hvis det er PowerShell, så kan jeg også starte PowerShell ISE.
Så det er lidt af hvert, afhængigt af den konkrete opgave.

David Konrad

Nu på 9 år. Gedit rummer præcis de killer-features jeg har brug for : Åbne, redigere og gemme tekstfiler, og som bonus er der syntax highlightning i diverse sprog - det letter læsningen. Gedit kan håndtere alt i en MEAN stack. Indrømmet, jeg har mødt et par stykker der mente jeg var lidt oldnordisk eller tosset; omvendt har jeg indtryk af, at visse folk har en tendens til at blive afhængige af deres elskede "killer-features", nærmest afmægtige uden :)

Jesper Hitch

platform jeg udvikler til.
Backend: PhpStorm er fantastisk
Linux kode C/C++: NetBeans (remote projects) og MS VisualStudio (Via samba)
Windows kode C/C++: MS VisualStudio 2010/15

Andre gange kan jeg bruger jeg blot Notepad++ eller nano og gcc.

Men ellers afhænger det af projektet jeg er på, samt kompleksiteten. Men det er svært at komme uden om MVS hvis man har brug for en god debugger :-)
Man skal dog lige kende sine bibliotekter/API og C++ Versioner hvis man som jeg ofte laver platformsuafhængig kode til Windows/Linux.

Yoel Caspersen Blogger

Jeg koder i Netbeans på Ubuntu - det er lidt irrationelt, for det kan sikkert også fås i andre værktøjer, men der er nogle ting jeg sætter stor pris på:

  • Formaterings-værktøj - sørger for at rydde op i indrykninger m.v. så det overholder den kodestandard, man har valgt
  • Farvekodning (letter overblikket)
  • Code completion (sparer tid og mindsker tastefejl)
  • Autosynkronisering til remote server (både ved kodning i PHP og C/C++)
  • Udmærket git-integration med versionshistorik og en grafisk diff-viewer

Jeg er dog ikke religiøs, så hvis der kommer en anden og mere letvægt editor, der kan det samme, kunne jeg godt finde på at skifte.

J A Thomsen

Jeg bruger VIM på linux og i mindst 15 år MED http://www.med-editor.com/indexus.html på Windows til redigering af både lokale Windows filer og linux filer via file share. Seneste version af MED er fra 2007, men jeg har ikke fundet nogen fejl i den og den supporterer projekter, 30 forskellige sprog (konfigurerbart), søgninger fra filniveau til filsystemniveau inkl. regexp, flere views på samme fil osv.
Den eneste mangel ved den ubetalte version er vist manglende mulighed for at printe en fil.

Klaus Hebsgaard

Jeg har i lang tid brugt vi og er vild med de keybindings, den har.
Men for lidt over 1 år siden stødte jeg på spacemacs og har ikke set mig tilbage siden.

Det er en helt vildt vim'ificeret emacs, som bruger space rigtig meget. (passer godt til mit kinesis advantage keyboard)
Der er rigtig gode plugins til snart sagt alle sprog.
Best setup ever.

Og velkommen til som blogger :-)

Simon Shine Blogger

  1. Perl til simple teksttransformationer (søg og erstat, filtrering og lignende). Hvis noget kan gøres med en elegant one-liner, behøver man slet ikke en editor!
  2. Vi(m) til konfigurationsfiler og serverbrug. Den har jeg brugt absolut længst tid (næsten 20 år). Eftersom jeg kun bruger den til småting nu, er min .vimrc skrumpet en del.
  3. Emacs til at kode i Haskell, Erlang, Standard ML og lignende sprog hvor dens modes er langt de mest modne. Det er det miljø jeg har personliggjort mest. Ikke at min .emacs er kæmpestor.
  4. Visual Studio på arbejdet. Det er efterhånden mit foretrukne udviklingsmiljø fordi det er så modent. Desværre bruger den ret meget RAM og virker til en relativt begrænset mængde sprog.
  5. Visual Studio Code når jeg leger med Unity på Mac'en derhjemme. Den er ikke lige så feature-rig som Visual Studio, men til gengæld kører den på Mac og minder utrolig meget om Sublime Text.
  6. Sublime Text som general purpose copy-paste buffer og formatteringsværktøj til StackOverflow-svar, Wikipedia-artikler, breve og lignende. At den ser flot ud og gemmer mine midlertidige filer selvom jeg ikke giver dem et navn hjælper mig i den kreative skriveproces, da jeg ikke skal tænke hvor en tanke passer ind før jeg skriver den. Og så er dens multi-cursor support lige så god, hvis ikke bedre, end Emacs'es, og er et nice, interaktivt alternativ til søg-og-erstat med kommandolinjen, idet man ser ændringen foretaget ved hver markør idet man skriver.

Jeg bruger næsten alle editors på tværs af alle tre platforme Mac, Windows og Linux, med nogle få undtagelser (Visual Studio bruger jeg kun på Windows, Visual Studio Code bruger jeg kun på Mac, og Emacs bruger jeg aldrig i Windows). For eksempel bruger jeg Perl og Vim i Windows via Cygwin

Morten Brørup

Notepad++ til almindelig udvikling og tekstfiler - den har nemlig en fin NppFTP-plugin, der integrerer godt til Linux.

Microsoft Visual Studio til Windows-udvikling.

emacs-nox (Emacs uden X), når jeg er i kommandoprompt på en server og lige skal rette noget. (Det er af historiske årsager: Jeg lærte om Emacs, før jeg lærte om vi.) Og da jeg aldrig rigtig har fået lært vi, installerer jeg rask væk emacs-nox på serveren, hvis den ikke er installeret i forvejen.

Som chef har jeg desuden adgang til et særligt superhøjniveau-programmeringssprog, nemlig: beskriv og uddeleger opgaven. Hertil benytter jeg Microsoft Outlook eller Microsoft Word (de engelske versioner). Sidstnævnte benytter vi iøvrigt også til forskellige former for dokumentation, kravspecifikationer, vejledninger osv., der ikke er inline i koden eller ligger som tekstfiler i kodebasen.

Med venlig hilsen,

Morten Brørup
CTO, SmartShare Systems

Henrik Mikael Kristensen

TextMate har været min foretrukne editor siden 2005 til at kode i REBOL, men jeg har kigget rundt i år for at se om der er andre der er bedre, specielt fordi TextMate er ret langsom.

Så lige nu er jeg ved at prøve Sublime Text af og har lært VIM for en god ordens skyld, men der er mangler ved begge.

Jeg ender nok med at gå tilbage til TextMate. Et decideret IDE bruger jeg aldrig.

Peter Christiansen

vim til c++, c, perl
notepad++ til javascript
eclipse til android/java
visual studio til c#
mplab-x ide til microchip pic c programmer.
Atom til CTF writeups, (har et godt MarkDown plugin).
gedit/notepad til hurtig notetagning.

Egentlig er jeg lidt ligeglad med hvilken editor folk bruger,
det kommer an på personlige preferencer og/eller firmapolitik.

Dog kan jeg ikke helt se hvorfor en arbejdsplads skal bestemme
hvilken editor der skal benyttes, hvis man kan producere den samme
kodestil.

Thomas Peter Berntsen

Velkommen til og tak for oplægget til et spændende tema. :-)

For mit vedkommende ser landskabet ud som følger:

På kommandolinien: Vim -> Emacs -> Joe (som jmacs) -> Nano/Pico.

Windowed: Atom -> Sublime -> Notepad++ (Windows) -> Vim (windowed)

IDE (afhænger af platform og sprog): IntelliJ (og afarter heraf) -> Visual Studio (den åbne) -> Eclipse

Rune Jensen

Er ikke super nørd, og har bevæget mig mest på klienten, hvad angår kode. Jeg bruger også gedit på Linux.

gedit har ikke code completion, som jeg måske godt kunne ønske, men dens farvning har jeg vænnet mig så meget til, at det vil være lidt vigtigt for at skifte.

Derudover har gedit en fed bug, som gør at lidt for store filer ikke kan læses. Lidt en party booper nogen gange.

Meeeen. En editor skal være light weight over alt andet. Jeg gider ikke vente på editoren åbner. Det betyder nok en masse ekstrafunktioner ikke kommer med, som er nyttigt (for nogle).

Jeg er åben for andre ditorer, men er foreløbig blevet ved gedit. Jeg har forsøgt mig med vim og sublime text, men forlod dem igen, husker ikke hvorfor.

gedit brug: en del CSS, HTML, efterhånden også en del JavaScript og en smule serverside scripting (VBS/Visual Basic).

gedit fordele: Light weight, åbner hurtigt, samt dens kodefarvning

gedit ulemper: bug ved for store filer (jeg har aldrig oplevet det ved mine kodefiler - kun mine logfiler). Har ikke code completion.

En ting, som ville være FEDT, er hvad jeg har set engang i en anden editor - når man brugte HTML tags, så kunne man i højre side læse en forklaring om dem samt syntax (fra W3C). Hvis man kan få en editor, som kan det til CSS, HTML og javascript... Og hvis den så også kan holde styr på mine variable, endnu bedre... Men altså først og fremmest light weight. Og så må den på ingen måde lave om i min kode (visse editorer har haft den tendens - indsatte styrekoder for editoren i selve koden).

David Konrad

@Rune Jensen, you are my man :) Fuldkommen enig, især i kritikken af gedit, den kokser virkelig derudaf med store filer, utrolig det aldrig er blevet rettet. Havde engang en bestemt maskine hvor gedit altid på et tidspunkt gik ned, sådan cirka efter 7-8 dage, og så måtte jeg genstarte hele molevitten (!!?). Men overall "Light weight, åbner hurtigt, samt dens kodefarvning" …præcis.

Jesper Louis Andersen

Acme er Sam er to gamle plan9-editorer. De kan fås til typiske unix-systemer via plan9port, og det er efterhånden en del år jeg har brugt dem til at skrive kode med.

De glimrer ved at være totalt funktionalitetsløse, men de har et rimeligt stærkt kommandosprog og deres samspil med et unix-system er pænt stærkt. Det er nok ikke lige editoren for alle, men hvis du er til simple systemer og en Zen-lignende tilgang til det at skrive programmer, så er det det værd. F.eks. er der ikke nogen konfigurationsfil.

I det daglige er det mest acme jeg bruger, men sam glimrer ved at være en klient/server arkitektur hvor du kan køre serverdelen remote hvor filen er. Det giver den fordel at du kan arbejde på linier der er dårlige, langsomme etc. Bevares, du kan lidt det samme med emacs tramp-mode, men eftersom den editor er single-threaded bliver det hurtigt til en masse kedelig venten.

Jeg har også en Emacs, til når folk kommer forbi og ikke kan tåle en editor uden syntax-highlighting :)

Magnus Lund

C#: Visual Studio med R# - selvom den er tung, til tider har underlige bugs og generelt er tung (har jeg nævnt tung?) - men er for meget vanedyr, når der skal produceres.

Python: Primært Atom - Jedi og et par andre plugins for delvis auto-completion. IDLE når det er hygge projekter.

TypeScript/JS/Html/CSS: Primært VS Code - letvægts og gør som regel som jeg forventer.

Config/tekst-filer: NotePad++ - super support for overskuelig visning af XML/Json/YML filer via plugins. Lidt irriterende opdateringsfunktionalitet.

Når jeg en sjælden gang er på et linux miljø - Nano eller Vi.

Audun Nes

PyCharm til Python
Eclipse til Java
vim til diverse, for eksempel bash scripts eller Maven pom.xml filer.
Notepad++ til record og playback af macroer.

Atom lyder dog spændende, og skal prøves ved lejlighed.

Rune Jensen

buggen ser ud til at være fra 2007, så om den nogensinde bliver løst, er nok et åbent spørgsmål

https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/156201

Det er også derfor jeg har afprøvet så mange andre editorer, det kan være lidt svært at leve med.

Grundlæggende ser det ud til, man skal holde filen på lidt under 100kb for at være sikker, og det er normalt ikke et problem hvis man deler sine filer op i mindre dele til code reusage, men til logfilerne... Det er en anden sag.

Jacob Sparre Andersen

I dag brugte jeg Vi, GPS, Emacs og Uniface/IDF.

  • Uniface kan jeg ikke anbefale.
  • Vi er ganske praktisk over en SSH-forbindelse.
  • GPS (GNAT Programming Studio) er god til at overskue en stor Ada-kodebase.
  • Emacs, fordi det plejer jeg at gøre, og dens Ada-understøttelse er acceptabel.

Jeg burde måske gå helt over til at bruge GPS til Ada-udvikling, men jeg kan ikke helt vænne mig til dens opførsel, så når jeg ikke lige har brug for en editor med indbygget refaktoreringssupport genveje til at hoppe alle mulige relevante steder hen i kodebasen, så holder jeg mig stadig til Emacs.

Finn Glamhøj

… til C/C++ og Java.

Har rigtig god understøttelse af C/C++ som giver god syntaksfremhævelse samt kodefærdiggørelse og gør det nemt at navigere i koden og er rimelig til omstrukturering af koden.

Den fanger mange af mine ”stave- og tegnsætningsfejl” førend jeg kompilerer, hvilket spare mig en del tid.

Glæder mig til at få prøvet KDevelop (som jeg brugte meget for år tilbage) og nu i version 5 er multiplatform.

Magnus Jørgensen

Til c og c++ bruger jeg ellipse og Visual studio afhængigt af projekt og platform.
Til Java bruger jeg intellij, netbeans og ellipse (afhængigt af projekt og platform)
Til python bruger jeg pycharm
Notepad++ og gedit til scripts og andet.
Til .net bruger jeg Visual studio og Monodevelop afhængigt af platform.

Nicolas Østergaard

Jeg er mere til scripting/automatisering af opgaver end kodning, og på Linux er det nano, og på Windows er det Powershell ISE.

Jeg har aldrig kunne sætte mig ind i vi(m) og dens spøjse måde at indsætte tekst på, hvor nano minder meget om notepad på Windows, og er lige ud af landevejen når noget hurtigt skal rettes.

ISE'eren på Windows bruges kun, fordi jeg sjældent kan huske navnene på de forskellige cmdlets.

Morten Sørensen

Jeg er frontend udvikler med en lille smule identitetskrise. På den ene side er jeg glad for at jeg ikke skal sidde og lave alt det bagved, men på den anden side vil jeg gerne være selvkørende og lære det. Derfor forsøger jeg også at være lidt mere kode-agtig end alle de der hipster-Apple-agtige typer. Så den står primært på Linux på min laptop.

Jeg sværger til Sublime i øjeblikket, men jeg er (meget) langsomt begyndt at migrere til Atom. Mest fordi at Sublime's package manager er 3. parts, og elendig i forhold til Atom, hvor den følger med som standard.

Atom har jo et hold af frivillige på GitHub, der udvikler på det. Men der er kun én udvikler på Sublime, så der er langt imellem opdateringerne som ikke altid fixer de små problemer man efterhånden er stødt på. F.eks. virker kursiv tekst i temaerne ikke altid multi-platform. Linux håndterer åbenbart nogle få skrifttyper anderledes end Windows. Som frontend'er er jeg jo glad for en gui, så jeg er helt klart glad for Atom.

Den eneste ting jeg er træt af Atom ved er at den tager lang tid om at starte op. Sublime åbner med det samme - det kan man bestemt ikke sige om Atom. Jeg har dog forsøgt at justere, men det hjælper ikke det store.

Nicolai Nyberg

AsmONE (for dem der kan huske den slags)
Code Composer Studio (C/C++)
CLion
Visual Studio
Notepad++
Nano/Pico
Hexedit
Eclipse
Netbeans
KDevelop3
...sikkert et par andre, jeg har glemt :)

David Rechnagel Udsen

Moderne råtekstbehandlingsprogrammer er slet ikke hvad de påstår, de tilføjer en masse kodeskabeloner for en, både synligt for en, men også bag om ryggen på en. De gør store filer overskuelige, i stedet for at knække sig selv, for at fortæller brugeren, at vedkommende måske skulle overveje mindre filer! Desuden, hvem kigger igennem logfiler i andet end less eller tail -f?

Så jeg bruger Gedit, fordi dets mangler gør mig til en bedre udvikler. Mine programmer bliver mindre fordi jeg skal kode alting selv (ja ja, pånær standardbibliotekerne; jeg er ikke hip nok til at udvikle mit eget sprog), men jeg får ikke leveret enorme standardskabeloner til at farvelægge min kode indenfor stregerne i.

Og er vim egentligt ikke bare ed med farver?

David Rechnagel Udsen

På samme måder, som en tømrer er bedst hvis han nøjes med at bruge gammeldags værktøj og holder sig fra skruemaskiner og deslige?

Er Gedit et gammeldags program? Det er jo stadig under udvikling. Jeg synes ikke analogien holder.

Du tager simpelthen fejl - Anvendelse af moderne værktøjer har stor indflydelse på din produktivitet.

Hvornår blev mere produktivitet det samme som mere kvalitet? Jeg taler ikke om at kode meget, men om at kode godt.

Finn Glamhøj

Så jeg bruger Gedit, fordi dets mangler gør mig til en bedre udvikler. Mine programmer bliver mindre fordi jeg skal kode alting selv (ja ja, pånær standardbibliotekerne; jeg er ikke hip nok til at udvikle mit eget sprog), men jeg får ikke leveret enorme standardskabeloner til at farvelægge min kode indenfor stregerne i.

Jeg kan ikke se, hvordan koden skulle ændre størrelse afhængig af om jeg ser den i farver eller i sort/hvid, eller at et godt design pludselig bliver dårligt fordi det vises i farver (eller sort/hvid). Jeg kan faktiske slet ikke se, at det kan gøre en forskel med hensyn til kvaliteten om koden er farvelagt eller ej.

Det gør det derimod hurtigere for mig, at skimme koden når den er farvelagt og det gør det hurtigere, at skrive koden når jeg bruger kodefærdiggørelsesfunktionen.

Det gør det også hurtigere for mig, at finde mine ”stave- og tegnsætningsfejl” når de er synlig med det samme og jeg ikke skal vente med at finde dem til jeg har kompileret.

De mange funktioner skriver ikke koden for mig de gør det bare lettere for mig at læse og skrive, men design og implementering er da stadigvæk op til mig.

David Rechnagel Udsen

Jeg kan ikke se, hvordan koden skulle ændre størrelse afhængig af om jeg ser den i farver eller i sort/hvid, eller at et godt design pludselig bliver dårligt fordi det vises i farver (eller sort/hvid). Jeg kan faktiske slet ikke se, at det kan gøre en forskel med hensyn til kvaliteten om koden er farvelagt eller ej.

Det gør det derimod hurtigere for mig, at skimme koden når den er farvelagt og det gør det hurtigere, at skrive koden når jeg bruger kodefærdiggørelsesfunktionen.

Jeg kan se at min farvelade- og tegnebogsanalogi måske nok har været lidt misvisende. Når jeg taler om standardskabeloner (ikke syntaksfremvisere), så forestil dig i stedet en slags »burgerskabelon«. Der er blot bolle og bøf, men det er op til en selv at »udfylde« ting i burgeren, såsom hvordan bøffen skal steges, bollerne skal bages, om der skal bruges ketchup, sennep og/eller mayonnaise, om der skal ost i og hvilket tilbehøret, såsom salatblade, agurker, løg, osv.

Sådan er det når man i et stort IDE siger »nyt projekt«, så har den en skabelon klar til en. Man skal slet ikke selv ud og vælge bolle eller kød. Det har den valgt for en.

Som sidebemærkning bør det nævnes, at Gedit også har syntaksfremviser.

Finn Glamhøj

Sådan er det når man i et stort IDE siger »nyt projekt«, så har den en skabelon klar til en. Man skal slet ikke selv ud og vælge bolle eller kød. Det har den valgt for en.

Det er en mulighed man har, at man kan vælge at bruge en skabelon, men det er ikke et krav for at bruge IDE’et og selvom man starter ud med at bruge en skabelon, så er det jo ikke noget der ikke kan ændres, man kan jo bare tilpasse den genereret kode efter behov.

Hvorvidt det giver mening at starte med en skabelon afhænger af skabelonen og hvad man ønsker at opnå.

Rune Jensen

Sådan er det når man i et stort IDE siger »nyt projekt«, så har den en skabelon klar til en. Man skal slet ikke selv ud og vælge bolle eller kød. Det har den valgt for en.

Jeg er ikke helt sikker på, hvad der menes her... Er det ikke bare, at editoren ikke må ændre i koden? Der kan lægges mange extra ting ind, som hjælper ved kodning, og som ikke påvirker koden. Syntax higlightning er kun én. Code completion er en anden. Små ting, som hjælper én at kode hurtigere uden at ændre i koden. Og som man kan slå fra, hvis det irriterer.

Med det sagt... Så ville jeg måske - ved større projekter - være lidt varm på SASS.

Jeg elsker at have 100% kontrol over min kode, og editoren skal bare holde nalderne fra den; jeg er bestemt ikke fan af frameworks heller, men... ved større projekter, kan det være en fordel for eksempel at bruge variable. Det er ikke fuldt ud understøttet i CSS endnu.

Det siger sig selv, så, at her har editoren ganske meget kontrol med koden, for det skal jo "oversættes" til valid CSS. Jeg kan forestille mig SASS vil være smart til web APPs, fordi det kun er ét CSS-ark, som er nødvendigt (jeg har IKKE prøvet SASS, men jeg har læst om det).

Men stadig... En god, kritisk sans mht. templates og frame works. Nogle gange tror jeg de er brugbare.

Til alt hvad jeg har lavet indtil nu, har jeg fuldstændigt veget udenom javascript frame works, fordi det er ikke "rigtigt" javascript, men jeg kan se deres eksistenberettigelse til visse projekter. Lidt det samme udgangspunkt har jeg med CSS-resets. Det er tredje part, derfor ikke noget jeg har bekymret mig om, i stedet tester jeg. Men ville måske være nyttige til visse ting.

En HTML template til HTML5, som indsætter standard tags for alle web sider de rigtige steder? Tjoh, kunne også være smart.

Man skal ikke afskrive alt nyt, men vurdere det for hver sag.

Rune Jensen

Her er en funktion, som jeg ville finde nyttig ved CSS.

Jeg kan godt lide, at mine deklarationer står i en bestemt orden. Sådan, at rene farvedeklarationer, som ikke ændrer i layout står først (color, background-color), og deklarationer, som kan ændre i layout står sidst (margin og padding f.eks), og alle individuelt i en bestemt rækkefølge (så vidt muligt alfabetisk).

Kan editoren lave den orden for mig, så synes jeg det vil være ret fedt. For lige nu gør jeg det manuelt.

Troels Henriksen

Personligt synes jeg, at syntax highligtning, auto-completion og lignende er overvurderet, når man skal kode. Men det er måske mig, der er gammeldags. :-)

Syntaksfarvning er nok mest et æstetisk valg, men hvad auto-completion og kodenavigationsværktøjer angår, så tror jeg ens præference er baseret på den type kode-opgaver man normalt har.

Du, som forsker i datalogi, skriver som regel kode for at afprøve nye idéer. Typisk er det små programmer, ofte skal de ikke interagere med anden kode, og det er ikke usædvanligt at det er helt ny kode, frem for videreudvikling af gammel. De sprog du bruger er enten nye (så værktøjer findes ikke), eller meget kraftfulde (så værktøjer er ikke helt så essentielle). I denne situation er det værdifuldt at mestre generiske værktøjer der kan anvendes på enhver tekstbehandlingsopgave, men måske ikke er så gode som et specialiseret værktøj ville være.

Mange industrielle programmører arbejder derimod på eksisterende systemer de ikke selv har skrevet, og som ingen måske har specielt godt overblik over, hvorfor det bliver essentielt at have gode kodenavigationsværktøjer til at se hvordan tingene hænger sammen. Systemerne er grundet størrelse og alder ofte komplekse. Nu og da er de direkte dårligt designet, men for store til at blive forbedret på kort sigt, så man er nødt til at lave stærke (men konceptuelt komplicerede) værktøjer til at gøre det mere håndtérbart. Javascript-økosystemet er et godt eksempel på dette.

En forsimpling kunne være: Jo længere man har fra idé til implementering, jo vigtigere er det med stærke værktøjer.

Selv kan jeg godt lide Emacs. Det er generisk nok til at være nyttigt som et "dumt" værktøj, men samtidigt er det overkommeligt at udvide med forholdsvist avanceret funktionalitet, når ens behov vokser. F.eks. brugte jeg ikke mere end lidt REPL-integration da jeg i forbindelse med min forskning startede på at skrive min oversætter, men efter den er vokset til 40.000 linjer Haskell har det været rart med lidt værktøjer. Jeg kan forestille mig at man føler behovet endnu stærkere, hvis man arbejder på to millioner linjer Java udviklet af hundrede mand over et årti.

Jørgen Larsen

@Troels Henriksen - det er en fuldstændig korrekt, men ofte overset pointe. Når man som mig skal hoppe ind og ud af mange projekter, skrevet af mange udviklere over en længere tidsperiode, så er kodenavigation og visualisering helt essentielt. Det vil ofte være kode jeg ser for første gang og undertiden skal en forklaring eller løsning på et kritisk produktions problem findes indenfor minutter/timer.

I virkeligheden bruger jeg langt mere tid på, at læse kode fremfor at skrive den selv. Det samme gør sig egentlig også gældende NÅR jeg skriver kode. Det tager tid - i hvert tilfælde for mig - at skrive god kode. Den vil ofte blive refaktoreret over flere omgange. Hvorvidt jeg skal bruge tid på, at genopfriske en bestemt editor shortcut betyder ikke det store i den sammenhæng.

Kodeeditor - jeg er på mange måder græsk katolsk. Mange editor understøtter de samme egenskaber som syntax highlight, auto complete, code folding, keyboard layout, kode layout format m.m.

IntelliJ virker fint for mig, men jeg kan sagtens leve med, at kollegaerne har andre præferencer. Brug hvad der giver mening for dig og lad os i stedefor bruge kræfterne på det der betyder noget - kodekvalitet.

Kevin Johansen

Er 99% .NET udvikler så bruger Visual Studio Professional (hjemme Visual Studio Community) til stort set alt, herunder mobiludvikling til Android og iOS (Xamarin)

Har rodet med andre IDE'er til mobil som xcode til iOS, Android Studio, NetBeans etc.

Kasper Helweg Jonassen

Emacs er en virkelig god editor med en del problemer. F.eks. er genvejstasterne ret udfordrende og .emacs konfigurationen bliver hurtigt et vedligeholdelses-projekt i sig selv. Man kan så overgive sig og installere Spacemacs hvilket for mig løser alle de små quirks. Emacs har ydermere en kick-ass Clojure mode(CIDER) og integrerer sømløst med GIT via Magit.

Til nogle projekter, typisk større, statisk typede af slagsen, kan jeg meget godt lide Visual Studio(Community).

Henrik Mikael Kristensen

Den eneste ting jeg er træt af Atom ved er at den tager lang tid om at starte op. Sublime åbner med det samme - det kan man bestemt ikke sige om Atom. Jeg har dog forsøgt at justere, men det hjælper ikke det store.

Nu har jeg også prøvet Atom af, men dens kritisk vigtigste feature, hastighed, er helt fraværende, men resten fungerer nogenlunde udemærket. Nogle gange skal man vente minutter på at den får sig sneglet færdig med... et eller andet.

Det er til at blive arrig over, når man har et stykke kode i korttidshukommelsen, man altså lige skal have skrevet ned.

Hastigheden er det store minus ved at basere sig på en webplatform for en editor.

Knud Jensen

Bruger udelukkende Notepad++. Når jeg selv har valget vel at mærke.

Tager ingen tid at installere, er nemt at tage med sig, og har tilpas mulighed for tilpasninger af udseendet.
Og vigtigst af alt, ingen forstyrrende knapper eller funktioner som man alligevel ikke bruger.

Niels Hansen

Det afhænger lidt af hvad jeg laver. Når jeg tager min udvikler-hat på, så er jeg begyndt at være ret glad for Atom. Så kan man have hele projektmappen liggende ude i siden, og alt er godt.

Hvis jeg er i gang med at være sysadm, så er jeg halvt i kategori 4. På Windows foretrækker jeg Notepad++, gedit i GNOME, og i en ssh-shell vælger jeg helst mcedit (det er trygt og godt). Men jeg bruger ret ofte nano hvis jeg ikke lige har midnight commander til rådighed. Og jeg er stoppet med at gå i panik hvis VI er eneste mulighed. Jeg ville ikke synes om at køre Atom med root.

Lars Madsen

Jeg tilslutter mig også Emacs vogntoget. Bruger dog også nano en del til hurtige rettelser. Ellers kodes der mest i Emacs. Det jeg så laver mest af i dag er redigering af LaTeX-kode, her er Emacs + auctex + reftex noget af det mest perfekte værktøj.

Eneste anke jeg har ved Emacs er at det tog så lang tid før jeg fik taget mig sammen til at lære at skrive makroer i Emacs. Det var først efter at have været forbi Emacsforum tilbage i 2011 at jeg fik taget mig sammen, hvilket nu har sparet mig SÅ meget tid, så stor tak til Peter Toft og Kenneth Geisshirt for at have lavet det arrangement.

Michael Hansen

Er ikke ansat som udvikler, men er uddannet til det, og laver en del DevOps stuff.

Hvis vi snakker C#/C++ så Visual Studio 2015 (Gratis Community edition hjemme, ent. på work), bedste features er intellisense/debuggeren.

Hvis vi snakker PowerShell (not a fan, hvis det er scrips længere end 20-30 linjer, det er for uoverskueligt at arbejde med) så ISE (Ofte Preview release, med andet (mørkt) colorscheme fra https://github.com/marzme/PowerShell_ISE_Themes), bedste feature, er built-in på Windows 2012 server og nyere)

På Linux/BSD, sad to say, men for det meste bare nano/pico, kan bruge vim, men er ikke fan af den, emacs uff, no, just no, bedste feature hurtigt at bruge, syntax highlighting. dog ikke noget jeg ville bruge som primær kode editor.

Som general editor på work til hurtigt at rette noget specifikt/read only, så Notepad++, bedste features, syntax highlighting til stort set alt, og loader store log filer hurtigt (ikke direkte relateret til programmering).

Carsten Gehling

...så die-hard, at Visual Studio først blev tålelig at arbejde i, efter at jeg fik installeret ViEmu. Jeg har brugt VIM siden 2000, og kommandoerne sidder dybere end min rygrad. Det er de små forskelle, som akumuleret bare gør, at jeg ikke arbejder nær så effektivt med andet.

Jeg vil sige, at nu hvor jeg udvikler C#, så giver Visual Studio og ViEmu absolut det bedste fra begge verdener.

Sidsel Jensen Blogger

Der er overraskende mange af jer der arbejder i blandede miljøer og derfor har forskellige editorer til de forskellige platforme - det giver god mening - pragmatisme FTW.

Det virker til at phpStorm er relativt populær - den har jeg ikke prøvet.

Jeg har tidligere arbejdet med Netbeans og blev utroligt træt af den - stort, tungt og langsommeligt monstrum.

Der er ikke en eneste af jer der nævner Brackets - oprindeligt Edge Code lavet af Adobe - den supporterer HTML, CSS, LESS og SASS markup sprogene. Den er skrevet i HTML, CSS og Javascript - Er det fordi den er noget bras og det er for begrænset hvad den understøtter eller er det fordi I ikke har prøvet den af endnu?

Finn Glamhøj

Jeg har tidligere arbejdet med Netbeans og blev utroligt træt af den - stort, tungt og langsommeligt monstrum

Det synes jeg også den var for et par versioner eller tre tilbage, men jeg synes ikke det er tilfældet i dag, hvis man se bort fra når den starter op og når den ved start skal scanne adskillige C/C++ projekter.

Det er i, version 8.x, umiddelbart den bedste multiplatform editor til C/C++ jeg har arbejdet med og i seneste version er det blevet endnu nemmere at arbejde med mange forskellige toolchains.

Hvis der er nogen der kan anbefale en anden multiplatform editor til C/C++ der er bedre er jeg altid interesseret i at prøve noget nyt.

Sune Marcher

Jeg synes det virker meget mystisk at kræve ét bestemt værktøj - så længe anvendte værktøjer ikke laver lort for andre (tab/whitespace commit wars, auto-syntax-indent-full-file-reformat og så videre), så bør det ikke være noget folk blander sig i. Den slags micro-management ville jeg se som et faresignal i en virksomhed. På den anden side er det for reaktionært ikke en gang i mellem at se hvad der findes af muligheder, og evaluere om man bruger de bedste værktøjer til ens opgaver.

Når jeg skal lave softwareudvikling (på projekter med mere end en håndfuld filer) er det med et fullblown IDE, ikke teksteditor og gaffertape. Refactoring, statisk kode-analyse, strukturel søg/erstat (med sprogforståelse, ting der simpelthen ikke er muligt med regex), lynhurtig navigation/referencesøgning (igen baseret på sprogforståelse), code completion, syntax-baseret dokumentations-opslag.

Så det betyder IntelliJ IDEA til Java, og Visual Studio til C/C++/C#. Jeg skal dog have tjekket CLion, det er folkene bag IntelliJ der har lavet det - og Visual Studio halter stadig lidt på refactoring siden uden Resharper / Visual Assist. Jep, jeg kan bedst lide stærke statisk typede sprog - men det er opgaveafhængigt.

Hvis jeg blot skal lave hurtig test af whatever, eller ikke har startet IDE og skal kigge på noget jeg enten ved hvor er, eller hurtigt kan greppes / Silver Searcher'es, sker det med en texteditor. Her er kravet at den starter lynhurtigt, samt har fornuftige edit-muligheder og syntax highlighting. Her er valget normalt Sublime Text, som har nok funktionalitet + plugin-mulighedr, samt er lynhurtig. På Windows starter jeg stadigvæk Notepad++ i ny og næ, men jeg kan i skrivende stund ikke komme på nogen specifik grund til jeg ikke eksklusivt bruger Sublime.

Hvis jeg skal rette noget over en SSH-forbindelse eller skal rette en config-fil på min arbejds-macbook (der kører OS X) er det normalt med VIM. Det er ikke fordi den til mit behov kan gøre noget andre miljøer ikke kan gøre lige så godt, men den er typisk tilgængelig på de fleste systemer, og når man ikke har visning af dotfiles slået til er det hurtigere at få åbnet config-filer med vim + shell autocompletion end gennem en system open dialog.

ATOM virker som en OK editor, men jeg har ikke fundet et scenarie hvor den rigtigt vinder for mig. Til generel editing er den for langsomt ifht Sublime (både startup og editing, når man er over småtingsafdelingen), og som IDE kan den heller ikke de ting jeg sætter pris på. Men til primært HTML + JavaScript vil den nok fungere udmærket.

Det er rart at have nogle effektive editor shortcuts, men jeg synes oftere jeg har brug for ting med sprogforståelse (expand selection i forhold til program-struktur, flyt markeret stuff på en måde der giver mening ifht. struktur, ...) end de mere "maskinelle" ting som fx VIM tilbyder. Og derudover bruger jeg mest tid på at navigere/forstå kode/gruble over et problem, hvorefter der følger et burst af writing/editing.

Til andre opgaver er der andre værktøjer - sed, forskellige hexeditors, unix-style tool pipelines, log navigation og hvad der nu giver mening. Nogle gange er det OK at lave mindless manuel tekst-transformation, andre gange er det bedre at automatisere (også selvom automatiseringen ender med at tage længere tid end den manuelle redigering).

Der er ikke en eneste af jer der nævner Brackets - oprindeligt Edge Code lavet af Adobe


At den er lavet af Adobe er næsten grund nok i sig selv til at fravælge den. Derudover er det (så vidt jeg husker) ligesom ATOM en editor baseret på Node og HTML/CSS til UI, så efter GitHub besluttede sig for at opensource ATOM i stedet for at holde den proprietær... well, så skal der være et eller andet specifikt i Brackets man er rigtigt glad for, for at vælge den editor. Det giver måske mening for frontendere der godt kan lide integration med Adobe produkter?

Log ind eller opret en konto for at skrive kommentarer