Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

C development na Linuxu - stil pisanja koda i preporuke - IX

1.Uvod

Možda se pitate šta se podrazumeva pod ovim naslovom. Kod je kod, zar ne? Važno je da bude bez greški i to je to, šta drugo? Development je više od pisanja koda i njegovog testiranja/uklanjanja grešaka. Zamislite da morate da pročitate tuđe radove, a pretpostavljam da ste to već radili, a sve se varijable zovu foo, bar, baz, var, itd. A kod se ne komentariše niti dokumentuje. Verovatno ćete osetiti nagli poriv da prizovete nepoznate bogove, a zatim da odete u lokalnu kafanu i utopite svoju tugu. Kažu da ne treba raditi drugima ono što ne želite da rade vama, tako da će se ovaj deo usredsrediti na opšte smernice za kodiranje, plus GNU-specifične ideje koje će vam pomoći da vam kod bude prihvaćen. Trebalo je da pročitate i razumete prethodne delove ovog serijala, kao i da rešite sve vežbe i, po mogućnosti, pročitate i napišete što više kodova.

2. Preporuke

Pre početka, molim vas da obratite pažnju na stvarno značenje gore pomenute reči. Ne želim, na bilo koji način, da vam govorim kako da pišete svoj ​​kod, niti izmišljam ove preporuke. Ovo su rezultati dugogodišnjeg rada iskusnih programera, a mnogi neće samo primenjivati C, već i druge jezike, interpretirane ili prevedene.

Valjda je prvo pravilo koje želim da naglasim: komentarišite svoj ​​kôd, a zatim proverite da li ste dovoljno komentarisali, onda još malo komentarišite. Ovo nije korisno samo za druge koji će čitati / koristiti vaš ​​kod, već i za vas. Budite uvereni da se nećete sećati šta ste tačno mislili da napišete posle dva ili tri meseca, niti ćete znati šta je int ghrqa34; trebalo da znači, ako je išta trebalo da znači. Dobri programeri komentarišu (skoro) svaki red svog koda što je moguće temeljnije, a to se isplati više nego što biste mogli zamisliti na početku, uprkos povećanom vremenu koje je potrebno za pisanje programa. Još jedna prednost je da komentarisanjem, jer je to način na koji naš mozak radi, sve što smo poželeli da uradimo biće bolje zapamćeno, pa stoga nećete gledati svoj kod, za nekoliko meseci, pitajući se ko ga je napisao. Ili zašto.

C analizatora zapravo ne zanima koliko je vaš kod uređen. To znači da možete napisati tipičan "hello, world" program kao što je ovaj, i ipak će se prevesti:

#include <stdio.h> int main(){printf("Hello, world!"); return 0;}

izgleda mnogo čitljivije onako kako smo napisali prvi put, zar ne? Opšta pravila vezano za formatiranje su: jedna instrukcija po redu, izaberite širinu tabulatora i budite joj dosledni, ali budite sigurni da je u skladu sa smernicama projekta, ako radite na nekom, takođe slobodno koristite prazne redove, za razgraničavanje raznih delova programa, zajedno sa komentarima, i na kraju, iako to nije nužno vezano za stil pisanja koda, pre nego što ozbiljno počnete sa pisanjem koda, pronađite neki program za obradu teksta koji vam se sviđa i naučite kako da ga koristite dobro. Uskoro ćemo objaviti članak o programima za obradu teksta, ali do tada će vam pomoći Google sa nekim alternativama. Ako čujete ljude na forumima, mailing listama, itd. koji govore "program za obradu teksta x je sranje, program za obradu teksta y je super!", ignorišite ih. Ovo je vrlo subjektivna stvar, i ono što je dobro za mene ne mora biti toliko dobro za vas, tako da bar isprobajte neke programe za obradu testa koji su dostupni za Linux, tokom nekoliko dana svaki, pre nego što uopšte počnete da stvarate svoje mišljenje.

Budite dosledni kod davanja imena promenljivim. Takođe se pobrinite da se imena slažu s drugima, tako da postoji sklad u celom programu. Ovo vredi čak i ako ste vi jedini autor softvera, biće ga lakše održavati kasnije. Napravite spisak korišćenih prefiksa i sufiksa (npr. max, min, get, set, is, cnt) i koristite ih, osim ako se drugačije ne traži. Doslednost je ovde ključna reč.

2.1. GNU-specifične smernice

Ono što sledi je rezime GNUCoding standarda, jer znamo da ne volite da čitate takve stvari. Dakle, ako pišete kod koji biste želeli da se uklopi u GNU ekosistem, ovo je dokument koji treba da pročitate. Čak i ako ne pišete, i dalje je korisno pročitati o tome kako da napišete ispravan kod.

Ovaj dokument uvek vredi pročitati u celosti ako pravite ili održavate GNU softver, ali u nastavku ćete naći najvažnije delove. Prvo pitanje vredno spomena je kako se nositi sa prototipom funkcije. Molimo da se vratite onom delu koji se bavi time ako imate bilo kakvih problema. Ideja je "ako imate svoje funkcije, koristite deklaraciju prototipa pre glavnog (), a zatim definišite funkciju kada je to potrebno." Evo primera:

#include <stdio.h> int func (int, int) int main() [...] int func (int x, int z) [...]

