( hrgy84 | 2012. 05. 02., sze – 16:46 )

Egyreszt ez attol fugg. Ha jol van dokumentalva a kod, akkor eleg csak az adott scope-ban ervenyes objektumokat tudnod, ami azert nagysagrendileg kevesebb. Viszont egy kb. ismeretlen objektumon belul azert neha nem trivialis megmondani, hogy melyik fuggveny fogja neked azt csinalni, amit szeretnel. Ez foleg akkor igaz, ha az adott objektum nem is a te rendszeredbol szarmazik, hanem valamely kulso rendszer biztositja szamodra.

Vegyuk peldanak (csak hogy C++ legyen) a Qt-t. Eleve rengeteg objetumot biztosit a konyvtar magatol, ezen felul a nevkonvencioja neha eleg erdekes tud lenni. Lehet, hogy abszolut nem is illeszkedik a kod altal hasznalt konvenciokhoz. Ilyenkor meg tudja gyorsitani a kodolast, ha mar eleve van egy listad a fuggvenyekrol, es az autocompletion tooltipben melle tudja irni, hogy az adott fgv megis mi a rakot csinal, milyen objektummal ter peldaul vissza - amin ismet lehet fuggvenyeket hivni.

De szerintem nagyon elmentunk az autocompletion iranyaba, holott ez az IDE-knek csak egy - kikapcsolhato - szolgaltatasa. A debuggolasnal peldaul szerintem iszonyuan jol tud jonni egy IDE, ahol az adott breakpoint-hoz hozza tudja kapcsolni az adott forrast, alapbol kiirja neked az epp ervenyben levo - vagy watchlist-en levo - valtozokat, etc. Sokkal gyorsabba, hatekonyabba teszi a muveletet, mintha ugyanezeket kezzel iratnad ki.

De kiemelhetnem a kulonbozo forraskezelo funkciokat, azt, hogy sok IDE akar meg naplokimenetekhez is tud forraskodot csatolni neked. Ezek apro dolgok, osszessegeben azonban tudnak annyit adni a fejleszteshez, ami miatt _szerintem_ megeri befektetni az IDE konfiguráció összeállításába.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal