Szerinted milyen a "szép kód"?

[quote:d20ae9cb49="Pingvin"]6) Amire nem kell, arra nem írok külön függvényt (pl. van egy két soros összehasonlítás, amit az egész programban kétszer használok, arra fölösleges függvényt gyártani.)

ha 2x szerepel, akkor tessék rá függvényt gyártani :wink:

[quote:c120e94298="Pingvin"]Szerintem szép kód kb annyit jelent, hogy:

3) C, PHP, stb esetében kapcsos zárójeleket mindig új sorba és előre elgondolt
szerkezet szerint rakosgatni.

Attól függ, milyen formázási stílus, lásd Borland C++Builder beállításai (vmikor használtam), szerintem Kylix is ugyanilyen.

A fv-ek törzsében a nyitó kapcsoszárójelet új sorba rakom, utána újsor van, de pl elágazás, ciklus stb esetén az if, while stb kulcsszóval egy sorba, mert máshogy - idegesít, ugyanis nagyon széthúzza a kódot és átláthatatlanná teszi számomra.

[quote:fd0f3cb004="Panther"]A fv-ek törzsében a nyitó kapcsoszárójelet új sorba rakom, utána újsor van, de pl elágazás, ciklus stb esetén az if, while stb kulcsszóval egy sorba, mert máshogy - idegesít, ugyanis nagyon széthúzza a kódot és átláthatatlanná teszi számomra.

Úgy is kell :D

[quote:a2779916fb="Pingvin"]3) C, PHP, stb esetében kapcsos zárójeleket mindig új sorba és előre elgondolt szerkezet szerint rakosgatni.

Itt Panther-rel értek egyet. Érdemes sor végére rakni, mert nem húzza szét a kódot, ezáltal olvashatóbb lesz.

4) Ha valamit meg lehet oldani 2 sorban, akkor az nem csinálom meg 15-ben.

Ha 15 sorban olvashatóbb, mint 2-ben, esetleg még könnyebb is megírni, akkor 15 sorban írom. Az optimalizálás (ilyen alacsony szinten) nem az én feladatom, hanem a fordítóé. Ha a 15 soros kódot egy év múlva könnyebben megértem majd, akkor az a jobb választás.

8.) Minél kevesebb IF -- THEN

Ezt nem értem. Nekem még sosem volt olyan, hogy választani tudtam volna kevesebb és több if között.

11) Minden komolyabb függvényhez (amiről nem látszik első ránézésre, hogy mit csinál) négy-öt soros commentet írok.

És természetesen ez a komment azt meséli el, hogy a függvény _mit_ csinál, mik a bemenő és kimenő paraméterei. Nem azt mondja el, hogy hogyan csinálja, és pláne nem a nyelv szintaktikai elemeit meséli el.

[quote:b2f44e9368="trey"]Na es mi a helyzet a GOTO-val?

IMHO: Meg kell tanulni GOTO nélkül programozni C-ben, és ha már megtanultál, és nagyon jól begyakoroltad, akkor tudni fogod, hogy hol használhatod mégis. C-ben hibakezelésre más lehetőség sajnos nem nagyon van.

A már elhangzott okosságokat igyekszem nem megismételni, csak néhány plusz, leginkább C nyelvre.

- Mindenekelőtt az indentálás, kinézet stb. legyen önmagával konzisztens.

- Az operátorok körül szóköz, hosszabb kifejezés esetén esetleg csak a nagyobb részek elválasztására szóköz, és persze egyértelmű atombiztos zárójelezés növeli az olvashatóságot. Például i=5 helyett i = 5, de mondjuk i = (a + 1) * (b + c) helyett már mehet i = (a+1) * (b+c), de ennél jobban már ne spóroljunk a szóközökkel. Olyasmit, hogy i = a && b || c nem írok le zárójelezés nélkül.

- Fv argumentumok között is a vessző után szóköz.

- Beépített C parancsok nevei után én hagyok, de függvények nevei után nem hagyok szóközt. Például for (i = 1; i <= 10; i++), de fprintf(stderr, "...");

