Hopeinen Omena

Heh... Huomasinpa just että Qt Creatorissa on FakeVim, joka tekee editorista Vimin. Täytyy varmaan ottaa käsittelyyn.

morbusg kirjoitti:

theinonen kirjoitti:RISC OS piilottaa ohjelmien valikot keskimmäisen hiiren napin taakse jolloin niiden tarvitsee olla esillä ainoastaan tarvittaessa.

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.

Koodi: Valitse kaikki

:set filet<tab>=ruby<enter>

(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)

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.

RISC OS ei käytä tiedostopäätteitä, vaan tiedostoilla on omat tiedostotyyppinsä. Tiedoston päätteen voi kyllä lisätä laittamalla tiedoston nimen perään /jpg esimerkiksi, jolloin kun siirrän tiedoston Windowsiin näkyy se siellä .jpg-kuvatiedostona. Käyttöjärjestelmän MimeMap moduuli hoitaa mäppäyksen tiedostotyyppien ja tiedostopäätteiden välillä jolloin, kun tuon tiedostoja tietää käyttöjärjestelmä mistä tiedostoista on kyse.

Jos tiedostoilla vain on oikea tiedostotyyppi, niin silloin käyttöjärjestelmä osaa ladata sen oikealla ohjelmalla ja esimerkiksi kyseinen tekstieditori osaa automaattisesti asettaa oikean moodin. Jos esimerkiksi haluan editoida BASIC-tiedostoa, niin shift+tuplaklikkaus vasemmalla napilla avaa sen editoriin. Pelkkä tuplaklikkaus taas suorittaa ohjelman.

RISC OS itsessään on tosin kyllä aika hiiripainotteinen ja esimerkiksi drag and drop on viety huomattavasti pidemmälle kuin muissa käyttöjärjestelmissä.

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?

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

Tuntuu että täällä on jos jonkin näkösen kielen koodaajaa Topicista saisi paremman jos jengi kertoisi vielä mitä koodia kirjottaa omalla lempparieditorilla. Toiset soveltuu joihinkin paremmin kuin toisiin, kuten tässä alkaa pikkuhiljaa jo tulla esiin.

(jalskin viestissä taisi tullakin jo selväksi)

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?

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'.

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

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?

Joku ohjelma joka generoi vim-tageja kuten ctags olisi tyypillisesti luotettavampi ja tehokkaampi ratkaisu jonkun ohjelmointikielen elementtityypin löytämiseen, koska se ei ole rajoittunut "tyhmään" tekstihakuun vaan voi ottaa laajemmin huomioon kielen rakenteen. Jos tekstihaku riittää mutta on oleellista nähdä listaus hakutuloksista, niin vimgrepillä tehdyn tekstihaun tulokset saa omaan ikkunaansa. Näitä käyttäessä ei ole rajoittunut yhteen tiedostoon. Nopeinta ja yksinkertaisinta on tietysti normitekstihaku tiedoston sisällä, silloin kun se riittää. Esimerkiksi eteen- ja taaksepäin normihakutulosten välillä hyppiminen ja edellisen editoinnin toistaminen ovat mahdollisia yhdellä näppäimenpainalluksella.

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?

En tarkoittanut, että piilottaisi editoitavan asian kontekstin vaan sitä, että piilottaisi näkyviltä editoitavan asian kannalta ylimääräisen tiedon.

Esimerkkinä vaikka liitteenä oleva kuva:
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).

Tuohon rivikomentoalueelle voi myös kirjoittaa labeleita tai tageja, joita voi käyttää komentojen tai omien makrojen sekä skriptien toteutuksen apuna.

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).

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.

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...)

Jos ylläolevassa käyttäjän tarkoitus oli vain kopioida yksi funktio, niin se onnistuu vimissä suurinpiirtein 6 näppäimenpainalluksella, ihan yhdistelemällä peruskomentoja ilman että vim tajuaa ohjelmointikielestä mitään. Kielispesifisillä toiminnoilla vähän nopeammin, esim. 3 näppäimenpainallusta on mahdollinen. Jos on foldannut funktiot, niin funktion voi kopioida kuten yksittäisen tekstirivin, 2 näppäimenpainallusta.

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...)

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?

Oma suosikkieditori ja käytetyt työskentelytavat ovat tietysti makuasioita, mutta on niistä silti aina mukava kiistellä... ;-)

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.

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ä.

Ja kyllä - VIM on huomattavasti helpottanut ja tehostanut koodaamista itselläni. Samaten aiemmissa työpaikoissa on ollut tilanteita, jolloin on pitänyt koodata etänä SSH:n yli laitteella suoraan pieniä muutoksia. Aika hankala olisi toteuttaa jollakin graafisella kikkareella, etenkin kun SSH-yhteydet on pitänyt muodostaa putkea pitkin toisen servun kautta + servu on ollut GPRS/EDGE/3G yhteyden takana.

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...

Mitä tarkoitat riippuvuuksien hallinnalla ja koodin täydennyksellä?

Oon itsekin nähnyt aika monta VIM-koodaria "ihan-siinä-oikeassakin-sovelluskehityksessä", ovat lähinnä C:tä ja standardia C++:aa koodanneet. Koodintäydennyksellä varmaan haettiin isojen luokkakirjastojen code-completea (esim OS X Cocoa/Foundation, Qt), jotka vaatii IDEltä vähän erilaista supportia mitä VIM pystyy tarjoamaan.

Jotenkin vaikea nähdä ketään koodaamassa isoja ohjelmistoprojekteja vimillä vaikka siitä tykkäänkin

