Mikortól számít valami gányolásnak?
2016-12-05T13:52:12+01:00
2016-12-08T15:12:40+01:00
2022-06-29T11:26:58+02:00
  • Ebből nem az következik, hogy a kézi okozza a merge conflict-ot, hanem az, hogy a kettő együtt.

    Az eredendő ok az eltérő "beállítások", függetlenül attól hogy gépi vagy kézi. De gépinél biztosítani tudod hogy ezt elkerüld. Kézinél nem.

    A kézi önmagában is okozhatja gépi nélkül, ha a két ember nem azonos "beállítások" alapján tér el a gépitől, akkor egymástól is eltérőt csinálnak.

    A csak a változtatott kódot formázzuk kitételt nagyon könnyű véletlenül akár reflexből is elrontani, szóval azt felejtsük el.
    Mutasd a teljes hozzászólást!
  • Ha kézzel jobb eredményt érsz el, akkor nyilván más "beállítást" alkalmazol mint az automata. Ergo más lesz az eredmény is, ergo lehet merge conflict.

    Ha a kézit és az automatát együtt használod, akkor igen, egyik átformázhatja a másikat.
    Ebből nem az következik, hogy a kézi okozza a merge conflict-ot, hanem az, hogy a kettő együtt.
    Szerintem az egyértelmű, hogy keverni nem jó a kettőt!
    Mutasd a teljes hozzászólást!
  • Ha az olvashatóbb alatt mind a ketten a könnyebben érthetőt értjük, akkor szerintem összességében olvashatóbb lesz a kód ilyenkor.

    A fenti példákban igen.

    Amikor a típusdeklaráció önmagában 30 karakter, akkor már nem feltétlenül, mivel ezt változódeklaráció nélkül nem írod ki.

    Igen, olyan nyelvekben ahol a típusdeklaráció elhagyható a változó vagy literál deklarációból, ott kényelmesebb.
    Mutasd a teljes hozzászólást!
  • ( Mellesleg kézzel mindig jobban meg tudod formázni, mint a legjobb automaták. )

    Igen, de egyszerűen nem érdemes kézzel, túl sok gondot okoz a mergeknél. Csak találni kell egy nem túl oszlop pazarló autoformázási beállítást.

    Ezt értem, azt nem értem, hogy ha kézzel szabdalom több sorba, vagy ha autoformázó szabdalja több sorba, az mennyivel másabb.

    A gond akkor van ha különböző beállításokkal csináljátok, és amire eredetileg reagáltam az az volt, hogy kézzel jobb eredményt érsz el. Ha kézzel jobb eredményt érsz el, akkor nyilván más "beállítást" alkalmazol mint az automata. Ergo más lesz az eredmény is, ergo lehet merge conflict.

    Avagy úgy érted, hogy azért jobb az automata formázó, mert az nem formáz át olyan kódokat, amiket nem változtatsz meg? Elvileg kézzel formázás esetén sem jön elő ilyen probléma. Ha jól megformáztuk elsőre, akkor miért akarnánk átformázni?

    Nem. Azért jobb a kikényszerített automata formázó, mert biztosítható hogy mindenütt ugyanazokkal a beállításokkal formáz (az egész filet, nem csak a módosított sorokat), és elkerülhető ezáltal a csak formázás miatti merge conflict.
    Mutasd a teljes hozzászólást!
  • - vagy amikor a változó deklaráció amit így bevezetsz (és amit lehagytál a példádból), az önmagában is hosszú sort eredményez, mert pl. sok típusváltozó van az új lokális változó típusában... ekkor ha lokális változót vezetsz be, nem biztos hogy összességében olvashatóbb lesz.

    Nem hagytam le, nem egy konkrét nyelvről volt szó. Ám legyen, Java:

    final Type1 harmadikParam = harmadikMetodus(z); final Type2 masodikParam = masikMetodus(x, harmadikParam, y); metodusHivas(a, masodikParam, c);
    Scala:

    val harmadikParam = harmadikMetodus(z) val masodikParam = masikMetodus(x, harmadikParam, y) metodusHivas(a, masodikParam, c)
    Ha az olvashatóbb alatt mind a ketten a könnyebben érthetőt értjük, akkor szerintem összességében olvashatóbb lesz a kód ilyenkor. Nem csak az válik szét, hogy ki kivel van, hanem még plusz információk is kerülnek be (elnevezések és esetleges típusok).
    Mutasd a teljes hozzászólást!
  • Ha máshol van a sortörés, akkor azt a diff eszközök a merge során különbségnek veszik, még ha a file-ok közti különbség csak és kizárólag whitespace és sortörések.

    Ezt értem, azt nem értem, hogy ha kézzel szabdalom több sorba, vagy ha autoformázó szabdalja több sorba, az mennyivel másabb.

    Avagy úgy érted, hogy azért jobb az automata formázó, mert az nem formáz át olyan kódokat, amiket nem változtatsz meg? Elvileg kézzel formázás esetén sem jön elő ilyen probléma. Ha jól megformáztuk elsőre, akkor miért akarnánk átformázni?

    Ha meg nem tudunk jól formázni, akkor szükséges az autoformázás, amit írtam is korábban:

    Nem rossz, sőt nagyon jó, ha sokan dolgoznak együtt és (egyesek) képtelenek kézzel, normálisan formázni a kódot. Ilyenkor elkerülhetetlen és egy áldás!
    Mutasd a teljes hozzászólást!
  • Azért van egy kis félelmem, hogy legtöbbször gondolkodás nélkül zöldítenének.

    Audit trail kell rá, és már is meggondolják
    Mutasd a teljes hozzászólást!
  • Értelek, és nagyon egyet is értek. Valóban úgy tűnik, hogy az említett személy által alkalmazott szabályok valószínűleg nem szültek jól olvasható kódot.

    Valamint ő bevezette a szabályait, de az olvashatósági problémákat amiket okozott egy 3-4 éves kódhalmazon, és aminek egy jó része vendor által írt kód volt az ő formázási beállításaikkal, ami gyökeresen eltért az övétől, és tele volt anonim osztályokkal, azt már nem javította ki. Én meg nem szeretem ha más az én alkatrészemmel veri a csalánt.

    Azonban én nem Őt és a szabályait próbáltam védeni, hanem azzal nem értek egyet, hogy szükség lenne a 160 karakteres sorokra.

    Nem látom a problémát a 160 karakteres sorokban, ha csak arra használod fel hogy adott esetben hosszabb metódusneveket engedsz meg magadnak.

    A szabályok halmaza egy egyensúlyt alakít ki. Egy rosszul megválasztott szabályt ki kell egyensúlyozni egy másik szabály lazításával. Erre volt példa az, hogy az ő általa választott szabályok elvadították a sorhosszt, amit a legegyszerűbben a sorhossz növelésével lehet megszelidíteni.
    Erre volt példa az, hogy különböző formázásokhoz különböző sorhossz is elég, anélkül hogy bármi egyéb változást csinálnánk.

    Így még olvashatóbb:

    harmadikParam = harmadikMetodus(z) masodikParam = masikMetodus(x, harmadikParam, y) metodusHivas(a, masodikParam, c)

    Ezzel bizonyos kivételekkel egyetértek. A két kivétel ami miatt nem mindig,
    - mikor anonim blokkot vagy pláne lambdát akarsz átadni egy metódushívásnak, amit nem szeretek változóban látni (és lambdánál talán fordítási vonzata is lehet Java-ban, bár talán metódus lokális változójának értékadásnál nem...)... valamint sok helyen látod példaként ugyanazt, hogy a callback anonim class vagy lambda nincs külön változóba deklarálva... tehát az a kód ami ezeket a példákat vette alapul tele lesz ilyesmivel
    - vagy amikor a változó deklaráció amit így bevezetsz (és amit lehagytál a példádból), az önmagában is hosszú sort eredményez, mert pl. sok típusváltozó van az új lokális változó típusában... ekkor ha lokális változót vezetsz be, nem biztos hogy összességében olvashatóbb lesz.

    Ha védeni akarod a 160 karakteres hosszt, akkor inkább olyanra hozz példát, ahol szerinted annál nem lehet olvashatóbban megírni rövidebben és/vagy több sorban.

    Nem mindenáron a 160 karakteres sorhosszt akartam védeni, hanem azt is megmutatni, hogy nem lehet a szabályokat magukban vizsgálni.

    Függvények hívásának (mint amilyen a fenti példa is volt), ciklusok, feltételek egymásba ágyazására.

    Igen, azt általában én sem szeretem, a hosszú property path-okat Java-ban getter-rel különösen nem.

    Ciklusok feltételek egymásba ágyazása viszont abba a kategóriába esik amit említettem, runtime costja lehet, ha a ciklusmagot vagy a branch-et kiviszed metódusba (több változó változtatása esetén), illetve nem minden if egymásba ágyazását lehet elkerülni.

    Egyetértek, ez teljes eszementség. Az egyik legrosszabb kódformázás a paraméterek, változók egymáshoz igazítása, amikor egymás alatt kell kezdődjenek.

    Változók esetében egyetértek, paraméter deklarációk esetében annyira nem zavar, bár fura tud lenni a szignatúra mikor van egy pár típusváltozó és pár exception is deklarálva.

    De ezek sima metódus hívás paraméterek voltak, és ott is gondot okoz lambdák és anonim blokkok esetén meg azzal, hogy ha a hívott metódus név utánra igazítod az egészet akkor pazarolja az oszlopokat. Ha nem igazítaná a metódusnév utánra, akkor még el is fogadnám, hogy oké, mert akkor csak egy indent a költség.
    Mutasd a teljes hozzászólást!
  • Miért okozna gondot a mergeknél?

    Ha máshol van a sortörés, akkor azt a diff eszközök a merge során különbségnek veszik, még ha a file-ok közti különbség csak és kizárólag whitespace és sortörések. Némelyik nem csak merge során.

    Emiatt automatikus merge helyett merge conflict-od lesz.

    Ha a (pre-commit hookban) kikényszerített formázás biztosítja hogy ilyen nem történhet meg, akkor rengeteg merge conflict-ot elkerülsz. Úgy 80%-ra tenném az a kézzel végzett merge-ek közül amik csak ilyesmi miatt történtek velem eddig.

    Itt is a hosszú sorok és a rengeteg paraméterből egyből gyanút foghatunk, hogy itt egy gánnyal van dolgunk, amit kicsit átalakítva, sokkal rövidebb sorokat és olvashatóbb kódot kaphatunk.

    Már akkor is kevesebb lenne a sorhossz, ha az átadott paramétereket lokális változóba kiteszed.
    A toString()-et nem szeretem kézzel meghívni, mielőtt a visszatérési értékét továbbadom, és gyanús ha meg kell. Az arra utal, hogy valami formázási feladatot végzel olyan helyen ahol igazság szerint nem kéne, mivel a formázás formátuma az a hívott helyhez vagy még beljebbhez tartozik, tehát annyi az encapsulation-nek.
    Mutasd a teljes hozzászólást!
  • Szimpatikusak egyébként az ötleteid.
    A TODO-kat egyébként most is lehet jobb eszközökkel már keresgélni, de a te itt felvetett megközelítésed nekem is jobban tetszik!

    Ezt már nem is neked, hanem ha valaki tényleg nem lenne biztos abban, hogy van értelme (mondjuk dokumentációs) kommentnek:

    /// <summary> /// Helper function to try stopping our rotation with the engines in the using current physical state and velocities of the object /// </summary> /// <param name="angularVelocity">Current angular velocity direction</param> /// <param name="radiansPerSecond">Current magnitude of the angular velocity</param> /// <returns>A value of false if we have already stopped rotation according to the global reference frame(indicating desired state), true otherwise (indicating ongoing operations)</returns> private bool updateStoppingRotation(Vector3 angularVelocity, float radiansPerSecond)
    Szerintem ezt elég nehéz lenne értelmesen kifejezni, de alternatív architektúrához kb. újra kellene írni a unity-t. Cserébe itt mondjuk nagyon fontos lenne az, amiről beszélünk, mert ha elavul a komment az katasztrofális is lehet
    Mutasd a teljes hozzászólást!
  • Igen, de egyszerűen nem érdemes kézzel, túl sok gondot okoz a mergeknél.

    Miért okozna gondot a mergeknél?

    Csak találni kell egy nem túl oszlop pazarló autoformázási beállítást.

    Épp most is ilyen kódon dolgozok, így néz ki egy remek autoformázott forráskód, éles kódból van, így átneveztem a dolgokat:

    valamilyenBean.method("KONSTANS", valamiID, null, "111", ValamiUtil.getValamiErtek(), valami .getValamiObj().getKulcs().toString(), valami.getValamiID().toString(), valami.getValamiID() .toString(), valamiMasOrig.getValamiMas() + " - " + valamiMas.getValamiMas());
    Itt is a hosszú sorok és a rengeteg paraméterből egyből gyanút foghatunk, hogy itt egy gánnyal van dolgunk, amit kicsit átalakítva, sokkal rövidebb sorokat és olvashatóbb kódot kaphatunk.
    Mutasd a teljes hozzászólást!
  • Próbáltam direkt olyan példát mondani, amit nem kell túlbonyolítani és elég csak az IDE-t módosítani.

    Teljesen jó volt a példa és értem a lényegét.
    Ha mindenki ugyanazt az IDE-t kell használja és lelkiismeretesen használná is, akkor még akár hasznos dolog is lehetne.
    Annyival még tovább is viszem a gondolatod, hogy akár többféle jelölés is lehetne:
    - paraméter,
    - visszatérési érték vagy a
    - metódus törzse változott.

    Illetve, ha el akarnánk kerülni, hogy más IDE vagy szövegszerkesztő használata esetén ne legyen ilyen jelölés, akkor ezt nem is IDE-s pluginben kellene megvalósítani, hanem inkább Git-es hookban.

    Azért van egy kis félelmem, hogy legtöbbször gondolkodás nélkül zöldítenének.

    Úgy látom nem világos: A kommentben nem feltétlenül azt írod le, hogy mit csinál a kód, hanem inkább azt, hogy miért csinálja.

    Igen, azt hiszem félreértettelek. A dokumentációs kommentet (ami a metódusok, class-ok előtt van), azokat én nem is tekintem kommentnek, hanem szimplán dokumentációnak. Így aztán azokat teljesen helyénvalónak gondolom.
    Nekem csak a kód törzsben elhelyezett kommentek nagy részével van bajom. Pl. ott is elfogadom a // TODO és hasonlók használatát, bár erre is jobb volna kódot használni!
    Pl. mennyivel lenne rosszabb a // TODO helyett a TODO("Mit kell még megcsinálni!")?
    Ha ez naplózik is, akkor a futó program naplójából ordítana, hogy van még mit csinálni.
    Ha meg hibát generál (fail fast), akkor meg még gyorsabban kiderülne és javításra kerülne!
    Mutasd a teljes hozzászólást!
  • Nem is arra volt példa. Arra volt példa, hogy egyes emberek a meggondolatlan szabályaikkal mekkora problémákat tudnak okozni.

    Értelek, és nagyon egyet is értek. Valóban úgy tűnik, hogy az említett személy által alkalmazott szabályok valószínűleg nem szültek jól olvasható kódot.
    Azonban én nem Őt és a szabályait próbáltam védeni, hanem azzal nem értek egyet, hogy szükség lenne a 160 karakteres sorokra. Sőt azt mondom, hogy azok olvashatatlanabbá teszik a kódot és átgondolatlanságról tanúskodnak.

    Lehet hogy az elsővel sokkal olvashatóbb... de nagyon gyorsan elfogyik a 120 karakter a sorból.

    Nem olvashatóbb és feleslegesen hosszú is.
    Így még olvashatóbb:

    harmadikParam = harmadikMetodus(z) masodikParam = masikMetodus(x, harmadikParam, y) metodusHivas(a, masodikParam, c)
    Ha védeni akarod a 160 karakteres hosszt, akkor inkább olyanra hozz példát, ahol szerinted annál nem lehet olvashatóbban megírni rövidebben és/vagy több sorban.

    Nem tudom milyen egymásba ágyazásra gondolsz, kérlek pontosítsd.

    Függvények hívásának (mint amilyen a fenti példa is volt), ciklusok, feltételek egymásba ágyazására.

    mert az új formázási szabályok miatt hirtelen 60 karakterrel beljebb lett tabulálva, nem lett olvashatóbb a kód.

    Egyetértek, ez teljes eszementség. Az egyik legrosszabb kódformázás a paraméterek, változók egymáshoz igazítása, amikor egymás alatt kell kezdődjenek.
    Egyrészt nagyon könnyen szétcsúszik, másrészről rengeteg időt is el tud venni az igazítgatás, harmadrészt és ez a legfontosabb, feleslegesen pazaroljuk el a helyet és toljuk a kódot a hosszú sorok világa felé.

    Azt hiszem nagyrészt egyetértünk, amiben nem, abban meg valószínűleg nem is fogunk!
    Mutasd a teljes hozzászólást!
  • Ez nem (csak) az IDE-ken múlik. A logikai összekötésnek meg kell jelenjen a forráskódban is, valamint annak is, hogy valid/invalid.

    Próbáltam direkt olyan példát mondani, amit nem kell túlbonyolítani és elég csak az IDE-t módosítani. A dokumentációs kommentelt függvény jelenleg mondjuk így néz ki (javadoc-ot feltételezve):

    /** * This method is not doing anything at all * */ public void nothing(){ // NO-OP }

    Ha valaki van olyan agyas, hogy ezt refaktorálja úgy, hogy:

    /*! * This method is not doing anything at all * */ public void nothing(int time) { Thread.sleep(time); }
    Akkor az IDE feladata annyi volt, hogy szerkesztés esetén:
    1.) Megkeresse a függvény elejét (ezt egyébként is már most is tudja)
    2.) Ha van előtte a fenti két fajtából származó dokumentációs komment, akkor azokat jelölje meg !-jeles állapotúra
    3.) Ha a dokumentációs komment /*! szimbólumokkal kezdődik, akkor sárga, vagy valami warning színnel jelenítse meg

    Ha éppen nem lenne elég hobbi és nem-hobbi projektem, akkor szerintem ezt pl. eclipse pluginként eléggé egyszerűen meg is írhatnám, majd talán egyszer megcsinálom.

    Abba most lehetőleg ne kössünk már bele, hogy mennyire mondvacsinált a példa. Ilyen korai órában nem akarok csak azért keresgélni olyan részeket, amelyek (pl. szálkezelési, vagy egyéb tulajdonságok miatt) kommentekkel kell hogy el legyenek látva azon túl, amit maga a kód nyilván kifejez. Például ha használtok saját aspektusokat, vagy annotációkat (AOP), akkor elég hasznosak a dokumentációs kommentek, ha mindenképpen példát akarsz, de ilyen esetben az implementáció nem triviális. A függvények és osztályok esetében azért tökre kivitelezhető.

    Mellesleg így nem szorulnál rá mondat-hosszúságú névadásra sem. Jelenleg első körben azt csinálom, hogy a függvények eleve csak olyan kis dolgot csináljanak, amit miatt nem szükséges nekik hosszú név, de mindenképpen kialakul egy hosszú név olyan függvények esetén, amelyek tényleg logikailag összetartozó komplex műveletsort tartalmaznak, sok helyről hívandók, viszont a való életbeli üzleti folyamathoz még nem köthetők. Most kitalálhat az ember valami terminológiát ilyenkor, vagy leírhatja, hogy mit csinál. Jelenleg ezt a névbe szoktam röviden és a kommentbe nem feltétlen röviden azt, hogy miért is pont így csinálja (pl. van, hogy referálok üzleti doksira, amiben az ok van). Ezzel a módszerrel kicsit magabiztosabban tehetem ezt meg és egyáltalán nem nyilvánvaló, hogy miért jobb egy hosszú nevű függvényt hívni, mint egy rövidet, ami dokumentált - viszont továbbra is értelmes nevű, csak az előfeltétel pl. nem a névbe van kódolva!

    Na mármost ez vagy változik, vagy nem, de a fenti kis egyszerű plugin használatával legalább warning-szinten látszana, hogy mi a helyzet. Ha ezt még enforce-olni is akarod, akkor csinálsz egy kis findbugs kiegészítést, vagy pre-commit git hook-ot, amiben ellenőrzöd, hogy valaki tölt-e fel !-jeles kommentet és ha igen, akkor nem engeded kommitálni, csak egy speciális branch-be, ahol szükséges egy review. Ez utóbbi szerintem felesleges túlzás, csak szerettem volna megmutatni azoknak is a lehetőséget, akik ilyesmikért rajonganak. Ha ezeket persze valaki úgy kezeli, hogy ha módosítja a függvényt, akkor reflexből elfogadja a kommentet hozzá, mert letojja, akkor szerintem arra is hasonló eséllyel tudod rávenni, hogy szép kódot írjon.

    Ha még ez pöpecül működne is, akkor sem látom, hogy mivel lenne ez jobb, mint ha a kód eleve olyan lenne, amihez nem kell komment.

    Úgy látom nem világos: A kommentben nem feltétlenül azt írod le, hogy mit csinál a kód, hanem inkább azt, hogy miért csinálja. A programozási nyelv véges, de a szemantikai jelentéstartalom amit ki tudsz fejezni vele fejezni mindig nagyobb, mint amit a kódszelet elolvasása adni tud. Ennek oka lehet olyan, hogy az adott nyelvben valamire nincs lehetőség, lehet egyenesen üzleti oka annak, hogy kötelező egy fura viselkedést valósítani meg és lehet természetesen technikai jellegű oka, vagy nehezen kifejezhető bonyolultság (pl. szálak, sorrendiség, miért lett valami "@Deprecated", stb. stb.)
    Mutasd a teljes hozzászólást!
  • "1) A kódok nagyrésze kaptafa kód. Nagyon nagyon ... nagyon nagy része."

    Na és? Általánosságban beszélünk.

    "De ha kódról van szó, akkor azt úgy kell írni, hogy nem feltételezheted, hogy a dokumentációt a karbantartó személy olvasta."

    Nem feltételezheted, de az ellenkezőjét sem. Nem feltételezéseken múlik.

    "És? A kódot az üzlet nyelvén kell írni, nem a hétköznapi ember nyelvén. Aki normális munkát akar végezni, annak tisztában kell lenni az alapvető üzleti fogalmakkal. Másképp olyan valamit akar lekódolni, amit nem ért, ami a tökéletes recept a gány kódhoz."

    Rengeteg feladatnál az első lépés az, hogy az üzleti részét leképezed absztrakt matematikai formába, a mindenféle üzleti struktúrát pedig absztrakt struktúrává. Teljesen analóg a szöveges feladattal. A végén úgyis egyenlet lett belőle. Onnantól hiába érted az üzleti részét, azok a fogalmak meg sem fognak jelenni a kód egy részében. Ami utóbbi mondjuk 15-20%-ig módosított formája egy speciális (kifejezetten matematikai) algoritmusnak, tehát mondjuk külön neve lett olyan dolgoknak, amiket soha el nem nevezett még senki (viszont nem akarod a leírását névnek használni, hogy ne legyen 150 karakteres neve). Meg mondjuk optimalizálás miatt át lett szabva egy-két része, ránézésre nem nyilvánvalóra. Good luck doksi nélkül.

    "olyan szintű absztrakció, aminek nincs neve? - Ez mi? Üzleti absztrakció? Ha üzleti akkor van neve, max te nem tudsz róla"

    Mondjuk ott helyben találom ki. Valami absztrakt művelet, aminek nincs common sense neve, azt sem tudnád, hogy keress rá. Vagy osztályhierarchiában olyan közbülső absztrakt osztály, ami ott és akkor működő absztrakció, de soha más számára nem kellett, ezért nincs jó neve

    "Persze ne felejsd el, hogy kommentelni szabad, sőt ha olyan kódot írsz, amiből nem látszik a szándék vagy félreérthető, akkor kell is."

    Na, tehát szerinted is van helye a dokumentációnak.
    Mutasd a teljes hozzászólást!
  • Gondold csak át és megérted miért mondom azt, hogy a kód megértéséhez _lehetőség szerint_ ne kelljen doksi.

    Nem látok rá lehetőséget. Szerintem a követelményeket nem a kódban kell rögzíteni, viszont kötelező őket rögzíteni. Ha a követelményeket nem olvastad el, akkor érted a kódot, de nem érted a feladatot. Ha bugot reportálnak, értened kell a feladatot is nem csak a kódot, ami adott esetben nem is biztos, hogy jó, különben nem tudod eldönteni hogy a probléma a kódsorok közt, avagy a billentyűzet és a szék között van.

    A komment nem arra való, hogy a fent említett dokumentációt beletedd a forrásba, ezt te is elismerted.

    Algoritmus dokumentáció esetén mennyiségtől függő, pár sor még elmegy a kódban is, hosszabb már nem praktikus. Követelmények minden esetben külön helyen, nem a kódban.

    Tehát dokumentálod azokat a részeket, amik nem maguktól értetődőek? Mintha olyat írtam volna, hogy ezt illik is. Olvass nyugodtan vissza. A kód többi részét viszont úgy kell írni, hogy a bonyorult részek aránya minimális legyen. Ha valamit le tudsz írni 20 sorban "okosan" és kommentelve vagy 60 sorban, komment nélkül és egyértelműen, akkor a 60 soros a jobb megoldás.

    Nem minden esetben egyértelműen jobb a 60 soros megoldás. Ha a 20 és 60 soros változat teljesítményében jelentős különbség van a 20 soros javára, és teljesítmény szempontból kritikus helyen van (nagyon gyakran használt kód ami befolyásolja az SLA-kban rögzített max futási idejű művelet futási idejét), akkor nem jobb megoldás a 60 soros megoldás, és említettem olyan dolgokat (pl. kód refaktorálása külön metódusba azon az áron, hogy további objektumokat kell példányosíts vagy heap-en elhelyezz, hogy két vagy több változó változásait vissza tudd adni a metódusból) amik a jobb kinézetű és a jobb teljesítményű verziók közötti döntést tehetik szükségessé.

    Ha a 60 soros verzióval nem teljesíted az SLA-t a 20-assal meg igen, akkor nyilván nem választhatod a 60 sorost hiába néz ki esetleg szebben.
    Mutasd a teljes hozzászólást!
  • Tapasztalataim alapján hosszú távon megmutatkozik abban, hogy sokkal kevesebb időt kell eltölteni azzal, hogy egy meglévő kódot átvegyél, ha rendelkezésre áll a megfelelő követelmény specifikáció, algoritmus design doksi mint ha olyan dolgokat kell újra megérteni amiket a cégnél már senki nem tud, mert már rég nincs senki a cégnél aki válaszolni tudna a kérdésekre, hogy mi miért van így implementálva.

    Ezt nem is vitattam. Jó, ha van doksi, sőt sokat segít a szoftver megértésében. De ha kódot írsz, akkor ne úgy írd, hogy feltételezed azt, hogy annak aki elővette a kódod még rendelkezésére áll a dokumentáció. Láttál olyat, hogy nem volt meg vagy nem up-to-date? Gondolom számtalanszor a 20 éves karriered során. Gondold csak át és megérted miért mondom azt, hogy a kód megértéséhez _lehetőség szerint_ ne kelljen doksi. (>>Lehetőség szerint<<, nyilván doksi nélkül nehezebb az élet)

    De ha már úgy írsz kódot, hogy a megértéshez ne kelljen doksi, akkor mindössze két eszközöd maradt. Maga a kód és a kommentek. A komment nem arra való, hogy a fent említett dokumentációt beletedd a forrásba, ezt te is elismerted.

    Én a magam részéről a bonyolultabb algoritmusaimat mindig dokumentálom

    Tehát dokumentálod azokat a részeket, amik nem maguktól értetődőek? Mintha olyat írtam volna, hogy ezt illik is. Olvass nyugodtan vissza. A kód többi részét viszont úgy kell írni, hogy a bonyorult részek aránya minimális legyen. Ha valamit le tudsz írni 20 sorban "okosan" és kommentelve vagy 60 sorban, komment nélkül és egyértelműen, akkor a 60 soros a jobb megoldás.
    Mutasd a teljes hozzászólást!
  • De használom. Ne hidd, hogy amikor a problémákat sorolom, akkor feltételezem, hogy azokat a vezetőség nem probálja meg folyamatokkal megelőzni vagy amikor előkerülnek akkor kezelni.

    Ez továbbra sem indokolja, hogy kategorikusan használd. Nem tudhatod biztosra, hogy azokat a problémákat amik nálatok felmerültek, sehol nem tudták mindet megoldani.

    Én valószínűbbnek tartom, hogy van olyan terméket vagy saját rendszert fejlesztő cég, ahol ezeket a problémákat megoldották az általuk fejlesztett termék kódjával kapcsolatban, még ha akár a nagy többségre ez nem is igaz. Ha ezeket megoldották, akkor feltehetően azok a megoldások más cégeknél, akár megrendelőknek fejlesztő cégeknél is használhatók lennének.
    Mutasd a teljes hozzászólást!
  • Egyébként próbáld ki mekkora effort egy kvázi tökéletes folyamat fenntartása. Fogd 3-4 barátod, találjatok ki valamit és csináljátok meg. Folyamat szerint, megtervezve, dokumentálva, kódminőségre odafigyelve. Garantálom, hogy egy hónap után nem fogsz ennyire ragaszkodni a "meg lehet oldani csak akarni kell" mentalitáshoz.

    Tapasztalataim alapján hosszú távon megmutatkozik abban, hogy sokkal kevesebb időt kell eltölteni azzal, hogy egy meglévő kódot átvegyél, ha rendelkezésre áll a megfelelő követelmény specifikáció, algoritmus design doksi mint ha olyan dolgokat kell újra megérteni amiket a cégnél már senki nem tud, mert már rég nincs senki a cégnél aki válaszolni tudna a kérdésekre, hogy mi miért van így implementálva. 

    Én a magam részéről a bonyolultabb algoritmusaimat mindig dokumentálom, pedig nagyon jó vagyok abban hogy akár mások által írt spagettit is kibogozzak, tehát nem nekem lenne szükségem utána az általam írt kommentekre. És nem 1 hónapja, hanem 20 éve csinálom ezt. És nem egy-két személyes projekteken, hanem nagyokon.

    A szabályok nagy részét lehet automatizálni, tehát az csak egyszeri költséget igényel. A dokumentum struktúrát ki lehet találni úgy, hogy a linkek ne váljanak használhatatlanná tömegével.

    A bonyolultabb algoritmusok nem tartózkodnak minden osztályban, és nem minden változtatás egy bonyolultabb algoritmus osztályán jelent szükséges változtatást a mellékelt doksin. Sőt. Az eredeti követelmények túl gyakran nem változnak. Emiatt a nem egyszeri költséget nem kell minden alkalommal megfizetni, így az elamortizálódik a sok változtatáson.

    Ha jól ki van találva a folyamat, akkor nem kerül túlságosan nagy költségbe hogy fenntartsd, és ezzel a költséggel lehet becsülni (nem kiszámíthatatlan). 

    Ha a másik irányt fogadod el, mint status quo-t, akkor elég hamar eljutsz egy olyan pontra, hogy bármikor kellemetlen meglepetések érhetnek, nem lehet pontosan munkát becsülni, és összességében sokkal több energiát fordítasz a nem megfelelő processz által kiváltott felesleges dolgokra és a problémák ellensúlyozására. Hovatovább előbb-utóbb teljesen karbantarthatatlan lesz a kód és nem mertek egyetlen változtatást sem bevállalni.

    Jobb egy kiszámítható költség, még akkor is ha marginálisan nagyobb mint a kiszámíthatatlan. És hosszabb távon a kiszámítható költség kisebb is lesz mint a kiszámíthatatlan, pláne ha az a végtelenbe tart mert nem mered bevállalni az új követelményeket.
    Mutasd a teljes hozzászólást!
  • De ha kódról van szó, akkor azt úgy kell írni, hogy nem feltételezheted, hogy a dokumentációt a karbantartó személy olvasta.

    Ha az illető nem tudja milyen feladatot lát el a kód és nem olvasta a dokumentációt, akkor egy bonyolult algoritmus esetén, pláne ha üzlet-specifikus feltételek vannak benne, nem fogja megérteni az algoritmust, megértés alatt értve azt, hogy tudja melyik feltétel és döntés mi miatt van úgy.

    Azt fogja látni mit csinál a kód. De hogy a kód bugmentes azt ugye nem tudjuk garantálni, sőt, valószínűleg pont azért kellett elővennie, mert bugot kell benne javítania.

    Tehát lehet hogy amit "megért" belőle, az eleve hibás, és nem fogja tudni eldönteni, hogy a bug report az jogos vagy sem (works as intended). Ahhoz a döntéshez ugyanis az kéne, mi a helyes követelmény, nem pedig csak az hogy a valószínűleg bugos kód mit csinál.
    Mutasd a teljes hozzászólást!
  • A de a gyakorlat azt mutatja jellegű érveléseket légy szíves ne használd kategorikusan

    De használom. Ne hidd, hogy amikor a problémákat sorolom, akkor feltételezem, hogy azokat a vezetőség nem probálja meg folyamatokkal megelőzni vagy amikor előkerülnek akkor kezelni. A lényeg, hogy a szoftverfejlesztés egy összetett és bonyorult folyamat, ami az emberek természeténél fogva nehezen megy. Hibák vannak, lesznek a legjobb helyeken is, amik sokszor a legjobban kitalált folyamatokat is aláássák.

    Egyébként próbáld ki mekkora effort egy kvázi tökéletes folyamat fenntartása. Fogd 3-4 barátod, találjatok ki valamit és csináljátok meg. Folyamat szerint, megtervezve, dokumentálva, kódminőségre odafigyelve. Garantálom, hogy egy hónap után nem fogsz ennyire ragaszkodni a "meg lehet oldani csak akarni kell" mentalitáshoz.
    Mutasd a teljes hozzászólást!
  • Attól, hogy ugyanazt nem egy sorba írod, hanem ötbe, attól egy szemernyit sem lesz több boilerplate kód.

    Nem is arra volt példa. Arra volt példa, hogy egyes emberek a meggondolatlan szabályaikkal mekkora problémákat tudnak okozni. Az ürge arra hivatkozott, hogy ettől olvashatóbb lesz a kód, de csak azt érte el, hogy 5-ször annyi boilerplate sor közül kellett kisilabizálni azt az X mennyiségű hasznos sort, ergo egy képernyőn eleve sokkal kevesebb hasznos, nem boilerplate sort láttál, de legalább teljesen értelmetlen neveket is adott az általa bevezetett dolgoknak, mint Impl, Utils... (ezek nem név végződések hanem a belső osztályok nevei).

    Ha minden paraméter nem fér el egy sorban, akkor sokkal jobban olvasható és érthető, ha a paraméterek külön sorokban vannak.

    Ezzel egyet tudok érteni. A problémát az okozta, hogy a 120 karakteres oszlop limit volt, miközben a paraméterek nem 4 karakterrel beljebb kezdődtek, hanem a hívott metódus neve utáni oszlopban. Így már nagyon gyorsan elfogy az a 120 karakter. Példa:

    metodusHivas(a, masikMetodus(x, harmadikMetodus(z), y), c)
    vagy

    metodusHivas( a, masikMetodus( x, harmadikMetodus(z), y), c)
    Lehet hogy az elsővel sokkal olvashatóbb... de nagyon gyorsan elfogyik a 120 karakter a sorból.
    Valamint az anonim osztályok paraméternek átadásakor (pl. Spring template metódusok callback paraméterei) nagyon eldurvul a formázás, és máris nem sokkal olvashatóbb mert az egész anonim osztály be van indentálva akár 80 karakterrel... de attól persze még metódusdeklarációkat akar a maradék 40-re beformázni...

    Mint mondtam... a probléma a szabályok ész nélküli alkalmazása anélkül hogy megnézné mi a következmény, pláne ha egy összefüggő szabályrendszer bizonyos részeit amik arra lennének hivatottak, hogy a többi szabály által okozott problémákat ellensúlyozza... pl. bevezet olyan dolgokat amik megnövelik az indentálást, de nem engedélyez olyan dolgokat amik csökkentenék a továbbra is kötelezően egy sorba rakott részek hosszát (pl. nem engedélyezi a típus paraméterek sortörését ami nem engedi más tényezőkkel csökkenteni a metódus/konstruktor hívások okozta tabulációt).

    Ha jól értem, most azzal véded a rosszul tervezett kódot, hogy másik rosszul tervezett kódhoz tartozik?

    Nem. Nem a rosszul tervezett kódot védem, hanem a gondolkodás nélkül bevezetett szabályokat támadom, bármilyen esetben. Először nézze meg mi egy szabály eredménye, ne pedig a saját feje után rohanjon mint egy elszabadult hajóágyú, csak mert valahol valamit olvasott, és most be akarja vezetni.

    Nem is a paraméterek a legrosszabbak, hanem a túlzott mélységű egymásba ágyazások.

    Nem tudom milyen egymásba ágyazásra gondolsz, kérlek pontosítsd.

    Nekem meg az furcsa, hogy egyesek ész nélkül hadakoznak minden ellen, amit nem úgy használnak, nem úgy szoktak meg, és meg sem próbálnak belegondolni, esetleg kipróbálni, hogy hátha tényleg van annak értelme.

    Nem ész nélkül hadakozok minden ellen amit más javasol, csak azt mondom, először nézze meg mit eredményez az, ha bevezet valamit.
    Ha hirtelen három oldal értelmetlen nevekkel megspékelt szemét közül kell kibogarásznom azt, ami eddig 20 sorban elfért, attól nem lett olvashatóbb a kód.

    Attól hogy egy callback anonim osztály (tegyük fel hogy nem tudsz lambdát használni ott mert mondjuk még mindig Java7 a projekt) amin eddig 100 oszloppal gazdálkodhatott az autoformázó most hirtelen 40 oszlopba kell beférjen, mert az új formázási szabályok miatt hirtelen 60 karakterrel beljebb lett tabulálva, nem lett olvashatóbb a kód.

    Az én példámban háromnak kellett elférnie egymás mellett (3 utas diff/merge). ;)

    Azt jobb szeretem, ha a base felül van, a két ág egymás mellett base-hez képesti színkódolással, szóval még mindig 2 nem 3.

    ( Mellesleg kézzel mindig jobban meg tudod formázni, mint a legjobb automaták. )

    Igen, de egyszerűen nem érdemes kézzel, túl sok gondot okoz a mergeknél. Csak találni kell egy nem túl oszlop pazarló autoformázási beállítást.

    Sokkal jobb az auto-formázás (és whitespace és newline kanonizálás) a pre-commit hook-ban, és akkor nem kapsz egy csomó merge konfliktust kizárólag whitespace és sor különbségek miatt.
    Mutasd a teljes hozzászólást!
  • Jó kódról volt szó. Ha 8 mondatban tudod csak leírni, hogy mit csinál egy metódus, akkor azt akár egy osztályba is kiemelheted. De mondjuk 8 másik metódusra biztosan. Egyébként nem ismerek olyan fordítót, ami hibát dobna, ha mondjuk egy metódus neve 1 igéből, 1 főnévből és 2 melléknévből áll.

    Nem emlékszem arra, hogy specifikáltuk volna, hogy jó kódról van szó, és attól hogy valaki ilyen vagy olyan szabályait kielégíti, attól még nem lesz jó kód. Viszont a szabályok lehetnek indokolatlanul szigorúak.
    Pl. folyton azzal jön valaki, hogy egy metódusnév ne legyen túl hosszú, és általában az érvelés (nem feltétlenül ebben a fórumszálban, hogy ha 1 dolgot csinál valami, akkor két szóban le lehet írni mit csinál, tehát 2 szónál több az sok).

    Nem 8 mondatról beszéltem, de 4-5 szó szükséges lehet egy metódusnévben néha.

    És nem mindig lehet mindent kiemelni másik metódusba vagy osztályba, mert pl. ha egy kódrészlet két olyan változót is ír azonos feltételtől függően úgy hogy mindkét változót használod még később, akkor nem tudod kiemelni másik metódusba olyan egyszerűen tekintve hogy csak egy változó változását tudod visszaadni. Ekkor vagy valami plusz objektumot adsz vissza ami felesleges allokáció, vagy plusz objektumot definiálsz paraméternek ami wrappeli a két változót amit vissza akarsz adni, ekkor pedig legalábbis lassítottál a kódon a folytonos változó írások miatt ha a JIT valamiért nem akarja azt az objektumot stacken allokálni.

    Sok linkkel találkoztam már kódban. Úgy 100%-a nem működik, mert akkor még másik cég fejlesztette a szoftvert. Meg az SPS-t/wiki-t átkötöztettük máshova. Meg át lett struktúrálva az egész és aki ezt csinálta nem tudta, hogy az adott doksira kódokban hivatkozások vannak.

    Ez a cég és a processzek hibája. A kérdéses doksiba ugyanúgy el lehet (célszerű) helyezni egy megjegyzést, hogy ez a doksi hivatkozva van a kódból, az SVN ebből és ebből a filejából és revíziójából.

    Egész wiki költöztetésére megoldás lenne a permalink. Meg lehet a megfelelő processzeket találni az ilyen problémák megoldására, azért mert senki nem gondolkozott előre, azért nem a megoldás a rossz hanem aki nem gondolkodik. Ezért vannak fejlesztési processzek, hogy ezeket a problémákat előre lássák.

    Másrészt nem kell a linknek feltétlenül a source control-ból sem kimutatnia. Elég egy relatív link egy doc folderre a project source control repository-jában.

    Hosszú élettartamú és ezáltal kifejezetten bonyorult szoftvereknél viszont ilyen nincs.

    Ahol gondolkoznak, ott miért ne lehetne. Azért mert csak előre nem gondolkozó, megfelelő processzekkel nem jelentkező cégeknél vagy módszerekkel vezetett projekteket láttál, abból még nem kell általánosítani.

    És akkor legyen a kódban több ezer oldalnyi üzleti szabály olyan részletesen, amilyen még a tényleges üzleti emberek doksijaiban sincs?

    Nem mondtam, hogy a kódban legyen feltétlenül. Azért mert szerinted a linkelt doksi megoldhatatlan, nem jelenti azt, hogy ez valóban úgy van. És a szabályok dokumentáltságának részletességére vonatkozó megjegyzéseddel netán azt akarod megidealizálni, hogy nem szabad ledokumentálni még véletlenül sem az összes követelményt?

    Ha azt mondod, hogy igen akkor hajrá, valósítsd meg.

    Most a lustaságot akarod megideologizálni a tisztességes minőségi munkával szemben (amivel mellesleg azt is rögzíted mi volt a megrendelés, tehát van mire mutogatni), vagy mit akarsz ezzel mondani?

    Ha azt mondod, hogy nem, akkor pedig a kezdőnk így sem fogja érteni miről van szó, amíg valaki el nem magyarázza neki.

    Természetesen azt mondom, hogy igen.

    De ha már kezdőnél tartunk. Az üzlethez nem ért, rendben. Nade sokszor a programozáshoz sem!

    Nem azt mondtam hogy a programozáshoz kezdő. Attól még bőven lehet ez az első napja a cégnél, ebből következően a projekten is. Rögtön csuklani szeretnél?

    Az üzlethez nem ért, rendben. Nade sokszor a programozáshoz sem! Akkor ezek szerint minden programba bele kellene csempészni az adott nyelv/környezet működésének a leírását is? Nem is beszélve a magasabb szintű fejlesztői alapműveltségről, mint mondjuk fejlesztési minták, reguláris kifejezések vagy szálkezelés?

    Lásd fent. Nem a programozáshoz kezdő, hanem a projekten/cégnél új.

    Mert a gyakorlat azt mutatja, hogy minden üzletileg egy kicsit is különálló dolgot külön kód valósít meg. Nincs ám olyan, hogy van egy doksid, ami üzleti szegmens szerint tárgyalja a követelményeket, de van egy terméked, amit a lakossági és a kkv szegmensnek is elérhetővé akarsz tenni néhány apró eltéréssel. Persze lehet a termékeknek külön fejezet, csak azért mert a sok közül 1-2 többszegmenses, de akkor máshol fog szétcsúszni a dolog.
    (Ha technikai doksin osztályszintű leírást gondoltál, akkor a fentiek az üzleti követelményekkel furcsán hathatnak, de nyilván az osztályokat is kötni kell a követelményekhez, ahol szintúgy releváns lehet, amit írtam. Továbbá osztály szintű leírás is csak a mesében van. Aki nem mások által felhasználható API-t dokumentál az nem fog több(tíz)ezer osztályt egyesével dokumentálgatni és azt a dokumentációt karban tartani)

    Ezt a kód-doksi számossági leképezési okfejtést ne haragudj, de nem olvastam végig. A de a gyakorlat azt mutatja jellegű érveléseket légy szíves ne használd kategorikusan, mert egyrészt azért mert sok helyen valamit valahogy csinálnak, az nem jelenti 
    - sem azt hogy mindenütt úgy csinálják
    - sem azt, hogy csak úgy lehet csinálni
    - sem azt, hogy az hogy úgy csinálják az jó is

    Nem azt mondtam, hogy minden utolsó Javabeanről külön doksit írj, csak a kód olvasása után nem azonnal nyilvánvaló dolgokról (bonyolultabb algoritmusok).

    Attól, hogy téged nem érdekel az emberek lustasága, az attól még valós.

    De elfogadni, példaként állítani és megideologizálni nem kell. Ha van jobb megoldás, azt ki lehet kényszeríteni. Ha nem kényszeríted ki, akkor csak azt éred el hogy továbbra is silány lesz a munka minősége.

    Becsukhatod a szemed, befoghatod a füled és csinálhatsz úgy, hogy teljesen hétköznapi a tisztán tartott, jól kommentezett és ezek mellé jól dokumentált kód.

    ??? Nem mondtam, hogy hétköznapi. Én csak azt mondtam, hogy lehet jól is csinálni, és amit lehet jól csinálni, azt a jól csinálást ki is lehet kényszeríteni, ha a projektben megvannak a szabályok, a kód review-k, és a szabályokhoz sorozatosan nem igazodó embereket kirugdossák.

    A valóság az, hogy olyan szoftverek felelnek millárdokat érő üzletekért, amelyekkel engem páros lábbal rúgtak volna ki diplomavédésről (hacsak nem a rossz kódminőség lett volna a témám :)).

    Na ebben egyetértünk. Ettől még nem lesz követendő példa.

    Mivel a tapasztalat azt mutatja, hogy az embernek nem megy az, hogy karban tartson egy kódbázist, a hozzá tartozó kommenteket plusz a hozzá tartozó dokumentációt ezért a legegyszerűbb az, hogy ennek nagyrészét elvesszük tőle.

    Ha valamit elveszel tőle, attól még nem érted el, hogy jó minőségű egyéb megoldásokkal helyettesítse azt amit elvettél tőle.

    Valamint szerintem simán adható olyan processz ami által nem kell semmit karbantartani feleslegesen. A dokumentáció tárolása megoldható hogy ne dobja fel a talpát ha átmozgatod egy másik host-ra vagy path-ra, illetve ha a link a source controlon belül marad akkor fel se merül a probléma. Ha a követelmények megváltoznak, igenis a dokumentált követelményeket is aktualizálni kell. Az hogy az algoritmus dokumentációt amire a kódból van hivatkozás is frissítened kell bizonyos esetekben, minimális overhead.

    Aki igényesen dolgozik, az bizony tud olyan kódot írni, amit komment / doksi nélkül, üzleti emberek segítségével át lehet venni.

    Ha meg rendesen dokumentálva van a működési elv és a követelmények, akkor üzleti emberek nélkül is át lehet venni. Rengeteg helyen szembesültem azzal, hogy az üzleti emberek sem értik azt amit meg akarsz tőlük kérdezni. Ha egyszer egy információt megkaptál, azt le kell dokumentálni, mert egyrészt nem biztos hogy egy hét múlva még bárki is képes lesz válaszolni arra a kérdésre, másrészt egy hét múlva lehet hogy belekötnek abba hogy miért így működik nem pedig amúgy, és akkor sokkal jobb ha tudsz mire mutogatni.

    Aki meg nem, annak a kommentjei és a dokumentációja is csapnivaló minőségű lesz.

    Az ilyet úgyis ki kell rúgni. Ha nem képes normális minőségű munkát végezni, minek szenvedsz vele?
    Mutasd a teljes hozzászólást!
  • A 120 karakter akkor is túl kevés. 160 még bőven kényelmesen használható manapság.
    Pláne, hogy mint említettem, az illető rákényszerítette mindenkire a duplatabokat és az inner classait is. Meg a minden paramétert új sorba formázást, meg még egy pár dolgot aminek hatására kb. 5-10-szer annyi boilerplate kód keletkezett mint ami hasznos volt.

    Attól, hogy ugyanazt nem egy sorba írod, hanem ötbe, attól egy szemernyit sem lesz több boilerplate kód. Ha minden paraméter nem fér el egy sorban, akkor sokkal jobban olvasható és érthető, ha a paraméterek külön sorokban vannak. Nem egyszer volt már olyan, hogy tízen paraméteres függvénynél egy csomó időm ráment, hogy azonosítsam, hogy melyik paraméter melyik. Ha külön sorban vannak, akkor a sorszámából azonnal látszik. Tehát nem feltétlen hülyeség ez sem.

    Ez megint egy olyan dolog amit egyesek ész nélkül követnek anélkül hogy belegondolnának mi a következménye ha elkerülik a hosszú sorokat: pl. túl sok paraméter helyett egy befoglaló objektum példányosítása, ami egy sűrűn hívott függvényben fájdalmas tud lenni, de nem mindig tudod kivinni a paraméter csoportosító objektum példányosítását a cikluson kívülre, mert nem feltétlenül a tiéd az objektum szignatúra.

    Ha jól értem, most azzal véded a rosszul tervezett kódot, hogy másik rosszul tervezett kódhoz tartozik? Ha megnézed a legtöbb library-t, akkor nagyon keveset találsz, ahol nagy mennyiségű paraméterek lennének. Ezt a saját kódban is el lehet érni. Nem is a paraméterek a legrosszabbak, hanem a túlzott mélységű egymásba ágyazások.

    Pontosan ezért utálom amikor egyesek ész nélkül idézgetnek dolgokat amiket valahol olvastak anélkül hogy belegondolnának mivel jár a dolog alkalmazása.

    Nekem meg az furcsa, hogy egyesek ész nélkül hadakoznak minden ellen, amit nem úgy használnak, nem úgy szoktak meg, és meg sem próbálnak belegondolni, esetleg kipróbálni, hogy hátha tényleg van annak értelme.

    WQHD (2560x1440) képernyőn nekem 2x160 karakter elfér egymás mellett, és még borravaló is marad.

    Az én példámban háromnak kellett elférnie egymás mellett (3 utas diff/merge). ;)

    Nem, az automata formázás alapvetően nem rossz, csak egy értelmes szabályrendszer kell ami minden IDE-ben ugyanúgy van konfigurálva.

    Nem rossz, sőt nagyon jó, ha sokan dolgoznak együtt és (egyesek) képtelenek kézzel, normálisan formázni a kódot. Ilyenkor elkerülhetetlen és egy áldás!

    ( Mellesleg kézzel mindig jobban meg tudod formázni, mint a legjobb automaták. )
    Mutasd a teljes hozzászólást!
  • Ez kaptafa kódnál jól működik, de vannak olyan szoftverek, amik tele vannak olyan objektummal, osztállyal és művelettel, aminek nincs hétköznapi megfelelője, vagy olyan szintű absztrakció, aminek nincs neve.

    1) A kódok nagyrésze kaptafa kód. Nagyon nagyon ... nagyon nagy része.
    2) Nem írtam, hogy sosem kell kommentezni. Sőt dokumentálni sem árt. De ha kódról van szó, akkor azt úgy kell írni, hogy nem feltételezheted, hogy a dokumentációt a karbantartó személy olvasta.
    3) Nincs hétköznapi megfelelő? - És? A kódot az üzlet nyelvén kell írni, nem a hétköznapi ember nyelvén. Aki normális munkát akar végezni, annak tisztában kell lenni az alapvető üzleti fogalmakkal. Másképp olyan valamit akar lekódolni, amit nem ért, ami a tökéletes recept a gány kódhoz.
    4) olyan szintű absztrakció, aminek nincs neve? - Ez mi? Üzleti absztrakció? Ha üzleti akkor van neve, max te nem tudsz róla. Technikai absztrakció? Ha nem találod fel újra a kereket és általános technikai megoldásokat alkalmazol, akkor egy értelmes fejlesztő ránézésre tudni fogja mit akartál. Persze ne felejsd el, hogy kommentelni szabad, sőt ha olyan kódot írsz, amiből nem látszik a szándék vagy félreérthető, akkor kell is.
    Mutasd a teljes hozzászólást!
  • Húha... Akkor szépen sorban...

    Persze, feltéve ha az egész algoritmusod három lépésből áll. Egy bonyolultabb algoritmusban nem mindig tudod 1 igével meg egy főnévvel vagy melléknévvel összefoglalni mit csinál a metódus.

    Jó kódról volt szó. Ha 8 mondatban tudod csak leírni, hogy mit csinál egy metódus, akkor azt akár egy osztályba is kiemelheted. De mondjuk 8 másik metódusra biztosan. Egyébként nem ismerek olyan fordítót, ami hibát dobna, ha mondjuk egy metódus neve 1 igéből, 1 főnévből és 2 melléknévből áll.

    Vagy elég részletes legyen hogy csak a kommentből meg lehessen érteni az algoritmust (a kód nélkül), vagy tartalmazzon linket valami cégen belüli helyre ahol a megfelelő részletességű leírás megtalálható.

    Sok linkkel találkoztam már kódban. Úgy 100%-a nem működik, mert akkor még másik cég fejlesztette a szoftvert. Meg az SPS-t/wiki-t átkötöztettük máshova. Meg át lett struktúrálva az egész és aki ezt csinálta nem tudta, hogy az adott doksira kódokban hivatkozások vannak. Álomvilágban létezik a kódból doksi hivatkozás. Hosszú élettartamú és ezáltal kifejezetten bonyorult szoftvereknél viszont ilyen nincs.

    Tételezze fel a teljes hozzá nem értést?

    Igen. Lehet hogy ez egy új fejlesztő első feladata.

    És akkor legyen a kódban több ezer oldalnyi üzleti szabály olyan részletesen, amilyen még a tényleges üzleti emberek doksijaiban sincs? Ha azt mondod, hogy igen akkor hajrá, valósítsd meg. Ha azt mondod, hogy nem, akkor pedig a kezdőnk így sem fogja érteni miről van szó, amíg valaki el nem magyarázza neki.
    De ha már kezdőnél tartunk. Az üzlethez nem ért, rendben. Nade sokszor a programozáshoz sem! Akkor ezek szerint minden programba bele kellene csempészni az adott nyelv/környezet működésének a leírását is? Nem is beszélve a magasabb szintű fejlesztői alapműveltségről, mint mondjuk fejlesztési minták, reguláris kifejezések vagy szálkezelés?

    A technikai tervek rá vonatkozó fejezeteiben a probléma a többes szám. Egy doksiban (1 lapon) legyen arra az 1 osztályra vonatkozó minden információ.

    Mert a gyakorlat azt mutatja, hogy minden üzletileg egy kicsit is különálló dolgot külön kód valósít meg. Nincs ám olyan, hogy van egy doksid, ami üzleti szegmens szerint tárgyalja a követelményeket, de van egy terméked, amit a lakossági és a kkv szegmensnek is elérhetővé akarsz tenni néhány apró eltéréssel. Persze lehet a termékeknek külön fejezet, csak azért mert a sok közül 1-2 többszegmenses, de akkor máshol fog szétcsúszni a dolog.
    (Ha technikai doksin osztályszintű leírást gondoltál, akkor a fentiek az üzleti követelményekkel furcsán hathatnak, de nyilván az osztályokat is kötni kell a követelményekhez, ahol szintúgy releváns lehet, amit írtam. Továbbá osztály szintű leírás is csak a mesében van. Aki nem mások által felhasználható API-t dokumentál az nem fog több(tíz)ezer osztályt egyesével dokumentálgatni és azt a dokumentációt karban tartani)

    Az emberek lustasága sosem érdekelt, ha az a minőség rovására ment.

    Attól, hogy téged nem érdekel az emberek lustasága, az attól még valós. Becsukhatod a szemed, befoghatod a füled és csinálhatsz úgy, hogy teljesen hétköznapi a tisztán tartott, jól kommentezett és ezek mellé jól dokumentált kód. A valóság nem ez. A valóság az, hogy olyan szoftverek felelnek millárdokat érő üzletekért, amelyekkel engem páros lábbal rúgtak volna ki diplomavédésről (hacsak nem a rossz kódminőség lett volna a témám :)). Mivel a tapasztalat azt mutatja, hogy az embernek nem megy az, hogy karban tartson egy kódbázist, a hozzá tartozó kommenteket plusz a hozzá tartozó dokumentációt ezért a legegyszerűbb az, hogy ennek nagyrészét elvesszük tőle. Aki igényesen dolgozik, az bizony tud olyan kódot írni, amit komment / doksi nélkül, üzleti emberek segítségével át lehet venni. Aki meg nem, annak a kommentjei és a dokumentációja is csapnivaló minőségű lesz.
    Mutasd a teljes hozzászólást!
  • Összességében a megfelelően megírt kód öndokumentáló eléggé, hogy egy hozzáértő tudjon vele dolgozni.

    Ez kaptafa kódnál jól működik, de vannak olyan szoftverek, amik tele vannak olyan objektummal, osztállyal és művelettel, aminek nincs hétköznapi megfelelője, vagy olyan szintű absztrakció, aminek nincs neve. Olyankor mindegy, milyen nevet adsz neki, lehet, másnap már másikat adnál, mert a név nem következik semmiből és/vagy más csak azt olvasva nem tudja kikövetkeztetni, hogy mi akarna az lenni. Van, amikor van egy fogalomrendszer, amit meg kell tanulni, hogy értsd a kódot. Kinyitsz egy matek könyvet és kihúzod belőle a fogalmak definícióját, szinte esélyed sincs megérteni, mert kb. feltalálod újra azt/reverse engineereled nagyon fáradságos munkával a témát.
    Mutasd a teljes hozzászólást!
  • Ha jók a kódban az elnevezések, akkor abból gond nélkül kiolvasható a szándék.

    Persze, feltéve ha az egész algoritmusod három lépésből áll. Egy bonyolultabb algoritmusban nem mindig tudod 1 igével meg egy főnévvel vagy melléknévvel összefoglalni mit csinál a metódus.

    Ha nem lehet elég kifejező elnevezést találni, akkor még mindig lehet kommentet használni.

    Így van. Pontosan onnan indult az egész, hogy igenis a komment szükséges lehet, nem elég mindig csak a metódusnévre számítani.

    Ha a komment írja le a fejlesztői szándékot, akkor az mennyire legyen részletes

    Vagy elég részletes legyen hogy csak a kommentből meg lehessen érteni az algoritmust (a kód nélkül), vagy tartalmazzon linket valami cégen belüli helyre ahol a megfelelő részletességű leírás megtalálható.

    Tételezze fel, hogy a fejlesztő jártas az adott szoftver üzleti és technikai működésében és elég félszavakból is utalni a szándékra? De hát félszavakat az elnevezésekbe is írhat.

    Nem.

    Tételezze fel a teljes hozzá nem értést?

    Igen. Lehet hogy ez egy új fejlesztő első feladata.

    Kicsit hülyén mutatna, hogy minden változó mellett szerepel a specifikáció és a technikai tervek rá vonatkozó fejezetei.

    Nem. A változó neve alapján legyen könnyen beazonosítható hogy mit jelöl a szöveggel elmagyarázott algoritmusban. A technikai tervek rá vonatkozó fejezeteiben a probléma a többes szám. Egy doksiban (1 lapon) legyen arra az 1 osztályra vonatkozó minden információ.

    Összességében a megfelelően megírt kód öndokumentáló eléggé, hogy egy hozzáértő tudjon vele dolgozni. A hozzáértő azt jelenti, hogy ismeri az üzleti részt és nem azt, hogy látta már az adott kódot.

    Nem feltételezheted a hozzáértőt. Mindig jöhet új ember.

    Továbbá sokkal egyszerűbb csak egy kódot karban tartani, mint a kódot és a hozzá tartozó kommentet is.

    Az emberek lustasága sosem érdekelt, ha az a minőség rovására ment. Ha bonyolult az algoritmus és nem lehet vagy nem érdemes egyszerűsíteni, akkor legyen hozzá elégséges dokumentáció hogy érthető legyen. Többszálú kódnál legyen ott az érvelés arra is, hogy miért szálbiztos az osztály. Ha egyszerű a kód, akkor lehet elég a kód feltéve ha le van fedve (nem kamu) tesztekkel rendesen a teljes állapottér, ekkor a teszt helyettesíti az algoritmus leírását.
    Mutasd a teljes hozzászólást!
  • Neked van egy WQHD monitorod, mindenki más pedig így járt...

    A WQHD-n 330 karakter azt jelenti, hogy FHD-n is van 330 helyett 260 karakter. Full HD pedig szerintem munkahelyen már alap elvárás egy programozói gépnek.

    Persze lehet mondani, hogy minden fejlesztő asztalán alapfelszerelés egy nagy monitor, de azt az asztalt nem viheti mindenhova magával...

    A 24" az nagy monitornak számít? Mert hogy már abban is van jó minőségű WQHD felbontású. Talán már 23"-asban is.

    És notebookban is van FullHD felbontású. Nekem is az van és 6 éve vettem, tehát manapság már drágának se szabad számítson.
    Mutasd a teljes hozzászólást!
  • Ha a kód az egyedüli doksid, akkor ha bugos a kód akkor bugos a doksi is. Ha van valami ami leírja a szándékolt viselkedést, akkor kétes esetben tudjuk hogy mi a bug és mi nem.

    1) Ha jók a kódban az elnevezések, akkor abból gond nélkül kiolvasható a szándék. Ha kód nem azt csinálja, mint az elnevezés akkor az hibára utal. Ha az elnevezés alapján nonsense a folyamat, akkor az is hibára utal. Vedd észre, hogy úgy fogalmaztam "utal" és nem állítottam, hogy hiba is. A debuggolás már csak ilyen és nyilván nem feltételezem, hogy minden mindig tökéletes...
    2) Ha nem lehet elég kifejező elnevezést találni, akkor még mindig lehet kommentet használni.
    3) Ha a komment írja le a fejlesztői szándékot, akkor az mennyire legyen részletes? Tételezze fel, hogy a fejlesztő jártas az adott szoftver üzleti és technikai működésében és elég félszavakból is utalni a szándékra? De hát félszavakat az elnevezésekbe is írhat. Tételezze fel a teljes hozzá nem értést? Kicsit hülyén mutatna, hogy minden változó mellett szerepel a specifikáció és a technikai tervek rá vonatkozó fejezetei.

    Összességében a megfelelően megírt kód öndokumentáló eléggé, hogy egy hozzáértő tudjon vele dolgozni. A hozzáértő azt jelenti, hogy ismeri az üzleti részt és nem azt, hogy látta már az adott kódot. Továbbá sokkal egyszerűbb csak egy kódot karban tartani, mint a kódot és a hozzá tartozó kommentet is.
    Mutasd a teljes hozzászólást!
abcd