Bővebben, ha egy függvényt egy másik függvény visszatérési értékével történő osztással próbálják meg felparaméterezni és utóbbi függvény értéke nulla is lehet, akkor talán nem egy sorban, értékvizsgálat nélkül kéne megtenni.
- Hiena blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Workaround, bár ettől csak nem hasal el:
int g();
int a, b;
f(a / ((b = g()) ? b : 1));
:)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
... hanem meg kell hívni a függvényt kétszer, egyszer hogy megnézzük nulla-e, aztán még egyszer, hogy osszunk vele. Kérdőjel kettőspont operátorral!
Végülis ha az optimálisnál csak kétszer lassabb valaminek a futása, az még optimálisnak tekinthető az ipari standard kb 1000-szereshez képest :-)
- A hozzászóláshoz be kell jelentkezni
Csodálatos megoldás! Főleg, ha a nevezőben lévő függvény minden meghívásakor más a visszatérési értéke. Móka, kacagás minden korosztálynak!
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "
- A hozzászóláshoz be kell jelentkezni
Lehetne jython is, akkor 10^5-szor lassabb es nem tudnad visszagorgetni a terminalban a call trace-t mert nincs az az xterm line buffer meret amibe beleferne :]
- A hozzászóláshoz be kell jelentkezni
Annak a másik függvénynek valid visszatérési értéke a 0 vagy amolyan exception handling?
- A hozzászóláshoz be kell jelentkezni
Valid érték, csak a törtes egyenlethez tartozott kikötés is, amit elfelejtett implemetálni...
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "
- A hozzászóláshoz be kell jelentkezni
Én is találkoztam ilyennel.
Van aki szerint a 200 karakter hosszú, a sorban 4-5 utasítást tartalmazó kód nagyon jól átlátható, szemben azzal, ha ezt 4-5 sorba törjük. :-D
Olyan "sorok" is vannak a kódban, ahol 10-20 függvény hívás van benne.
- A hozzászóláshoz be kell jelentkezni
Most mi a gond? Sokkal faszább, amikor vízszintesen is kell görgetni, mert nincs 40" monitorod mint a másiknak és még ráadásul több kódot is néznél egymás mellett.
Az ilyennek kívánom, hogy debuggolja sokat a kódját, remélhetőleg évekkel később, sűrűn emlegetve saját felmenőit.
- A hozzászóláshoz be kell jelentkezni
Én azt gondolom, hogy egyszerűen csak a megszokás miatt gondolja így.
Ha majd egy kicsit hozzászokik az újhoz, akkor rájön, hogy temérdek helyen visszaköszön, hogy így sokkal egyszerűbb és átláthatóbb, könnyebb a hibát megtalálni.
Pl.
1. NPE hibánál, ha egy sorban egy utasítás van, akkor egyből lehet tudni, hogy mi volt a NULL.
2. Amit írtál is, debug-nál tud mindegyik utasításra külön-külön az adott sorra breakpointot tenni.
3. Ha sok sorba tör egy utasítás sorozatot, akkor abból az is látszik, hogy az túl bonyolult, egyszerűsítésre szorul.
- A hozzászóláshoz be kell jelentkezni
Meg el lehet rejteni dolgokat a képernyő szélén túlra :)
“Any book worth banning is a book worth reading.”
- A hozzászóláshoz be kell jelentkezni
Az automatának vissza kell baszni, hogy több n karakternél a sorhossz és nem mehet a merge.
- A hozzászóláshoz be kell jelentkezni
nálunk a coding standard checker failt dob pr-nál, ha bizonyos formai követelményeknek nem felel meg a kód. nekem lenne jogom mergelni mégis, de még senkinek nem adtam kivételt. magamnak sem!
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
- A hozzászóláshoz be kell jelentkezni