kamina kirjoitti:Jotenkin vaikea nähdä ketään koodaamassa isoja ohjelmistoprojekteja vimillä vaikka siitä tykkäänkin

Onks Mozilla Firefox tarpeeks iso? En tosin itse lähtisi moiseen.

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.

spiidi78 kirjoitti:

kamina kirjoitti:Jotenkin vaikea nähdä ketään koodaamassa isoja ohjelmistoprojekteja vimillä vaikka siitä tykkäänkin

Onks Mozilla Firefox tarpeeks iso? En tosin itse lähtisi moiseen.

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.

No se on ihan hyvä esimerkki (vaikka sen koodi onkin mulle vierasta).

Miten debuggaat vi'llä? Lisäämällä logitusta?

Miten etsit kaikki metodin käytöt? Greppaamalla?

Miten hanskaat riippuvuudet, ajat helposti unit testit?

Kyllähän tekstiesitorilla voi muokata tekstiä, mutta kunnon IDE tekee aika paljon muutakin joka isossa jaetussa proggiksessa on aika oleellista.

kamina kirjoitti:

spiidi78 kirjoitti:

kamina kirjoitti:Jotenkin vaikea nähdä ketään koodaamassa isoja ohjelmistoprojekteja vimillä vaikka siitä tykkäänkin

Onks Mozilla Firefox tarpeeks iso? En tosin itse lähtisi moiseen.

No se on ihan hyvä esimerkki (vaikka sen koodi onkin mulle vierasta).

Miten debuggaat vi'llä? Lisäämällä logitusta?

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.
Plugineilla saa toki integroitua debuggereita vimiin.
http://www.vim.org/scripts/script.php?script_id=1703

Miten etsit kaikki metodin käytöt? Greppaamalla?

Vimin sisäänrakennettu grep toimisi tietysti useimmissa tilanteissa, ja on kieliriippumaton. Parempaa, kielen semantiikan ymmärtävää hakua saa esimerkiksi cscopella.

Miten hanskaat riippuvuudet, ajat helposti unit testit?

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?)

Yksikkötestejäkin on nähdäkseni triviaalia ajaa vimin sisältä. Sehän pystyy ajamaan mitä vaan ulkoisia ohjelmia, ja kääntäjän/maken/yksikkötestijärjestelmän/tms antamat kuitit saa halutessaan listaan käsiteltäväksi.

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.

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.

Pieni huomio. Tässäkin topicissa mainittiin, että hiiren ja näppäimistön välinen käden surffaaminen vie aikaa (joka on muuten varsin lyhyt MBP:llä, jossa touchpad on loistava ja lähellä kiipparia). Mutta vielä enemmän aikaa vie VIMin ja muiden työkalujen välillä pomppiminen, kun VIM on kerran pelkkä editori. Edelleen tämäkin taas riippuu siitä koodataanko C++ vai PHP/HTML. Ja joo QtCreatorissa on FakeVIM, jota en ole vielä kerennyt kokeilemaan. Creatorin omat näppäinoikotiet on tosin sen verran hyvin selkärangassa, etten tiedä kannattaako kokeillakaan.

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).

En mä nyt oikein tiedä mitä etua ulkopuolisesta debuggerista olisi siihen että se on integroitu suoraan työkaluun jolla koodataan?

spiidi78 kirjoitti:

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.

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

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.)

Editoinnista: LLVM tuo näppärän lisän XCodeen, eli kääntäjän virheet huomaa jo suoraan kirjoittaessa koodia.

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.
https://github.com/rdavison/clavim

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).

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.

En mä nyt oikein tiedä mitä etua ulkopuolisesta debuggerista olisi siihen että se on integroitu suoraan työkaluun jolla koodataan?

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.

On ihan validi homma käyttää editointiin vaikkapa Emacsia, ja debuggerina jotain IDEä.

Tyypillinen osaava koodari ei tarvitse debuggeria jatkuvasti pitkin päivää - jos tarvitsee, niin koodi on laadutonta ja/tai koodarin tehtävänkuvaus on korjata sekalaisia bugeja - vaan jonkun spesifisen ongelman löytämiseen silloin tällöin. Siksi on keskimäärin aika pieni vaiva, jos joutuu vaihtamaan työkalujen välillä debuggauksen ajaksi. Sama kuin muistiprofiloijat, erilaiset tehoanalysaattorit jne. Sinne mennään ja haetaan vastaus haluttuun kysymykseen.

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...

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...

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.

Sleepperi kirjoitti:

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...

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.

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.

Oon tässä viritellyt Sublime Textiä korvaamaan XCodea. Käytännössä XCode projektin konffausta lukuunottamatta saa aika nätisti korvattua kaiken muun, kuten tiedostojen lisäyksen projektiin jne. Jatkan vielä virittelyä.

(Gnu) nano ja kielenä python.

Kotikoneen edessä istuessa Xcode, töistä käsin (windows) sörkittäessä Notepad++. Tarvittaessa (pääteyhteyden kautta esim. Linux-puuhailussa) toki myös GNU nano hoitaa homman. Ohjelmointikielinä, sikäli kuin joku oli niistä kiinnostunut, obj-c ja satunnaisesti myös tavallinen C.

Vuoden jälkeen päivitystä. Linux -puolella nyt yli vuoden putkeen koodailleena Qt Creator ollut ylivoimainen vaihtoehto C/C++ -koodauksessa. Nimestään huolimatta soveltuu nykyään erinomaisesti myös ei-Qt -projekteihin.