[so] [Tema1][Multi] Coding Style, Erori si Propagarea erorilor

[Mihai Barbulescu]

Variabilele de obicei se notează cu litere mici și macro-urile cu litere
mari

Deci mai sănătos e varianta cu variabile cu litere mici

On Mon, Mar 11, 2019, 21:17 Alex Cosmin Mihai <alexcosmin.mihai at gmail.com>
wrote:

> Salutare!
>
> Am facut modificarile pentru a folosi variabile extern const int in loc de
> macro-uri si am observat ca daca numeam variabilele cu litere mari,
> checkerpatch.pl dadea in continuare aceeasi eroare pentru coding style,
> cum ca ar trebui returnat -ERRBLABLA. Dupa ce am modificat numele
> sa foloseasca litere mici, checkerul nu a mai zis nimic.
> Banuiesc ca daca as fi numit si macro-urile cu litere mici ar fi mers.
>
> Sa pastrez aceasta varianta cu varabile extern const cu nume cu
> litere mici si valori pozitive ?
>
> Numai bine,
> Alex Mihai
>
> On Sun, 10 Mar 2019 at 22:23, Alex Cosmin Mihai <
> alexcosmin.mihai at gmail.com> wrote:
>
>> Salut Mihai,
>>
>> Multumesc mult pentru feedback!
>> Voi remedia chestiunile indicate si o sa revin cu rezultatul folosirii
>> extern const int.
>>
>> Numai bine,
>> Alex Mihai
>>
>> On Sun, 10 Mar 2019 at 20:53, Mihai Barbulescu <b12mihai at gmail.com>
>> wrote:
>>
>>> Salut Alex,
>>>
>>> Am verificat ce e pe gitlab.cs.pub.ro, din punctul meu de vedere e OK
>>> ce vad. Data viitoare daca cereti verificare pe vmchecker la
>>> teste/submisii sa precizati va rog frumos username-ul de LDAP (e.g. in
>>> cazul tau era
>>> alexandru.mihai1708)
>>>
>>> Identific o alta problema la priorityQueue.h -> nu l-ai protejat la
>>> multiple inclusion in mai multe fisiere. Fie o faci cu #pragma once
>>> fie o faci cu ceva de genul:
>>>
>>> #ifndef MYSUPERUBERHEADER_FILENAME_H
>>> #define MYSUPERUBERHEADER_FILENAME_H
>>>
>>> /* semnaturi si macrouri */
>>>
>>> #endif
>>>
>>> unde MYSUPERUBERHEADER_FILENAME_H te asiguri ca il alegi ca macro
>>> suficient de bine cat sa nu fie definit pe undeva.
>>>
>>> Mai sunt curios o chestie si n-am eu timp s-o verific dar poate o faci
>>> tu: in loc de
>>>
>>> #define ERRORNOMEM -12
>>> #define ERRORMEMBOUNDS -13
>>>
>>> sa definesti in .h doua extern const int, dar la valori pozitive, si
>>> in .c-ul lui priorityqueue unde le folosesti le setezi si valorile. Si
>>> sa le folosesti p-alea ca return values - oare se mai plange
>>> checkpatch.pl?
>>>
>>> De asemenea vezi ca nu imi plac denumirile astea prea "generice" de
>>> functii: insert, pop ... Vezi indicatiile generale de teme [1]:  -0.1:
>>> denumire neadecvată a funcțiilor sau variabilelor (do_stuff, my_var) ;
>>>
>>> [1] https://ocw.cs.pub.ro/courses/so/teme/general
>>>
>>> On Sun, 10 Mar 2019 at 18:40, Alex Cosmin Mihai
>>> <alexcosmin.mihai at gmail.com> wrote:
>>> >
>>> > Grozav!
>>> >
>>> > Multumesc frumos!
>>> >
>>> > Numai bine,
>>> > Alex Mihai
>>> >
>>> > On Sun, 10 Mar 2019 at 14:59, Mihai Barbulescu <b12mihai at gmail.com>
>>> wrote:
>>> >>
>>> >> Salut Alex,
>>> >>
>>> >> Din ce descrii tu aici sunt doua probleme:
>>> >> 1. Daca folosesti valorile "stas" din errno.h: EINVAL, ENOMEM etc.
>>> >> atunci checkpatch.pl o sa se planga ca vrea sa fie valoarea intoarsa
>>> >> negativa (adica -ENOMEM in loc de ENOMEM)
>>> >> 2. Testul cu "faulty" malloc se asteapta sa introci codul de eroare 12
>>> >> __valoare pozitiva__ (deci din multimea N*) sub ce forma vrei tu: ori
>>> >> exit(12) ori return 12 - oricare din abordari e buna si acceptat si
>>> >> modul in care imi returnezi tu valoarea 12 pozitiva nu prea imi pasa,
>>> >> atat timp cat nu o folosesti ca valoarea hardcodata ci printr-un macro
>>> >> sau un const int.
>>> >>
>>> >> On Sun, 10 Mar 2019 at 13:40, Alex Cosmin Mihai via so
>>> >> <so at cursuri.cs.pub.ro> wrote:
>>> >> > Checker-ul de coding style imi spunea sa returnez coduri de eroare
>>> negative de tipul "-ERRORNOMEM", iar in enunt spune ca valoarea returnata
>>> in cazul unei erori de malloc(), de exemplu, trebuie sa fie 12. Din aceasta
>>> cauza am schimbat codul sa returnez -ERRORNOMEM, dar am schimbat si
>>> definitia ERRORNOMEM in -12. Este corecta aceasta abordare?
>>> >> >
>>> >>
>>> >> Pare a fi ok.
>>> >>
>>> >> > De asemenea, nu am folosit deloc functia DIE din laboratoare si
>>> nici nu am afisat nimic la STDOUT, nici STDERR in afara de output-ul
>>> comenzii top, iar erorile le-am propragat ca int-uri valori de return ale
>>> functiilor pana in functia main, unde in cazul in care o astfel de valoare
>>> este diferita de 0 o folosesc ca parametru pentru exit(). Este aceasta
>>> abordare corecta?
>>> >>
>>> >> Da e foarte buna abordarea asta.
>>> >>
>>> >> >
>>> >> > As fi recunoscator daca cineva din echipa ar putea arunca un ochi
>>> peste codul meu care este incarcat si pe vmchecker si pe GitLab si sa-mi
>>> dea un ok / not ok.
>>> >>
>>> >> N-am apucat sa ma uit pe surse (poate s-o fac diseara cand am niste
>>> ragaz)
>>> >>
>>> >> --
>>> >> Cu stimă,
>>> >> Mihai Bărbulescu
>>>
>>>
>>>
>>> --
>>> Cu stimă,
>>> Mihai Bărbulescu
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20190311/04b92800/attachment.html>