Kell-e a kozmetika?

Szerintem kapcsolódik ide témában, ajánlom mindenkinek Joel legújabb cikkét: Making Wrong Code Look Wrong [www.joelonsoftware.com]

főleg az elején beszél arról, hogy a kezdők mániája a csinosítgatás, amitől semmivel nem lesz jobb a kód, sem pedig olvashatóbb a haladóbbak számára. De az egész cikket érdemes elolvasni (habár kicsit összevissza többmindenről is szól).

... arról nem is beszélve, hogy az ilyen akciók nagyon kellemetlen fölösleges perceket (órákat) tudnak okozni azoknak, akik innen-onnan beszerzett vagy épp saját készítésű patcheket alkalmaznak a forrásra.

akkor te is modositod a patched. senki ne mondja nekem azt, hogy nem szeret szep, jol atlathato kodot olvasni irni. alapbol nem kellet volna gany patcheket elfogadni es akkor nem lenne ilyen problema.

Jaja, telleg nem szamit semmit, ezek is allati olvashatok:)

http://www.ioccc.org/

Par a legolvashatobbak kozul:

http://www.ioccc.org/years-spoiler.html

:)

No ennek a kezzel torteno babusgatasara nem erdemes meg egy percet sem aldozni. A kodolasi szabalyokat nem lehet hiba nelkul betartani. (Persze torekedni lehet ra)

Van egy halom code beautifier progi, ami ast-bol csinal szep kodot, es garantaltan betartja a kodolasi szabalyokat. pl: indent

Egy opensource projektnél szinte mindennél fontosabbnak kéne lennie a szép forráskódnak, hogy könnyen be tudjon kapcsolódni bárki a fejlesztésbe. Szerintem.

Na ja, csak rohadtul utálom ha van 100 patchem amik tegnap még jók voltak, ma meg már a felük nem alkalmazódik olyasmi szarságok miatt mint pl. sor végéről leszedett szóközök... oké, átírom őket, de azt hiszem lehetne értelmesebb dolgokkal is foglalkozni :-)

Nagyon üt ez a Joel-es cikk. Hiánypótló olvasmány.

patch -l

Attól függ, ki mit ért csinosítgatás alatt... Egyszer belefutottam egy kb 600 soros függvénybe, amiben kettő szóközből állt egy indent, és átlagosan négyszeres, de igen sok helyen hatszoros volt az egymásbaágyazás. Felöltöztem, és hazamentem. (;

Erre valo wiggle, meg patch --ignore-whitespace opcioja.. Ha csak coding-style valtozas tortenik, meglehetosen egyszeru updatelni a patcheket tapasztalataim szerint. Ha meg nem csak stilus valtozik, akkor amugy is updatelni kell :)

Ha egy ember fogta magát és saját kezüleg végigfésülte a kódot és kijavítgatta ezeket a hibákat úgy, hogy megfeleljen a doksiban leírtaknak, akkor szerintem el kellene fogadni a patchet. Morton meg nem tudom hogy mit sír, kb. 2 sec leellenőrizni, hogy valóban csak CodingStyle módosításokat tartalmaz-e a patch...

Ha mar valaki kiganejozza utanuk a kodot (ami aztan tenyleg monoton), akkor ennyit megtehetnek a foistenek is :) Ilyen alapon a documentation/comment typo fixeket is el lehetne dobni, mert csak kozmetika.

De náluk policy volt, h nem kozmetikáznak, a linux kernelnél meg az a policy, h hogyan kellene kinéznie a dolognak.

Ez még príma is, hogy nincs kedvük/nem hajlandóak/van jobb dolguk is a monoton patch-nézéshez.

A gond ott van, hogy a legtöbb munka 20%-a érdekes, 80%-a dögunalom, és ez alapján a teszteléshez meg a heisenbugok levadászásához se állnak oda, mert az meg még unalmasabb?

Akkor most azért csinálják, hogy legyen és jó legyen, vagy azért, hogy ők jól elüssék vele az időt?

Ismét a kérdés: a linux most nyílt és közös fejlesztés (amiben az uncsi dolgokat is megcsinálj[áu]k), vagy pár ember hobbi-projectje?

A cikk feleig ugy gondoltam, hogy tiszta hulyeseg az egesz, es a fiu meg nem latott rendes OO megvalositast.

Aztan ahol a C++ orbitalis bakloveseket kopkodte, megertettem, hogy miert nem vett OO peldakat.

Megis, meg vagyok rola gyozodve, hogy nagyobb hiba az, hogy valaki jol lathato hibakat keressen a szemevel egy nagy nagy kodban, holmi irasi konvenciokra hagyatkozva, semminthogy keszitsen egy robosztus unsafeString es egy safeString osztalyt, es az egeszet az automatikus tipusellenorzesre bizza.

Az, hogy lehessen SafeString = UnsafeString, egy uj = operatorral, az szerintem jo dolog.

Az igaz, hogy C++-ban lehet iszonyatos baromsagokat csinalni, de egy jozan programozo nem fog olyasmit csinalni, amit o irt.

