nem *******ztam tovább

emmentem szavazni oszt yóvan

Utána pedig elgondokkottam ezen.

Hozzászólások

Nagyon megtisztelő, hogy ilyen sokan olvassátok a posztot és még követitek is a linkeket. Kérlek titeket, hogy szavazzatok a dizájnokra! Illetve va van észrevétel, vagy ötlet, akkor kommenteljétek a posztokat! Köszönöm!
--
unix -- több, mint kód. filozófia.
Life is feudal

Az elson szavaztam, bar igazabol kenyszerszavazat volt. Ha az, ami legfelul volt, az a site mostani logoja, akkor igazabol egyik se talalta el teljes mertekben annak a hangulatat.

Ami a magikus szamokat illeti, a kerdes igencsak megoszto tud lenni, raadasul eleve kontextusfuggo is. Amit pl. a panellel csinalsz, ott eleg egyertelmu, hogy mirol van szo, viszont a jelszavas cuccnal - noha szinten egyertelmu a kontextus - en biztos, hogy konstanst hasznalnek, es csak reszben azert, hogy meg egyertelmubb legyen a kontextus - inkabb arrol van szo, hogy ez egy parameter, es a parameterek legkonnyebben ugy valtoztathatoak, ha egy kupacban vannak - marpedig egy szepen szervezett kodban a konstans deklaraciok jobbara egy kupacban vannak. Gondold el, hogy ez a jelszoellenorzes egy 100-200 soros kod kozepeben van benne, te komolyan kepes lennel kiszurni harom-negy ev utan, hogy hol van? Egy konstans viszont olyasvalami, amire akar keresni is lehet, ellentetben egy szimpla hetessel, amire ugyan szinten lehet keresni - aztan sok sikert atbongeszni a kodot erte, hogy melyik hetesre volt szukseged.

--
Blog | @hron84
Üzemeltető macik

Jogos, köszönöm!
Mi a véleményed arról, hogy külön source file-ba tenni a konstansokat? Vagy akkor már inkább properties file?
Létezik, hogy a karbantarthatóság és az olvashatóság ellentétes előjelű erők?
A blogban említettem a karbantarthatóságot, de elsősorban az olvashatóság szempontjából néztem a példákat.
--
unix -- több, mint kód. filozófia.
Life is feudal

Kulon forrasfajlba a konstansokat: ez megint kontextusfuggo. Ha az egesz projektre ervenyes konstansokrol van szo (mittudomen, pl. egy Minecraft mod item nevek konstansairol), akkor tamogatom az otletet, ha kapcsolodasi adatokrol (pl. MySQL kapcsolat), azt inkabb properties fajlba erdemes tenni. Ha csak egy, vagy nehany osztaly hasznalja, akkor inkabb erdemesebb a kontextusban legkozelebb allo osztalyba belerakni publikusnak, es utana csak meghivatkozni.

"Létezik, hogy a karbantarthatóság és az olvashatóság ellentétes előjelű erők?"

Ha nem vakon alkalmazzuk a fejlesztesi paradigmakat, akkor ezek egymas komplementerei tudnak lenni. Minden egyes paradigma alkalmazasa elott at kell gondolni, hogy ad-e ez a fejlesztett szoftverhez erteket akar az olvashatosag, akar a karbantarthatosag teren. El tudom kepzelni, hogy egyes konkret esetekben ket ellentetes megoldas szolgalna a ket kulonbozo celt, azonban ez generikusan nem jelentheto ki egyertelmuen, hiszen a jol olvashato kod jobban karbantarhato, mint az atlathatatlan makaroni kod.

En ezert tartom karosnak azt, hogy minden masodik fejleszto nekiesett TDD-vel kodolni, holott ez lehet, hogy valojaban nem ad erteket a projekthez, nem lesz tole a projekt minosege jobb, raadasul az ilyesmi kepes plusz adminisztracios overhead is lenni. Nem az a baj, hogy a TDD onmagaban nem novelne barmilyen kod minoseget valamelyest, hanem az, hogy attol, hogy egy tesztet egy fos koddal implementalunk, az nem emel a projekt minosegen erdemben.
--
Blog | @hron84
Üzemeltető macik

„az, hogy attol, hogy egy tesztet egy fos koddal implementalunk, az nem emel a projekt minosegen erdemben”

De utána ahhoz a kódhoz sokkal bátrabban merek hozzányúlni, esetleg szebbet faragni belőle. Félre ne érts, szerintem sem a Szent Grál a TDD, de segít kikényszeríteni a teszt-fedettséget.
De, mint kb. mindenhol, gondolkodás nélkül használva, ez sem csodaszer.
--
blogom