Koristite pravilan i stalan uvučen red. Ovo se ne može dovoljno naglasiti. Iskusni programeri sa godinama i godinama pisanja koda iza njih će veoma loše reagovati kada podnesete kod sa nepravilno uvučenim redom. U našem slučaju, najbolji način da se navikne na to kako GNU ovo radi je upotrebom GNU Emacs (iako ovo nikako nije naš način da vam kažemo da je "GNU Emacs dobar za vas, koristite ga.", pošto smo zagovornici slobodne volje i izbora), gde je zadato ponašanje za C kod da je uvučeni red postavljen na dva razmaka i vitičaste zagrade u redu za sebe. Što nas dovodi do drugog važnog pitanja. Neki ljudi koriste vitičaste zagrade ovako:

while (var == 1) { code... }

dok drugi, uključujući i GNU ljude, rade to ovako:

while (var == 1) { code... }

Naravno, to se odnosi i na uslovne izraze, funkcije i svaku priliku u kojoj morate da koristite vitičaste zagrade u C kodu. Koliko je primećeno, ovaj izbor je nešto što je veoma specifično za GNU, i koliko od ovoga poštujete zavisi isključivo od vašeg ukusa i stava po tom pitanju.

Naš sledeći problem je tehničke prirode, i obećanje koje sam morao da ispunim: malloc () problem. Osim pisanja relevantnih i smislenih poruka o greškama, drugačijih od onih koje smo svi videli u drugim operativnim sistemima, proverite da se malloc () i prijatelji uvek vraćaju na nulu. Ovo su veoma ozbiljni problemi, a dobićete kratku lekciju o malloc () i kada da ga koristite. Do sada znate šta je dodeljivanje memorije automatski ili statički. Ali ove metode ne pokrivaju sve baze. Kada je potrebno da dodelite memoriju i da imate veću kontrolu nad ovom operacijom, tu je malloc () i prijatelji, za dinamičko dodeljivanje. Njegova svrha je da dodeli raspoloživu memoriju iz dinamičke memorije (heap), a zatim taj program koristi memoriju preko pokazivača koji malloc () vraća, a zatim pomenuta memorija mora biti slobodna/oslobođena. A reč "mora" treba da bude napisana velikim slovima od 60cm jarko crvenom bojom. To je otprilike to vezano za malloc (), a razlozi su već ranije bili prikazani u prethodnom delu.

Pozvani ste da koristite dosledan interfejs u svim programima sa komandnim linijama. Ako ste već iskusan korisnik GNU/Linuxa primetili ste da skoro svi programi imaju -- verziju i -- pomoć, plus, na primer, -v za verbose, ako je takav slučaj. Nećemo ulaziti u sve to ovde; zgrabite kopiju GNU Coding Standarda, u svakom slučaju će vam trebati.

Iako sam lično sklon da ovo previdim, i za mnoge je to manji problem, poboljšaće čitljivost vašeg koda, jer, opet, to je kako naš mozak radi. Ideja je: kada ste u nedoumici vezano za korišćenje razmaka, koristiti ih. Na primer:

int func (var1, var2); int func(var1,var2);

Ovde ima nekih koji kažu da ne možete izbeći ugnežđene if izraze. Postoje drugi koji kažu "zašto bi se izbegavali ugnežđeni if izrazi?" A tu su opet i drugi koji jednostavno ne koriste ugnežđene if izraze. Stvorićete ​​vlastito mišljenje o tome kako vreme prolazi i redovi koda koji pišete rastu. Ideja je, ako ih koristite, učinite ih što je moguće više čitljivim, pošto lako mogu dovesti do koda koji je zamršen skoro kao špagete, teškog za čitanje i za održavanje. I opet, koristite komentare.

GNU coding standardi kažu da je dobro da vaš kod bude što je moguće prenosiviji, ali ne i ”najvažniji". Prenosiv kad je reč o hardveru? To zavisi o svrsi programa i kakve mašine imate na raspolaganju. Mi mislimo više na softversku stranu, naime prenosivost između Unix sistema, otvoreni kod ili ne. Izbegavajte ifdefs ako možete, izbegavajte pretpostavke o lokacijama datoteka (npr. Solaris instalira softver drugih proizvođača pod /opt, dok BSD i GNU/Linux ne), i uopšteno govoreći cilj za čist kod. Kada govorimo o pretpostavkama, ni ne pretpostavljajte da je bajt osam bitova ili da adresni prostor procesora mora biti paran broj.

Dokumentovanje koda, u obliku stranica priručnika i dobro napisani README i tako dalje, je još jedan vrhunski aspekt razvoja softvera. Da, JESTE mučan zadatak, ali ako nemate pisca dokumentacije u svom ​​timu, vaša je obaveza da to uradite, pošto svaki dobar programer radi svoj posao od A do Ž.

3. Zaključak

Sledeći put ćemo nastaviti gde smo stali ovde: polazeći od ideje do kompletnog programa, sa make datotekama, dokumentacijom, ciklusima izdavanja i svim zabavnim stvarima. Jedinu vežbu koju imam za vas je da letimice pročitate GNU Coding Standarde i izmenite svoj ​​kod tako da se prilagodi. I spremite se, sledeći put će biti ludo!

Evo šta možete sledeće očekivati:





Published (Last edited): 23-06-2013 , source: http://how-to.linuxcareer.com/c-development-on-linux-coding-style-and-recommendations-ix