Ha i = j * 5, akkor az C++-ban is 5 * j, csak lehet, hogy j string volt, vagy akarmi.

Ez valoban a programozo felelossege. De ha az operatorokat kepes rendesen kezelni, akkor onnantol kezdve ez az egesz problemakor, amirol a cikk szol elmult, es nem kell semmit a szememmel atnezni, mert a fordito ellenoriz mindent helyettem.

Szoval ertem, amit irt, es meg most is ugy gondolom, hogy tiszta hulyeseg :-)

Ahogy az exception is. Ha az ember eleg tapasztalt ahhoz, hogy felismerje a benne rejlo veszelyeket, akkor meg is tudja ugy irni a kodot, hogy a cleanup mindig meghivodjek, es nem mashol, hanem ugyanott, ahova o tette a peldaban.

Nem is kell hozza mas, csak egy try/catch.

Na mindegy. Ez az en velemenyem, es nekem nincs nagy nevem, meg cikkeket sem irok. Nekem csak jopar ev tapasztalatom van, es tudom, hogy lehet ugyanazt a dolgot szarul is megvalositani, meg jol is. Es a jonal meg jobban is.

G

> Az ilyenek legtobbszor azert csinaljak ezeket a fixeket, h ot perc nepszeruseguk legyen.

Morton meg pénzért csinálja, az sokkal jobb :) A fanatikus opensource rajongok mindig azzal ervelnek, hogy barki besegithet egy opensource projectbe, megbecsulik stb. Ohoho.

Mindegy, nem akarok flamelni, csak nekem nem tetszik Andrew Morton elitista majomkodasa, ha nem akar ilyen dolgokkal foglalkozni, akkor kerjen meg egy altala megbecsult szakembert, hogy az ilyen patcheket szedje csokorba es ugy adja at neki.

Ha nincs coding style policyjük, akkor hajtsanak el. Ha van, akkor ne. Jelen esetben van. Ennyi.

"Morton jol dontott, majd fel megas patchenkent elfogadja a kozmetikat."

Ezt meg én nem vitatom.

De írta is az emberünk, h ő se úgy gondolta, h sok kis patchben küldi az ilyeneket, ezzel az első patchcsek csak annak fogadtatását akarta tesztelni, mert ha nem kerül be, akkor nem áll neki.

"De írta is az emberünk, h ő se úgy gondolta, h sok kis patchben küldi az ilyeneket, ezzel az első patchcsek csak annak fogadtatását akarta tesztelni, mert ha nem kerül be, akkor nem áll neki."

"Az, hogy lehessen SafeString = UnsafeString, egy uj = operatorral, az szerintem jo dolog."

Akkor igen, ha különböző típust használsz a kettő számára. De minek tennéd? Sztring mindkettő...

És akkor Joel cikkének példájánál maradva külön típust hozol létre az x koordináta számára, külön típust az y számára, különt a felbontáshoz stb.

Majdnem ott fogsz tartani, hogy van közel annyi típusod, mint ahány változód. Ez is nonszensz.

Ha meg a SafeString és UnsafeString azonos típus elemei, akkor meg nyilván nem fogod tudni az = jel értelmét megbütykölni.

Jah, az is policy, hogy levlistán megpróbálsz legjobb helyesírásod szerint írni, de nem kritizálod és nem javítod ki másokét.

Szóval miért ne lehetne policy, hogy igyekszünk magunkat tartani valamihez, de utólagos csinosítással nem pöcsölünk?

Ahogy az exception is. Ha az ember eleg tapasztalt ahhoz, hogy felismerje a benne rejlo veszelyeket, akkor meg is tudja ugy irni a kodot, hogy a cleanup mindig meghivodjek, es nem mashol, hanem ugyanott, ahova o tette a peldaban.

Nem is kell hozza mas, csak egy try/catch.

Vagy egy sentry class inline destruktorral, ha esetleg hatékonysági okokból nem akar try/catch blokkot.

Nagyobb problémának látom, hogy azt írja a

dosomething();

cleanup();

példánál, hogy át kell nézni a dosomething kódját, hogy biztosak lehessünk abban, lefut a cleanup. Nem, egyáltalán nem kell átnézni. Ha azt akarjuk, hogy a cleanup mindenképpen lefusson, akkor valamit tennünk kell, hiszen mi van, ha egy későbbi karbantartásnál megváltozik a dosomething kódja? Átnézzük az összes hívását? Egyszerűbb rögtön biztosítani valami módon, hogy a kérdéses kódrészlet biztosan lefusson, aztán történhet bármi, legalább ezen az egy ponton helyes lesz a program. :-)

KisKresz

Andrew Morton elitista majom >> minden opensource project elitista majmokbol all. Ez azert eleg durva kovetkeztetes :) Termeszetesen nem csak emiatt alakult ki ez a velemenyem. Nyugodtan kinevezhetnenek egy CodingStyle ormestert aki megkorbacsozza a csunya kodot kuldo developereket, es akkor nem utolag kene vitatkozni rajta :)

Ja egyébként erröl az jutt eszembe, mikor egy szakmai forumon megy a vita, és bele kötnek a helyes írásba érvek hílyán...

(;