Vlákno názorů k článku Suckless: méně smradlavý software od balki - Nesuhlasim s tym, aby kod mal cim menej...
-
Pavel (neregistrovaný)
Otázka je, co považujete za obfuskaci.
Já byl strašně překvapen, když jsem v potřeboval spočítat, kolik bloků paměti o velikosti K potřebuju na data o velikosti N, napsal jsem:
(N - 1) / K + 1
a bylo mi vynadáno, že tomu nikdo nerozumí, že správně to mám napsat:
N % K == 0 ? N / K : (N / K) + 1
(všimněte si toho závorkování, normální člověk asi neví že dělení má přednost před sčítáním, ač se to učí už na prvním stupni ZŠ a respektuje to drtivá většina programovacích jazyků).
Mě osobně tedy více obfuskuje to "správné" řešení.
-
Pavel (neregistrovaný)
Jo, komentář. Jeden z dalších principů, které jsem musel dodržovat, bylo co nejméně komentářů. Proč? Protože když se hrabe do kódu, většina programátorů se vykašle na příslušnou úpravu komentářů a není nic více obfuskujícího než komentáře popisující jiný kód, než ten, který vidíte.
Ale zpátky. Bylo to v týmu, který dělal různé komunikační protokoly a zarovnávat data musel každý několikrát denně. Přesto pro ty programátory bylo naprosté novum, že se to dá dělat tak jednoduše. To jsem fakt nechápal.
-
Lemming (neregistrovaný)
To je otázka, jaké ty komentáře jsou. Pokud je to stylem:
// Do proměnné A vložíme součet B a C
a = b+c;Tak takové komentáře opravdu radši nepsat.
Komentáře by měly popisovat věci, které se z kódu zjišťují obtížně. Třeba "co k čertu má tahle třída vlastně dělat". Není nic horšího, než mít projekt s desitkami nebo i stovkami vzájemně provázaných tříd, u kterých není vesměs ani čárka o tom, k čemu slouží a jak se vážou na ostatní a člověk to musí složitě louskat z kódu. Ideálně u každé netriviální funkce krátce popsat její kontrakt, hlavně s důrazem na různé speciality. Dál pak u netriviálních kusů kódu popsat co dělají a u překvapivých proč tam jsou.
-
Pavel (neregistrovaný)
Bohužel, pokud ten kód má už nějakou historii, tak se stejně louskání kódu nevyhnete, protože prostě nevíte, jestli ten komentář popisuje "jak to je" nebo "jak to bylo před deseti lety". Už jsem viděl hodně krásně okomentovaných tříd, kde ale metoda s deseti parametry měla podle komentáře parametry jen dva a vracela jiný objekt než podle komentáře.
-
Jose (neregistrovaný)
b = (N + 1)/(K - 1);
2003 se_addi r3,0x1 ; N,1
18DF84FF e_addi r6,r31,-0x1 ; r6,K,-1
7CE333D6 divw r7,r3,r6 ; r7,N,r6
D271 se_stw r7,0x8(r1) ; r7,b(r1)
12 bytes
b = (N % K == 0) ? N / K : (N / K) + 1;
7CDFF1D6 mullw r6,r31,r30 ; r6,K,r30
0736 se_subf r6,r3 ; r6,N
2A06 se_cmpi r6,0x0 ; r6,0
E205 se_bne 0x3DF82
7CE3FBD6 divw r7,r3,r31 ; r7,N,K
D271 se_stw r7,0x8(r1) ; r7,b(r1)
E804 se_b 0x3DF88
18FE8001 e_addi r7,r30,0x1 ; r7,r30,1
D271 se_stw r7,0x8(r1) ; r7,b(r1)
24 bytes
b = N / K + (N % K) ? 1:0;
7CFFE9D6 mullw r7,r31,r29 ; r7,K,r29
0737 se_subf r7,r3 ; r7,N
04D7 se_add r7,r29
2A07 se_cmpi r7,0x0 ; r7,0
E604 se_beq 0x3DF9E
4817 se_li r7,0x1 ; r7,1
D271 se_stw r7,0x8(r1) ; r7,b(r1)
E803 se_b 0x3DFA2
4807 se_li r7,0x0 ; r7,0
D271 se_stw r7,0x8(r1) ; r7,b(r1)
22 bytes
b = N/K - ((N % K) > 0);
05CF se_mullw r31,r28 ; K,r28
7CFF1850 subf r7,r31,r3 ; r7,K,N
7C0700D0 neg r0,r7
7C073878 andc r7,r0,r7
69F7 se_srwi r7,0x1F ; r7,31
07C7 se_subf r7,r28
D271 se_stw r7,0x8(r1) ; r7,b(r1)
20 bytes
Vitezem se stava povodni autor tesne nesledovan a :D, a rozpadlo se mi formatovani ale to uz rozlustite.
-
Pavel (neregistrovaný)
Bohužel, koho chleba jíš, ...
Taky mě štve že dnes se za programátora považuje každý, kdo umí zapnout počítač, v životě neslyšel slovo algoritmus, a když vidí dobře napsaný program, tak si může hlavu ukroutit, protože běžné efektivní postupy jsou nad jeho chápání. Pak člověk vidí takové hrůzy, jako že si tým napsal vlastní String library (protože ta standardní je samozřejmě špatně, plná chyb a neefektivní), a pak ji používá způsobem, že když potřebuje od stringu odříznout prefix REQ: tak napíše "pokud string obsahuje dvojtečku tak najdi pozici první dvojtečky a pokud je 4 tak ho až k dvojtečce odřízni), místo aby prostě po kontrole že začíná REQ: uřízl první čtyři znaky. A důvod takového nesmyslu je, že odříznutí prvních čtyřech znaků je nečitelné, protože programátor jejich kalibru si prostě neumí spočítat počet znaků v konstantě "REQ:"
Podobně jsem viděl (nekecám, opravdu) coding standars, kde se psalo, že když multithreadový program přistupuje ke globální proměnné, tak sice bývá zvykem ten přístup ošetřit mutexem, ale protože je malá pravděpodobnost, že se tam ty thready potkají, tak používaní mutexů je zbytečné a proto se používat nemají, aby se zbytečné nemrhalo CPU timem.
Bohužel takových lidé se živí programováním čím dál víc.
-
> A důvod takového nesmyslu je, že odříznutí prvních čtyřech znaků je nečitelné, protože programátor jejich kalibru si prostě neumí spočítat počet znaků v konstantě "REQ:"
To skutečně nečitelné a problematické být může – ta konstanta je definována někde nahoře a čtyřka je zapsaná kdesi uvnitř kódu. Co se asi tak stane, když někdo rozhodne o změně hodnoty konstanty? Přepíše to nahoře a dole bude chyba.
Měl bys tu 4 odvodit buď z délky řetězce nebo si pro ni definovat konstantu hned vedle té obsahující text a přidat tam komentář, že tyto dvě konstanty je potřeba udržovat v souladu.
-
JS (neregistrovaný)
To jsi ten priklad nejspis pochopil spatne, oni tam tu konstantu 4 porad maji, akorat se pouziva jinak.
Ale fakt je, ze casto to delam, nez abych pojmenovaval konstantu, radeji to spocitam. Duvodem je lepsi citelnost - pokud potrebuji delku na stejnem radku (typicky priklad je strncpy), pak zavadet konstantu nekde na zacatku bloku citelnost spis zhorsuje.