- A return után nem teszek zárójelet. Aki zárójelbe teszi a return argumentumát, az szerintem nem érti, hogy miről szól ez a parancs, mert ezt is függvényhívásnak tekinti.

- Kerülöm a hátultesztelős (do... while) ciklusokat, mert C-ben csúnya lesz tőlük a tabulálás, általában szerintem nehezebben olvashatóbb, természetellenesebb az elöltesztelősnél, és abszolút nem érdekel, ha emiatt eggyel többször ellenőriz fölöslegesen a kód a ciklusba belépéskor.

- Beszédes angol változónevek, inkább legyenek kicsit fölöslegesen hosszúak, mintsem nem teljessen egyértelműek a rövidség miatt. Ideiglenes változóknak, ciklusszervezésre stb. mehetnek az i, j, k...

- Igyekszem funkció szerint robbantani több .c fájlra a forrást, 20kB körül van az a mérethatár, ami fölött már nem érzem jól magam.

- -O2 -Wall kapcsolókkal warning nélkül forduljon.

- fv argumentumokra és változókra const, fv-ekre static kulcsszó használata ahol csak lehet.

[quote:9707967289="egmont"]fv-ekre static kulcsszó használata ahol csak lehet.

A static változó megvan, de a static függvény mire is jó?

[quote:9c363a19ad="sz"][quote:9c363a19ad="egmont"]fv-ekre static kulcsszó használata ahol csak lehet.

A static változó megvan, de a static függvény mire is jó?

Ha pl ilyen van hogy static void akarmi() ...

akkor az csak abban a file-ban lesz elerheto, mas fajlokban mar nem. Ez akkor erdekes, ha pl van elso.c masodik.c az elso.c ben van egy static void akarmi() na azt nem fogod tudni felhasznalni a masodik.c -bol. Mig ha nem static, akkor felfogod tudni. :)

Legalabbis en igy emlexem :)

De ittvan egy url, ami mindent megmagyaraz :) :

http://www.phim.unibe.ch/comp_doc/c_manual/C/SYNTAX/static.htm

Udv
-krix-

ezt én is tudtam, de gyakorlati értelmét nem látom, mivel a bináris mérete nem változik, egyébként meg szerintem sz*rt sem ér...

btw kezdünk elkanyarodni a kérdéstől :twisted:

style(9)

hamár itt tartunk, vannak paranoiák
pl amikor beljebb kezdesz vmit, vki 4 (esetleg 2) spacet nyom, valaki meg tabot
ebből helyenként legalább akkora háborúk szoktak lenni, mint a vi/emacs :wink:

[quote:11834ee06b="anr"]elrettenteskent nehany regexp:
[code:1:11834ee06b]
((?<!(?:br\>|e.'))<font[^>]*>)([\w\W]*?)(</font>)
(local $relRootPath ="$dir") =~ s|([^/]+/)|../|g;
(local $parent=$link) =~ s|^(.*/)[^/]+/?$|\1|;
[/code:1:11834ee06b]
Szerintem ezek szépek. Bár annak, aki nem ismeri inkább krixkrax-ok;))

bocs, az utolsó kettőnek csak a második fele regexp :wink:
az első meg nekem is kicsit krixkrax, ez mi a halál? 8O

[quote:8468edcfe6="lacipac"]ezt én is tudtam, de gyakorlati értelmét nem látom, mivel a bináris mérete nem változik, egyébként meg szerintem sz*rt sem ér...

btw kezdünk elkanyarodni a kérdéstől :twisted:

Hat passz. Max annyit erhet hogy egy fuggvenyt nem tud meghivni a program masik resze. Ez talan biztonsagi szempontbol lehet erdekes.

De ez csak maganvelemeny :)

Udv
-krix-

[quote:fa994476e1="lacipac"]ezt én is tudtam, de gyakorlati értelmét nem látom, mivel a bináris mérete nem változik, egyébként meg szerintem sz*rt sem ér...

