Re: Paras editori koodaamiseen?
Lähetetty: 22.5.2012 klo 19.32
Heh... Huomasinpa just että Qt Creatorissa on FakeVim, joka tekee editorista Vimin. Täytyy varmaan ottaa käsittelyyn.
Suomalainen Apple-keskustelufoorumi
https://hopeinenomena.fi/
Kyllähän noistakin ohjelmista ne Mortal kombat combot löytyvät jos tarvitsee, mutta ei olla rajoitettuja pelkkään näppikseen. Tuossa kuvassa nyt on vain joku random menu avattu hiirellä, eikä sillä ole mitään muuta virkaa kuin demonstroida ohjelman valikkoa ja jokusta valmista ohjelman asettelua.morbusg kirjoitti:Eli monet muut editorit on tehty hiirtä silmälläpitäen, ja aina käden vieminen hiirelle/takaisin on aikaa pois itse asian tekemisestä. Theinosen kuva on sikäli hyvä esimerkki, että siinä ajassa kun on löytänyt oikean valikkovaihtoehdon tuosta pitkästä tiedostotyyppilistasta, on vim:ssä jo kirjoittanut esim.theinonen kirjoitti:RISC OS piilottaa ohjelmien valikot keskimmäisen hiiren napin taakse jolloin niiden tarvitsee olla esillä ainoastaan tarvittaessa.(tosin vim kyllä yleensä tietää esim. tiedostopäätteestä mitä ollaan muokkaamassa. Yksi vastaan tullut poikkeus oli .md jonka se olisi tunnistanut jos olisi ollut .markdown)Koodi: Valitse kaikki
:set filet<tab>=ruby<enter>
Oikea kysymys on, osaako vim tai joku muu nykyaikainen vi-klooni. vi:hän on vuodelta 1976, ja nykytilanne on se, että 99% järjestelmistä joissa on 'vi' -komento ei oikeasti sisällä vi:tä, vaan komennolla käynnistyy vim vi-yhteensopivuusmoodissa. Käynnistäkää siis suoraan 'vim'.jalski kirjoitti:Olen nyt jonkun aikaa leikkinyt SPFLite:llä ja siitä on tullut lempieditorini koodaukseen. Kyseessä on siis mainframe ISPF tyylinen editori. Käyttö eroaa jokun verran perus PC-maailman editoreista, mutta kun outouksiin tottuu niin käytössä on hurjan joustava ja monipuolinen työkalu.
Osaakos muuten tuo kaikkien ylistämä Vi-editori piilottaa tekstiä, jotta editoitavissa olisi vain kiinnostuksen kohteena olevat rivit?
vimissä voi piilottaa tekstiä foldauksella. foldexpr-asetuksella voi automaattifoldata, ymmärtääkseni myös tavalla joka vastaa sitä mitä teet yllä. Mielestäni sen tekemisen hyöty on kuitenkin kyseenalainen. Miksi piilottaa editoitavan asian konteksti?Esimerkiksi, jos haluan PL/I koodistani näkyville pelkät muuttujien tyyppien määrittelyrivit, voin yksinkertaisesti kirjoittaa komennon:
X ALL;FIND R'^ *dcl .* type ' ALL
Kun tarkistukset ja mahdolliset muokkaukset on tehty, niin piilotetut rivit saa takaisin näkyville komennolla:
SHOW ALL
En tarkoittanut, että piilottaisi editoitavan asian kontekstin vaan sitä, että piilottaisi näkyviltä editoitavan asian kannalta ylimääräisen tiedon.Sleepperi kirjoitti: vimissä voi piilottaa tekstiä foldauksella. foldexpr-asetuksella voi automaattifoldata, ymmärtääkseni myös tavalla joka vastaa sitä mitä teet yllä. Mielestäni sen tekemisen hyöty on kuitenkin kyseenalainen. Miksi piilottaa editoitavan asian konteksti?
Funktioillakin on usein jotain kontekstia mikä on oleellista sen käytön (tai kopioinnin...) kannalta. Esimerkiksi kommentti ennen funktion määrittelyä, joku funktion käyttämä palanen määritelty sen yläpuolella, tms.jalski kirjoitti:Olen automatisoinnut funktionäppäimen taakse hakutuloksien näytön ja ylimääräisen tiedon piilotuksen. Kirjoitan komentoriville hakusanan, jolla saan näkyville funktioiden alku -ja loppukohdat sekä painan edellä mainittua funktionäppäintä. Jos tuloksista haluan vaikka tallentaa jonkun yksittäisen funktion sisällön toiseen tiedostoon, niin tämä onnistuu yksinkertaisesti liitteenä olevan kuvan mukaisesti merkkaamalla haluttu rivialue UU - parin väliin ja kirjoittamalla tavara tiedostoon (tallentaa siis myös UU-parin välissä olevat piilotetut rivit).
Ideana oli, että editorin ei tarvitse päätellä vaan tehdä mitä käyttäjä käskee. Ehkäpä laittamani esimerkki oli hiukan huono. Kuvittele tekstitiedosto jossa on 10 tuhatta riviä koodia ja tuolla koodin seassa on 40 riviä mitä EHKÄ tarvitsee editoida. Nuo rivit ovat siis sekalaisessa järjestyksessä, erillään toisistaan ja hajallaan ympäri tiedostoa. Hakeminen rivi kerrallaan ja mahdollinen editoiminen tuossa tapauksessa on kohtuullisen työlästä. Tietysti nuo rivit voi grepata ja putkittaa tuloksen uuteen tiedostoon ja ikkunaan jos niitä rivejä haluaa tutkailla allekkain. Mutta eikös olisi vain helpompi piilottaa muu tieto, jolloin kyseiset rivit mahtuvat suoraan yhdelle ruudulliselle allekkain ja mahdollisen editoinnin voi suorittaa paikallaan?Sleepperi kirjoitti: Editori ei voi kauhean tehokkaasti päätellä, mikä tieto on kulloinkin relevanttia ja mikä ei. Useimpiin eri operaatioihin mitä haluaa tehdä, erilainen setti tietoa on relevantti. Siksi ei yleensä kannata nähdä vaivaa tiedon piilottamiseen ja palauttamiseen vaan pelkästään navigoida sitä tehokkaasti. (Se asenne muuten on OS X:n ikkunointijärjestelmän isoimpia vahvuuksia verrattuna Windowsiin...)
Aiemmat työpaikat joissa olen ollut ohjelmoijana (eli siis ihan ammatikseni tehnyt), olen käyttänyt jokaisessa aina editorina VIMiä. Olen koodannut useamman vuoden käyttäen VIMiä ja koodaan vielä nykyäänkin käyttäen VIMiä aina jos koodaan PHP:tä, C:tä tai muuta sellaista. Ainoa missä käytän muuta kuin VIM on Mac-softien devaaminen - niissä käytän XCodea. Nykyinen työ tosin ei ole ohjelmoijana, mutta vielä pari viikkoa takaperin aiemmassa duunissa koodasin VIMillä.jjari kirjoitti:Vi ei tehosta kenenkään ammatikseen ohjelmoivan työtä. Päinvastoin. Itse olen tehnyt 12 vuotta töitä ohjelmistokehityksen parissa useissa eri firmoissa, sekä ropellihattufirmoissa että "savupiipputeollisuudessa", lukemattomien ohjelmistokehityksen ammattilaisten kanssa. Ikinä kukaan ei ole tehny vi:llä tai emacsilla duuniansa. Ainoastaan jotain satunnaisia shell-skriptejä tehnyt/muokannut solariksella. Nyt siis puhutaan koodaamisesta, sovelluskehityksestä, ei unixin ylläpidosta.
Mitä tarkoitat riippuvuuksien hallinnalla ja koodin täydennyksellä?jjari kirjoitti:Nyt kannattaa ottaa huomioon se että ammattimaisessa koodaamisessa kyse ei ole pelkästään koodin kirjoittamisesta. Siihen kuuluu kiinteästi mm. debuggaus, koodintäydennys (vai miksi sitä sanotaan), riippuvuuksien hallinta jne jne...
Onks Mozilla Firefox tarpeeks iso? En tosin itse lähtisi moiseen.kamina kirjoitti:Jotenkin vaikea nähdä ketään koodaamassa isoja ohjelmistoprojekteja vimillä vaikka siitä tykkäänkin
No se on ihan hyvä esimerkki (vaikka sen koodi onkin mulle vierasta).spiidi78 kirjoitti:Onks Mozilla Firefox tarpeeks iso? En tosin itse lähtisi moiseen.kamina kirjoitti:Jotenkin vaikea nähdä ketään koodaamassa isoja ohjelmistoprojekteja vimillä vaikka siitä tykkäänkin
edit: Mitä tulee itse koodin kirjoitukseen, niin ainakin itselläni siihen itse kuluu loppupeleissä kaikista vähiten aikaa koko prosessissa. Aina pitäisi selvitä mahdollisimman vähällä määrällä koodia. Jossain web-koodauksessa homma voi tietty olla eri.
Yleensä vimillä ei debugata - sehän on editori. Bram Moolenaarkin on kommentoinut, ettei editorista kannata yrittää tehdä työkalua joka tekee kaiken, vaan käyttää parasta työkalua kuhunkin hommaan.kamina kirjoitti:No se on ihan hyvä esimerkki (vaikka sen koodi onkin mulle vierasta).spiidi78 kirjoitti:Onks Mozilla Firefox tarpeeks iso? En tosin itse lähtisi moiseen.kamina kirjoitti:Jotenkin vaikea nähdä ketään koodaamassa isoja ohjelmistoprojekteja vimillä vaikka siitä tykkäänkin
Miten debuggaat vi'llä? Lisäämällä logitusta?
Vimin sisäänrakennettu grep toimisi tietysti useimmissa tilanteissa, ja on kieliriippumaton. Parempaa, kielen semantiikan ymmärtävää hakua saa esimerkiksi cscopella.Miten etsit kaikki metodin käytöt? Greppaamalla?
En ole näiden asioiden asiantuntija, mutta jos joku moduuli täytyy pitää tietyllä tavalla riippumattomana, niin se varmaan hoituisi automaattitestillä joka testaa sen moduulin pelkillä sallituilla riippuvuuksilla? Jos on isompi pläjäys koodia, vaikka joku satatuhatta riviä, mitä lähdetään pilkkomaan moduuleihin niin sitten käyttäisin jotain erillistä työkalua apuna identifioimaan riippuvuuksia ja löytämään sopivia moduulirajoja. En ole nähnyt, että IDEt pystyisivät näihin asioihin kunnolla, automaattisesti, ilman plugineja ja oikeasti isolle koodimassalle. (Tarkoitatko riippuvuuksien hallinnalla jotain muuta?)Miten hanskaat riippuvuudet, ajat helposti unit testit?
Irrallista hyvää debuggeria ei taida olla olemassakaan. En ole ainakaan törmäänyt vaikka googletin joskus päiväkausia... Testit olen kyllä päivään mennessä oon itse ajanut aina komentoriviltä suoraan, jos en ole XCodea virittänyt moiseen. Tosin joskus on joutunut debuggaamaan vikaa, johon IDE on sitten taas kätevämpi kuin komentorivi-gdb Editoinnista: LLVM tuo näppärän lisän XCodeen, eli kääntäjän virheet huomaa jo suoraan kirjoittaessa koodia.Sleepperi kirjoitti:Yleensä vimillä ei debugata - sehän on editori. Bram Moolenaarkin on kommentoinut, ettei editorista kannata yrittää tehdä työkalua joka tekee kaiken, vaan käyttää parasta työkalua kuhunkin hommaan.
Komentorivi-gdb:llehän oli tosiaan vaihtoehtona esimerkiksi plugari joka integroi gdb:n hyvään editoriin. En tiedä kuinka paljon IDEjen debuggerit tekevät sellaista mitä tuolla kombolla ei voi tehdä? Ainakin Visual Studion usein kehuttu debuggeri on oman kokemukseni mukaan ollut harmillisen rajoittunut, eli siinä on ollut vaikeaa nähdä oleelliset tiedot jostain objektista jonkun pointterin takana, tehdä järkeviä breakpoint-ehtoja jne. Jo ihan se käyttöliittymä, minkä sisällä näitä asioita pitäisi VS:ssä tehdä, on ruma, tekstiboksit toimivat huonosti jne. En uskalla edes ajatella millainen homma olisi lähteä korjaamaan näitä aspekteja VS:stä plugareilla, olettaen että se on edes mahdollista. (Tuskin on.)spiidi78 kirjoitti:Irrallista hyvää debuggeria ei taida olla olemassakaan. En ole ainakaan törmäänyt vaikka googletin joskus päiväkausia... Testit olen kyllä päivään mennessä oon itse ajanut aina komentoriviltä suoraan, jos en ole XCodea virittänyt moiseen. Tosin joskus on joutunut debuggaamaan vikaa, johon IDE on sitten taas kätevämpi kuin komentorivi-gdbSleepperi kirjoitti:Yleensä vimillä ei debugata - sehän on editori. Bram Moolenaarkin on kommentoinut, ettei editorista kannata yrittää tehdä työkalua joka tekee kaiken, vaan käyttää parasta työkalua kuhunkin hommaan.
Juu, tuo on oikeasti hyvä juttu. libclang on tietysti avoin, joten sitä voidaan hyödyntää kaikissa avoimissa editoreissa. Tässäkin joku pakertaa jo sitä samaa syntaksiväritystä vimiin.Editoinnista: LLVM tuo näppärän lisän XCodeen, eli kääntäjän virheet huomaa jo suoraan kirjoittaessa koodia.
Tuo kuvaa kaikkia debuggereita mitä olen käyttänyt, mutta vahvemmat debuggerit voivat antaa lisäksi muokata luettuja debuggausarvoja eri tavoilla ennen näyttämistä, näyttää graafeja ja kuvia tekstin lisäksi, kasata monimutkaisempia ehtoja breakpointeille jne.kamina kirjoitti:Ehkä mulla on väärä käsitys debuggaamisesta, mutta kun olen tottunut koodaamaan Idealla javaa niin minulle se kertoo kutsupolun siihen metodiin jossa on, antaa mennä eteenpäin yhden askeleen kerrallaan joko astuen metodikutsuihin tai niiden yli. Antaa muuttaa minkä vain muuttujan arvon lennossa, evaluoida koodia ja muuttujien arvoja sen hetkisen tilanteen mukaan, määritellä milloin breakpointtiin pysähdytään (aina, vasta viidennellä kierroksella, vain jos jossain on tai ei ole määriteltyä arvoa, aina kun tulee poikkari jne).
Ei mitään, jos sisäänrakennettu debuggeri on paras debuggeri mitä on ikinä keksitty ja tullaan ikinä keksimään. Muussa tapauksessa siinä ulkopuolisessa debuggerissa saattaa olla paremmat ominaisuudet. Oleellistahan ketjun kannalta ei ollut niinkään kysymys, olisiko ulkoinen debuggeri jotenkin parempi, vaan se, ettei debuggerin ole pakko olla sisäänrakennettu ollakseen kelvollinen. Ja niin ollen, editorin voi valita myös niistä joissa ei ole sisäänrakennettua debuggeria.En mä nyt oikein tiedä mitä etua ulkopuolisesta debuggerista olisi siihen että se on integroitu suoraan työkaluun jolla koodataan?
Kuulostaa juurikin sellaiselta poikkeustilanteelta jossa tarvitaan todella paljon debuggeria ja sen pitää olla myös hyvin integroitu. Sekä työnkuvan että käytetyn kielen takia. Ja jos arvaan oikein, niin ne miljoonat rivit eivät kaikki ole kovin laadukasta tavaraa.kamina kirjoitti:Joo, mun työnkuva on ollut korjata bugeja useita miljoonia rivejä koodia sisältävistä projekteista joissa samaan moduliin ei välttämättä joudu monesti koskemaan joten ehkä on vähän väärä käsitys, tai sitten tuon kautta muodostunut tietynlainen työskentelytapa...
Bugeja korjatessa monesti onneksi yleensä pärjää pelkällä dumpilla ja offseteilla. Hienompi interaktiivinen debuggeri ja rivi kerrallaan askellus on toki mukava silloin, kun haluaa paremmin selvittää itselleen ja sisäistää jonkun oudolta näyttävän asian toteutuksen.Sleepperi kirjoitti:Kuulostaa juurikin sellaiselta poikkeustilanteelta jossa tarvitaan todella paljon debuggeria ja sen pitää olla myös hyvin integroitu. Sekä työnkuvan että käytetyn kielen takia. Ja jos arvaan oikein, niin ne miljoonat rivit eivät kaikki ole kovin laadukasta tavaraa.kamina kirjoitti:Joo, mun työnkuva on ollut korjata bugeja useita miljoonia rivejä koodia sisältävistä projekteista joissa samaan moduliin ei välttämättä joudu monesti koskemaan joten ehkä on vähän väärä käsitys, tai sitten tuon kautta muodostunut tietynlainen työskentelytapa...