[so] [Tema 1][General] Sfaturi Coding Style

[Mihai Barbulescu]

Salut Ioan,

O sa revizuiesc putin acea sectiune, multumesc ca mi-ai semnalat.

On Wed, 13 Mar 2019 at 18:55, Ioan-Florin-Cătălin NIŢU (87674)
<ioan_florin.nitu at stud.acs.upb.ro> wrote:
>
> Salut,
>
> La 3. aia cu sizeof(*s) am citit aici https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/c_tips#operatorul_sizeof
>
> In rest m-am lamurit cu restul. Sper ca am raspuns bine la e-mail (nu m-am obisnuti cu lista de discutii)
>
> Mersi mult,
> Catalin
> ________________________________
> De la: Mihai Barbulescu <b12mihai at gmail.com>
> Trimis: miercuri, 13 martie 2019 15:11
> Către: Ioan-Florin-Cătălin NIŢU (87674); Sisteme de Operare
> Subiect: Re: [so] [Tema 1][General] Sfaturi Coding Style
>
> On Wed, 13 Mar 2019 at 14:03, Ioan-Florin-Cătălin NIŢU (87674) via so
> <so at cursuri.cs.pub.ro> wrote:
> >
> > Salut,
> >
> > Am câteva nelămuriri și întrebări legate de coding style:
> >
> > 1. Am vazut că în headerul cu funcția compare se folosea #ifndef __COMPARE_H_, așa că pentru consecvență si eu mi-am făcut la fel define-urile pentru bibliotecile mele (#ifndef __UTILS_H_ de exemplu), dar am citit că acest lucru nu e recomandat. Să schimb peste tot (să dau drop la __) sau să las așa?
>
> E ok oricare din variante
>
> >
> > 2. Când știu ce funcții să fac statice? Și cum le organizez în headere? Dacă declar o funcție static trebuie să o scriu neaparat in header, dar eu nu vreau asta. In headere aș vrea să păstrez doar prototipul funcțiilor. Cum e recomandat sa lucrez?
>
> Sugerez sa citesti ce inseamna "static function" - functie interna
> unui modul. Vezi si ce ti-a spus Paul Olaru c-a zis bine.
>
> > 3. În implementare am folosit ceva gen struct smt *s = malloc(sizeof(struct smt)); pot lasă așa sau o să fiu penalizat la notare? (nu aș schimba în tot codul să pun struct smt *s = malloc(sizeof(*s)); dar dacă e nevoie o fac).
>
> Este OK cum ai pus, nu stiu de unde ai scos-o ca e obligatoriu sa faci
> sizeof(*s)
>
> >
> > 4. In Kernel coding style am citit că e recomandat să se scrie despre fiecare variabila folosită câteva cuvinte, sper ca e okay daca am facut asta. Printre altele am pus și #endif /* __UTILS_H */ pentru include-uri, tot din recomandari.
> >
>
> E OK.
>
> > 5. Este okay dacă am folosit typedef pentru structuri? Știu că în documentația de la Kernel spune că nu e recomandat, dar având în vedere scopul temei mi s-a părut mai usor de înțeles/utilizat/lucra așa. Pe viitor am să fiu mai atent la abordare.
> >
>
> Eu unul sunt pro typedef-uri daca fac codul mai usor de citit - mai
> ales la tema asta la care "inventam" un "obiect" (PriorityQueue). Da,
> e de preferat sa evitati typedef-ul pt struct-uri dar nu vom scadea
> mai ales daca codul e "citibil"
>
> > 6. Este okay dacă scriu README-ul în română? (comentariile din cod le-am pus in engleză, dar aș prefera să scriu README-ul în română).
>
> Il scrii in ce limba vrei, dar sa te asiguri c-o stiu si asistentii.
>
> > 7. Deși nu are neapărat legătură cu coding style, dacă nu am lucrat pe git cu tema, pot să fac un repo simplu în care să pun doar sursele mele și atât? Sau să copiez repo-ul vostru și pentru fiecare temă să îmi mai fac eu un folder separat de fișierele voastre în care să îmi pun sursele și celelalte fișiere utile?
>
> Sugerez sa revezi sectiunea de indicatii de folosire a gitlab:
> https://ocw.cs.pub.ro/courses/so/teme/folosire-gitlab
> Raspunde la tot ce ai intrebat aici.
>
> >
> > Intreb aceste lucruri pentru ca nu am erori de checkstyle care să mă ajute să imi rezolv singur problemele și aș vrea să scap de ambiguități.
>
> Sper c-ai scapat de ambiguitati.
>
> > Mulțumesc frumos și imi cer scuze de deranj. Știu că poate par puerile intrebările mele dar aș vrea să știu cum să procedez.
> >
>
> Nu e nici o problema, va rog sa intrebati de fiecare data cand aveti
> neclaritati.
>
>
>
> --
> Cu stimă,
> Mihai Bărbulescu



-- 
Cu stimă,
Mihai Bărbulescu