Nem a méretről van szó, hanem egyrészt arról, hogy a neve nem látszik kifelé, nem kell namespace conflict-tól félni, másrészt ez az adatvédelem meg elrejtés meg mittommén ami az összes magasabb szintű nyelv lényege: a kódod ne egy átláthatatlan hatalmas massza legyen, hanem sok apró komponensből tervezetten, céltudatosan, szépen összerakott építmény. A static fv-t bármikor átírhatja, kidobhatja, interface-t megváltoztathatja stb. azon 1 db fájl karbantartója, nem kell az egész esetleg többfős fejlesztői gárdának ugrálnia miatta... Szóval igenis ami fv-re nem akarod, hogy az adott .c (majd .o) fájlból látszódjon kifelé, mert nincs rá szükség, az legyen static, vagyis szándékosan tedd kifele láthatatlanná.

html forrásból szűr ki egy speckó esetet, de még nem esett le, h mi ennek a gyakorlati haszna :wink:

Ez attol fugg milyen nyelv, a perlnek is megvan a szepsege akar a C-nek, vagy a Javanak, aprobl;ma ott kezdodik, ha valaki ugy programozik javaban, mintha perl programot irna. Mindegyik programozasi nyelv egy kulon szemleletmod, egy kulon stilus.Van szep kod javaban, perlben,C-ben, de ezeknek szinte alig van kozuk egymashoz.

[quote:6db7442a70="sz"]A static változó megvan, de a static függvény mire is jó?

(OO megkozelitesben) a statikus metodusok nem tartoznak egy bizonyos egyedhez, es tipus.metodus alakban hivatkozunk rajuk (ellentetben az instance metodusokkal, ahol egyed.metodus-t irunk) - a tipikusan "utility" osztalyok altalaban csak statikus metodusokat tartalmaznak, es nem-publikus konstruktoruk van (dummy) - erre jo megoldas a C# 2-ben bevezetett statikus osztaly (egybol sealed lesz, nincs konstruktor, a fordito hibat jelez, ha instance metodust akarsz irni)

Ha pici agyammal jól emlékszem, php-hoz a PEAR manban adnak egy jó ajánlást. Nekem az viszonylag tetszett, plána ha sokan használják, mert az ugye csak jó, ha minnél több programozó használja ugyanazt a stylust. Persze programnyelvre vonatkoztatva...

Honsin

:set cino=>2g2h9 :lol:

Egyebkent amire nagyon szoktam figyelni:
1.) sorhossz < 80 karakter
2.) fuggvenyhossz < 25 sor
3.) Nincsenek beegetett valtozok
4.) Nem sporolok a kodhosszal az atlathatosag kedveert.

Ajanlott irodalom:
The Practice of Programming by Brian W. Kernighan and Rob Pike.

[quote:8ef17f1176="egmont"]- -O2 -Wall kapcsolókkal warning nélkül forduljon.

erről az mplayer-dev-engen volt egy hosszú szál (nem találom a linket)
ott azt hozták ki, h csak ésszel, időnként olyanokra warningol, amit ha megcsinálsz, akkor romlik a progi teljesítménye

[quote:f4c312b189="anr"]A programozási paradigmák egytől egyig tartalmazzák, hogy illik szép kódot írni, anélkül hogy a pontos definicióját megadnák.

Nem veletlen, hogy nem adnak pontos definiciot: nincs ilyen. A szepseg erosen szubjektiv, emberenkent es programnyelvenkent valtozik, nomeg tobb fajtaja is van a szepsegnek. Szerintem peldaul ez is gyonyoru szep kod: http://perlmonks.thepen.com/45213.html

Teny, hogy nem lennek az az ember akinek az a feladata hogy irjam at, hogy pillangot rajzoljon ki - de attol meg igen magas muveszi ertekkel rendelkezik szamomra, ergo szerintem szep. Aki epp heveny perl gyuloletben szeret, annak pedig ez egy ekes bizonyitek arra, hogy szerinte miert nem szabad azt a nyelvet hasznalni (pedig pont az a szep benne, hogy ilyen eszement muveszetet is lehet vele csinalni >;).

