Zlepšení čitelnosti vlastního kódu

[JurajP]

Q1: Su knizky od Fawlera hodne citania?
Q2: Robit code review v grupe alebo samostatne?

[Reklama]

[Ink]

Q2: Robit code review v grupe alebo samostatne?

Co je code review v grupě? Všichni koukají do stejného kódu najednou a dohadují se, jak to má být?

[JurajP]

ano, presne tak. skupinka povedzme 4 developerov prezera kod.

[luvar]

ano, presne tak. skupinka povedzme 4 developerov prezera kod.

Moj subjektivny nazor na toto je, ze je to prilis neefektivne. Jeden schopny koder (poznajuci jazyk, problemovu domenu a idealne i projekt) by mal plne stacit. Pri 4 developroch za jednym monitorom sa to imho zvrhne na offtopic velmi rychlo

PS: Ale code review dvoch, ci troch, po sebe iducich ludi by nemusel byt celkom strata casu (ak ide naozaj o extra kvalitu kodu, ktora ma opodstatnenie v letectve, medicine, ci podobne).

[listoper]

...

PS: Ale code review dvoch, ci troch, po sebe iducich ludi by nemusel byt celkom strata casu (ak ide naozaj o extra kvalitu kodu, ktora ma opodstatnenie v letectve, medicine, ci podobne).

U nas delame code review vzdycky tak 3-4 (nadpolovicni vetsina vyvojaru v tymu + nekdo z venku) i kdyz nejsme mission/life critical.
Code review ma jeste jine benefity krom kvality kodu:

• Sireni povedomi. Kdyz uz sem neco jednou videl tak to priste snadneji najdu.
• Junior potrebuje nejen dostavat feedback, ale i se ho naucit davat.
• a urcite by se toho naslo vic

[Reklama]

[PanVP]

skupinka povedzme 4 developerov prezera kod.

A proč ne třeba celá firma? 

toto je, ze je to prilis neefektivne

Přesně tak.

Code review, aby mělo smysl, musí nějakou dobu trvat a účastníci se na něj mají připravit, pročíst si kód.
Představa, že procházím cizí kód za týden - OD ČTYŘ LIDÍ - vlastně pěti (i svůj), protože na codereview se člověk prostě trochu připraví = zabiju tím 5 lidí * 1-2 hodiny každý = celý pracovní den. Resp. zabiju PĚT člověkodní, protože to stejné musí udělat i ti ostatní. Takže jsem ztratil pět člověkodní a to to ještě nezačalo. Plus - nějakou dobu to trvá, takže celkem pět lidí se svým kódem, každý 40 minut? A pak nějaký čas na finální opravy? I kdybych to všechno stihl za jeden den, pořád to musí udělat všech pět lidí a je zabitých 5 pracovních dnů.

Jestli to takhle někdo skutečně dělá, tak musí pracovat leda ve státním.
Nebo plácá.
Nebo tam ty lidi jsou, ale s kódem kolegů se předem neseznámili a vlastně jim je ukradený a chrápou, než na ně přijde řada. Mě teda 1 to 1 přijde jako rozumnější.

A ještě jedna věc, kolegové mají úplně jiný styl.
Často se podívám na kód a vím, kdo ho tam naprasil.
Jejich kód je nejlepší a pak to cpou ostatním, že oni to dělají nejlépe. 

...ale mohu se plést, pletu se často a pletu se rád....

[xPoli]

Na jednom kontraktu nás bylo v týmu 5 programátorů + leader a code review dělalo většinou ještě víc lidí, než programátorů. Typicky ale byli alespoň 3 programátoři z týmu + leader + architekt. Jelo se podle přísných regulí (MISRA a další), takže něco jako vlastní code style každého jednotlivce neexistovalo, možnost poznat autora podle kódu byla velice omezená. Konkrétně tento projekt nebyl life-critical, ale společnost takové produkty dělá, takže byla laťka dost nahoře.

Pro aspoň 95% programování je tento režim overkill, ale něco to do sebe mělo. Každý pár očí vidí něco jiného, každý vidí různá úskalí - složitost algoritmu v různém zatížení, paměťová náročnost, rizika při paralelním přístupu, priority vláken atp. Pokud se má dělat code review v pravém slova smyslu (ne pečlivý git add -p, když člověk dělá solo), tak osobně bych po výše uvedené zkušenosti šel alespoň na 2:1, protože ten vícenásobný pohled na věc je něco, co se většinou vyplatí a ten čas tím strávený není promrhaný - viz zmiňované distribuované povědomí o kódu, odhalení chyb před začleněním atp. Něco pokryjí testy, ale obecně je kód pouze tak dobrý, jak dobré jsou testy a pokrytí kódu testy ještě nic neříká o tom, že se otestují všechny okrajové podmínky, které v nasazení mohou nastat.

[Sam Samovic]

No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

[Pavel Stěhule]

