[robocheck-dev] Idei si intrebari

[Constantin Mihalache]

On Jul 5, 2015 1:20 AM, "Andrei Tuicu" <andrei.tuicu at gmail.com> wrote:
>
> Imi cer scuze, am marcat cumva mailul ca citit fara sa raspund si am
uitat ulterior. :)
>
> În data de 29 iunie 2015, 18:52, Laura Vasilescu <laura at rosedu.org> a
scris:
>>
>> 2015-06-25 16:07 GMT+03:00 Constantin Mihalache <mihalache.c94 at gmail.com
>:
>> >     Am vazut ca pe wiki, la sectiunea Detected Errors, sunt cateva
>> > puncte care sunt legate de coding style (number of lines in a function
>> > exceeded maximum admitted, number of character in a line exceeded
>> > maximum admitted, etc.) asa ca am implementat un modul pentru C
>> > (codingstyle.py) care, deocamdata, verifica numarul de caractere de pe
>> > o linie si numarul de linii din fiecare functie si returneaza o lista
>> > de erori.
>> >
>> > Other things done:
>> >     *am schimbat run-tests.sh conform issue-ului "Use pushd and
popd..."
>> >     *am adaugat un test pentru a verifica modulul codingstyle.py
>> > (works as expected)
>> >
>> > Toate modificarile sunt in fork-ul asta [1].
>>
>>
>> Sună foarte bine! Mă bucur că deja ai început chiar să și faci
patch-uri! :)
>> Singura observație e că codul respectiv poate duplică munca depusă și
>> am prefera să ne bazăm cât mai mult pe tool-uri deja existente, if
>> any.
>>
>> Spre exemplu, pentru a verifica coding style-ul în C ar exista mai
>> multe variante, fiecare coding style având particularitățile lui. De
>> regulă, la programare și SO se merge destul de mult pe linux kernel
>> coding style care poate fi verificat rulând scriptul checkpatch.pl din
>> tree-ul de kernel.
>
>
> Este aici o mica lista de tool-uri ce planuiam sa le integram in
robocheck:
> https://github.com/rosedu/robocheck/wiki/tools
>
>>
>>
>>
>> @RD: ai idee pe unde era tree-ul vechi cu sursele scrise în C? Aparent
>> nu e niciun link către el pe wiki și ar fi fost util.
>
>
> Found it: git://ixlabs.cs.pub.ro/robocheck.git
>
>> O referință cu niște tool-uri care erau integrate în versiunea
>> respectivă ar fi lucrarea mea de licență (cap. 02):
>> http://swarm.cs.pub.ro/~laura/p/bachelor-thesis/thesis.pdf
>>
>> > Nelamuriri:
>> >     1. Nu stiu daca am gresit sau nu ca am scris eu parsarea surselor
>> > si ca nu am integrat un tool care sa verifice chestii. (mi s-a parut
>> > mai usor de controlat)
>>
>> See above. :D
>> E întradevăr mai ușor de controlat, dar se poate ajunge la cod
>> duplicat. De regulă tool-urile externe se modifică mai greu și
>> mentenanța rămâne la ei.
>>
>>
>> >     2. Daca abordarea mea e in regula, in fisierul codingstyle.py sunt
>> > hardcodate la inceput numarul maxim de caractere pe linie si numarul
>> > maxim de linii dintr-o functie si presupun ca ar trebui mutate intr-un
>> > fisier de configurare or something. (any advice?)
>>
>> Ca idee generală, ar fi util să fie configurabile. Chiar dacă modulul
>> este pentru C, aș vedea mai degrabă un astfel de modul care să fie
>> configurabil per limbaj de programare (deci să nu stea în C, unless
>> funcționalitatea nu e strict dependentă de C). Dacă funcționalitatea
>> (în cazul ăsta lungimea linilor și a funcțiilor) nu depinde de limbaj,
>> ar trebui ca și în repo să fie reflectat ca atare și să fie ușor de
>> configurat. (deci dacă ar fi așa, nu ar mai fi checkpatch.pl din
>> kernel)
>
>
> Eu as vota totusi varianta cu checkpatch, deoarece verifica mai mult
decat lungimea liniilor si a functiilor. :)
> Daca ramane aceasta varianta, eu as sugera sa te uiti pe implementarile
modulelor de DrMemory si Valgrind, sa vezi
> cum sunt apelate si cum este strans output-ul lor si apoi sa implementezi
un modul similar pentru checkpatch. Tin minte
> ca voiam sa definesc o interfata comuna tuturor modulelor pentru a fi
foarte clar ce trebuie implementat, dar nu mai stiu
> daca am facut-o.
>>
>>
>> >     3. Ar fi ok introducerea de unit-test-uri ?
>>
>>
>> Ar fi chiar super! :)
>
>
> +1 pentru unit teste. :)
>>
>>
>> > Awaiting feedback,
>>
>> Scuze de delay, am fost plecată. O să fiu mai responsive. :)
>>
>> Laura
>>
>
> Am facut merge la pull request-ul tau. Pe viitor, as recomanda sa creezi
branch-uri pentru a putea face pull request-uri separate (ex. branch pt
unit-teste, branch pt implementarea unui modul), astfel incat sa le putem
face merge separat. :)
>
> Cheers,
> Andrei
>
>
> _______________________________________________
> robocheck-dev mailing list
> robocheck-dev at lists.rosedu.org
> http://lists.rosedu.org/listinfo/robocheck-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rosedu.org/pipermail/robocheck-dev/attachments/20150706/07a12f21/attachment.html>