Altalaban veve en ugy tartom, hogy a szep kod az rendezett, attekintheto, es konnyen felfoghato. Pl ha csinalok egy call-graph-ot rola, akkor nem fekete foltot kapok, hanem valami attekintheto dolgot. Tovabba a szep kod konzisztens - ha az egyik fele GNU-style indentet hasznal, a kovetkezo funkcio meg K&R-stylet, az meglehetosen borzalmas. Extra bonusz ha meg komment is van a bonyolultabb blokkok elott, segitendo a megertest. Ha meg meg az is meg van csinalva, hogy amint az ember atlatja az algoritmust, a szivehez kap, hogy "Uramatyam, ez gyonyoru szep!", szoval meg van _tervezve_ a kod, nem csak osszecsapva es utana toldozva-foldozva, az az igazi szepseg. Fuggetlenul attol hogy epp teveformaban van megcsinalva, vagy $YOUR_FAVOURITE_STYLE indentelve van.

[quote:b8dd575a71="anr"][quote:b8dd575a71="algernon"]
Szerintem peldaul ez is gyonyoru szep kod: http://perlmonks.thepen.com/45213.html

Ez szerintem mas kategoria.

Bingo! Ott a kulcsszo: a szepsegnek is vannak kategoriai (is) :)

Hello,

kicsit talan off, de mondjatok meg nekem, van valamilyen magyar nyelvu (vagy angol vagy nemet) levlista, portal, ami altalanosan programozasrol szol, ahol mondjuk olyanokat targyalnak meg, mint ez a tema? Meg egy hint: mint a coder-l volt.

koszhelo,
viktor

ehh, volt erre egy kezdeményezés, h létrejöjjön a www.unidev.hu, táltos el is kezdte csinálni, de a drupal telepítésnél elakadt :wink:
azóta nemtom, h volt-e vmilyen lépés az ügyben
:arrow: Indulóban egy új, programozással kapcsolatos oldal...

Szerintem szép kód kb annyit jelent, hogy:

1) Nem túl hosszú sorok
2) Átlátható szerkezet
3) C, PHP, stb esetében kapcsos zárójeleket mindig új sorba és előre elgondolt szerkezet szerint rakosgatni.
4) Ha valamit meg lehet oldani 2 sorban, akkor az nem csinálom meg 15-ben.
5) A szükséges helyeken rövid és egyértelmű comment, ami nem zavarja a kódot.
6) Amire nem kell, arra nem írok külön függvényt (pl. van egy két soros összehasonlítás, amit az egész programban kétszer használok, arra fölösleges függvényt gyártani.)
7) Csak olyan programban használok OOP-t ahol erre szükség van.
8) Minél kevesebb IF -- THEN
9) Programkódban akkor sem használok ékezetet, ha azt a nyelv megengedi. (Ez csak izlés kérdése asszem.)
10) Nem használok globális változót, ha ezt technikailag el tudom valahogyan kerülni.
11) Minden komolyabb függvényhez (amiről nem látszik első ránézésre, hogy mit csinál) négy-öt soros commentet írok.

Nagy vonalakban ennyi. :)

[quote:87dfb2b1f4="Pingvin"]Szerintem szép kód kb annyit jelent, hogy:

1) Nem túl hosszú sorok
2) Átlátható szerkezet
3) C, PHP, stb esetében kapcsos zárójeleket mindig új sorba és előre elgondolt szerkezet szerint rakosgatni.
4) Ha valamit meg lehet oldani 2 sorban, akkor az nem csinálom meg 15-ben.
5) A szükséges helyeken rövid és egyértelmű comment, ami nem zavarja a kódot.
6) Amire nem kell, arra nem írok külön függvényt (pl. van egy két soros összehasonlítás, amit az egész programban kétszer használok, arra fölösleges függvényt gyártani.)
7) Csak olyan programban használok OOP-t ahol erre szükség van.
8) Minél kevesebb IF -- THEN
9) Programkódban akkor sem használok ékezetet, ha azt a nyelv megengedi. (Ez csak izlés kérdése asszem.)
10) Nem használok globális változót, ha ezt technikailag el tudom valahogyan kerülni.
11) Minden komolyabb függvényhez (amiről nem látszik első ránézésre, hogy mit csinál) négy-öt soros commentet írok.

Nagy vonalakban ennyi. :)

Na es mi a helyzet a GOTO-val?

(vigyazz flame csali :-), az orok flame indito kerdes :-)