Code review, aby mělo smysl, musí nějakou dobu trvat a účastníci se na něj mají připravit, pročíst si kód.
Představa, že procházím cizí kód za týden - OD ČTYŘ LIDÍ - vlastně pěti (i svůj), protože na codereview se člověk prostě trochu připraví = zabiju tím 5 lidí * 1-2 hodiny každý = celý pracovní den. Resp. zabiju PĚT člověkodní, protože to stejné musí udělat i ti ostatní. Takže jsem ztratil pět člověkodní a to to ještě nezačalo. Plus - nějakou dobu to trvá, takže celkem pět lidí se svým kódem, každý 40 minut? A pak nějaký čas na finální opravy? I kdybych to všechno stihl za jeden den, pořád to musí udělat všech pět lidí a je zabitých 5 pracovních dnů.

...ale mohu se plést, pletu se často a pletu se rád....

U kritických aplikací se tohle běžně dělá - nicméně jsou to úplně jiné ceny. U Postgresu se dělá review každého patche na několika úrovních a běžně se kód přepisuje 10-100x. Nicméně ten kód pak budou používat milióny lidí. Review kódu odděluje okresní přebor od první ligy. Je to jeden z ukazatelů, jak poznat slušnou firmu. V několika firmách v republice jsem to zažil. Samozřejmě, že pokud má firma na jednom produktu jednoho programátora, tak nemá cenu dělat code review, ale tam těžko bude kdokoliv za cokoliv ručit. Máte aplikace, kdy za neplánovaný výpadek se platí penále v jednotkách miliónů, a code review je základ pro kvalitní kód. Záleží, kdo code review dělá a jak. Ale i tak, je tam psychologické hledisko. Špičkový programátor neprasí, ale takových je málo. Normální programátor neprasí, pokud ví, že jeho kód bude číst někdo jiný, a že pokud ho neodsouhlasí, tak ho bude přepisovat.

[xyz]

No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

Protoze jsou blbe pojmenovane promenne. Nazvat promennou number muze jen uplny zacatecnik.

[anonacct]

Legendární Quake rsqrt - ten komentář tam je jen pro lidi, kteří chápou, co se tam děje

[anonacct]

Code review je důležitý - minimálně 2 lidi by ho měli dělat (1 je většinou málo, ale záleží i na velikosti teamu)

Code review tě naučí psát kód tak, aby prošel, a taky tě naučí unést kritiku, což je pro některé jedince celkem důležité.

[Ink]

No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

Protoze jsou blbe pojmenovane promenne. Nazvat promennou number muze jen uplny zacatecnik.

Jo, psal to nějaký Carmack nebo kdo. 

Na druhou stranu bych si tipnul, že dnes to vidí jinak než v devadesátkách. Nejenom co se týče stylu psaní, ale dost vyzdvihnul výhody psaní v Rustu. Ta odmocnina je vcelku sranda, jelikož se tam nešachuje s pamětí, nemutují data apod. a je vcelku zřejmé, co dělá (zadání) i zda to dělá dobře (podle výsledků). V takovém kódu snad ani ty identifikátory nejsou špatně (byť nejsou v souladu s rozumnými obecnými konvencemi).

[xyz]

No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

Protoze jsou blbe pojmenovane promenne. Nazvat promennou number muze jen uplny zacatecnik.

Jo, psal to nějaký Carmack nebo kdo. 

Na druhou stranu bych si tipnul, že dnes to vidí jinak než v devadesátkách. Nejenom co se týče stylu psaní, ale dost vyzdvihnul výhody psaní v Rustu. Ta odmocnina je vcelku sranda, jelikož se tam nešachuje s pamětí, nemutují data apod. a je vcelku zřejmé, co dělá (zadání) i zda to dělá dobře (podle výsledků). V takovém kódu snad ani ty identifikátory nejsou špatně (byť nejsou v souladu s rozumnými obecnými konvencemi).

Ok, beru zpatky, jsem se trochu unahlil :-))
- Carmack neni az tak uplny zacatecnik asi
- nazev number v matematicke funkci je ok.
- vyvoj her je specificky a kdyz by ke kazde funkci psali komentar ve stylu doxygen (javadoc), tak by to dodelali nekdy za 50 let.

[xyz]

No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

Protoze jsou blbe pojmenovane promenne. Nazvat promennou number muze jen uplny zacatecnik.

Jo, psal to nějaký Carmack nebo kdo. 

Na druhou stranu bych si tipnul, že dnes to vidí jinak než v devadesátkách. Nejenom co se týče stylu psaní, ale dost vyzdvihnul výhody psaní v Rustu. Ta odmocnina je vcelku sranda, jelikož se tam nešachuje s pamětí, nemutují data apod. a je vcelku zřejmé, co dělá (zadání) i zda to dělá dobře (podle výsledků). V takovém kódu snad ani ty identifikátory nejsou špatně (byť nejsou v souladu s rozumnými obecnými konvencemi).

Ok, beru zpatky, jsem se trochu unahlil :-))
- Carmack neni az tak uplny zacatecnik asi
- nazev number v matematicke funkci je ok.
- vyvoj her je specificky a kdyz by ke kazde funkci psali komentar ve stylu doxygen (javadoc), tak by to dodelali nekdy za 50 let.

Jeste bych dodal, ze jestli jsem to pochopil spravne, tak jde o nejakou aproximaci SQRT, tak aby byla co nejrychlejsi a davala rozumne vysledky.
Pokud by to bylo treba v nejake numericke knihovne, tak by si to komentar zaslouzilo. Na cem je ten trik zalozen atd....
Ale ve vyvoji her na to neni cas.