Re: [so] [Tema1] Coding Style - Conditii lungi
Mulțumesc frumos pentru răspunsuri.
Seară ușoară
Teodor Popescu
+40 770 498 496
On Fri, 28 Feb 2020 at 11:41, Mihai Barbulescu wrote:
>
> Salut Teodor,
>
> Iti recomand sa folosesti setarile astyle pentru kernelul de Linux
> (astyle --style=linux). E mai simplu decat sa iti bati tu capul. Mai
> exista si indent da nu mi-am batut capul cu asta. Si o poti face mai
> agresiva sub urmatoarea forma:
>
> astyle --style=linux --indent=force-tab=8 --align-pointer=name -p -H -U
>
> Daca folosesti Visual Studio code poti configura de exemplu ca la
> autosave sa se ruleze astyle, uite mai jos un exemplu de intrare in
> settings.json (invalida pt Linux, o folosesc in alt context)
> {
> ...
> "astyle.cmd_options": [
> "--style=kr",
> "--indent=spaces=4",
> "--indent-col1-comments",
> "--convert-tabs",
> "--pad-oper",
> "--pad-header",
> "--unpad-paren",
> "--lineend=linux",
> "--max-code-length=120",
> "--add-brackets",
> "--align-reference=type",
> "--align-pointer=type"
> ],
>
> ...
> }
>
> Daca folosesti gitlab poti configura hook de post/receive sa ruleze
> checkpatch.pl si astyle pt codul tau cand pushezi.
>
> Punctual la intrebarea ta: din punct de vedere al codului nu mi-as
> bate capul atat timp cat indeplineste 2 conditii:
> 1. checkpatch.pl il valideaza fara erori
> 2. tie personal ti se pare usor de citit
>
> Orice review de genul: mie imi place mai mult asa decat cum propui tu,
> domnu' developer, mi se pare ca genereaza discutii infinite inutile si
> de-aia sunt fanul automatizarii lui prin astyle/indent/checkpatch.
>
> On Fri, 28 Feb 2020 at 09:21, Paul Olaru via so wrote:
> >
> > Eu unul sunt familiarizat cu a doua opțiune fiind cel mai des folosită în
> > porțiunea de kernel Linux în care lucrez eu deci aș recomanda să o
> > folosești pe aceasta. Prima variantă poate fi bună în situații rare în care
> > condiția e într-adevăr complexă și ar avea nevoie de un nume sau comentariu.
> >
> > A treia variantă nu văd să aibă un avantaj.
> >
> > Deci eu unul recomand să mergi pe a doua variantă, cu excepția cazului în
> > care a crea funcția cu un nume relevant poate ajuta înțelegerea codului.
> > Dacă funcția s-ar numi "cond7", don't bother. Dacă funcția s-ar numi
> > "is_valid_open_request", o poți crea.
> >
> >
> > On Fri, Feb 28, 2020, 9:17 AM Teodor Popescu via so
> > wrote:
> >>
> >> Bună ziua,
> >>
> >> Putem întâlni situații în care avem suficient de multe condiții
> >> într-un if încăt linia să depășească un prag de bun simț (să spunem,
> >> 100 de caractere).
> >> Presupunem următoarea secvență de cod:
> >> if (CONDIȚIE_1 || CONDIȚIE_2 || CONDIȚIE_3 || CONDIȚIE_4 ||
> >> CONDIȚIE_5) {
> >> instr;
> >> }
> >>
> >> Nu am găsit în standardul pentru Linux Kernel o soluție pentru aceste
> >> situații, dar am identificat 3 metode prin care am putea aborda aceste
> >> cazuri:
> >>
> >> 1) Refactorizarea codului prin adăugarea unei funcții (care nu va
> >> apărea și în fișierul .h) astfel:
> >> int my_function()
> >> {
> >> return CONDIȚIE_1 ||
> >> CONDIȚIE_2 ||
> >> CONDIȚIE_3 ||
> >> CONDIȚIE_4 ||
> >> CONDIȚIE_5;
> >> }
> >> if (my_function()) {
> >> instr;
> >> }
> >>
> >> Dezavantaj: Nu este imediat evidentă condiția, fiind nevoie să
> >> cauți funcția pentru a înțelege codul.
> >>
> >> 2) "Spargerea" condiției pe mai multe linii, astfel:
> >> if (CONDIȚIE_1 ||
> >> CONDIȚIE_2 ||
> >> CONDIȚIE_3 ||
> >> CONDIȚIE_4 ||
> >> CONDIȚIE_5) {
> >> instr;
> >> }
> >>
> >> Dezavantaj: Indentarea instrucțiunilor este identică celei a
> >> condițiilor, și nu este imediat clar unde se termină condițiile și
> >> unde încep instrucțiunile.
> >>
> >> 3) "Spargerea" condiției pe mai multe linii, astfel:
> >> if (CONDIȚIE_1 ||
> >> CONDIȚIE_2 ||
> >> CONDIȚIE_3 ||
> >> CONDIȚIE_4 ||
> >> CONDIȚIE_5)
> >> {
> >> instr;
> >> }
> >>
> >> Dezavantaj: Nu se respectă recomandarea generală de a avea acolada
> >> deschisă pe aceeași linie cu închiderea condiției unui 'if'.
> >>
> >> Aveți vreo recomandare legată de acest aspect?
> >>
> >> Mulțumesc frumos.
> >>
> >> O seară plăcută
> >> Teodor Popescu
> >> +40 770 498 496 | teodor.popescu2005 | 335CB
> >> ___
> >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> >
> > ___
> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
>
>
> --
> Cu stimă,
> Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [Tema1] Coding Style - Conditii lungi
Salut Teodor,
Iti recomand sa folosesti setarile astyle pentru kernelul de Linux
(astyle --style=linux). E mai simplu decat sa iti bati tu capul. Mai
exista si indent da nu mi-am batut capul cu asta. Si o poti face mai
agresiva sub urmatoarea forma:
astyle --style=linux --indent=force-tab=8 --align-pointer=name -p -H -U
Daca folosesti Visual Studio code poti configura de exemplu ca la
autosave sa se ruleze astyle, uite mai jos un exemplu de intrare in
settings.json (invalida pt Linux, o folosesc in alt context)
{
...
"astyle.cmd_options": [
"--style=kr",
"--indent=spaces=4",
"--indent-col1-comments",
"--convert-tabs",
"--pad-oper",
"--pad-header",
"--unpad-paren",
"--lineend=linux",
"--max-code-length=120",
"--add-brackets",
"--align-reference=type",
"--align-pointer=type"
],
...
}
Daca folosesti gitlab poti configura hook de post/receive sa ruleze
checkpatch.pl si astyle pt codul tau cand pushezi.
Punctual la intrebarea ta: din punct de vedere al codului nu mi-as
bate capul atat timp cat indeplineste 2 conditii:
1. checkpatch.pl il valideaza fara erori
2. tie personal ti se pare usor de citit
Orice review de genul: mie imi place mai mult asa decat cum propui tu,
domnu' developer, mi se pare ca genereaza discutii infinite inutile si
de-aia sunt fanul automatizarii lui prin astyle/indent/checkpatch.
On Fri, 28 Feb 2020 at 09:21, Paul Olaru via so wrote:
>
> Eu unul sunt familiarizat cu a doua opțiune fiind cel mai des folosită în
> porțiunea de kernel Linux în care lucrez eu deci aș recomanda să o folosești
> pe aceasta. Prima variantă poate fi bună în situații rare în care condiția e
> într-adevăr complexă și ar avea nevoie de un nume sau comentariu.
>
> A treia variantă nu văd să aibă un avantaj.
>
> Deci eu unul recomand să mergi pe a doua variantă, cu excepția cazului în
> care a crea funcția cu un nume relevant poate ajuta înțelegerea codului. Dacă
> funcția s-ar numi "cond7", don't bother. Dacă funcția s-ar numi
> "is_valid_open_request", o poți crea.
>
>
> On Fri, Feb 28, 2020, 9:17 AM Teodor Popescu via so
> wrote:
>>
>> Bună ziua,
>>
>> Putem întâlni situații în care avem suficient de multe condiții
>> într-un if încăt linia să depășească un prag de bun simț (să spunem,
>> 100 de caractere).
>> Presupunem următoarea secvență de cod:
>> if (CONDIȚIE_1 || CONDIȚIE_2 || CONDIȚIE_3 || CONDIȚIE_4 || CONDIȚIE_5) {
>> instr;
>> }
>>
>> Nu am găsit în standardul pentru Linux Kernel o soluție pentru aceste
>> situații, dar am identificat 3 metode prin care am putea aborda aceste
>> cazuri:
>>
>> 1) Refactorizarea codului prin adăugarea unei funcții (care nu va
>> apărea și în fișierul .h) astfel:
>> int my_function()
>> {
>> return CONDIȚIE_1 ||
>> CONDIȚIE_2 ||
>> CONDIȚIE_3 ||
>> CONDIȚIE_4 ||
>> CONDIȚIE_5;
>> }
>> if (my_function()) {
>> instr;
>> }
>>
>> Dezavantaj: Nu este imediat evidentă condiția, fiind nevoie să
>> cauți funcția pentru a înțelege codul.
>>
>> 2) "Spargerea" condiției pe mai multe linii, astfel:
>> if (CONDIȚIE_1 ||
>> CONDIȚIE_2 ||
>> CONDIȚIE_3 ||
>> CONDIȚIE_4 ||
>> CONDIȚIE_5) {
>> instr;
>> }
>>
>> Dezavantaj: Indentarea instrucțiunilor este identică celei a
>> condițiilor, și nu este imediat clar unde se termină condițiile și
>> unde încep instrucțiunile.
>>
>> 3) "Spargerea" condiției pe mai multe linii, astfel:
>> if (CONDIȚIE_1 ||
>> CONDIȚIE_2 ||
>> CONDIȚIE_3 ||
>> CONDIȚIE_4 ||
>> CONDIȚIE_5)
>> {
>> instr;
>> }
>>
>> Dezavantaj: Nu se respectă recomandarea generală de a avea acolada
>> deschisă pe aceeași linie cu închiderea condiției unui 'if'.
>>
>> Aveți vreo recomandare legată de acest aspect?
>>
>> Mulțumesc frumos.
>>
>> O seară plăcută
>> Teodor Popescu
>> +40 770 498 496 | teodor.popescu2005 | 335CB
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
--
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [Tema1] Coding Style - Conditii lungi
Eu unul sunt familiarizat cu a doua opțiune fiind cel mai des folosită în
porțiunea de kernel Linux în care lucrez eu deci aș recomanda să o
folosești pe aceasta. Prima variantă poate fi bună în situații rare în care
condiția e într-adevăr complexă și ar avea nevoie de un nume sau comentariu.
A treia variantă nu văd să aibă un avantaj.
Deci eu unul recomand să mergi pe a doua variantă, cu excepția cazului în
care a crea funcția cu un nume relevant poate ajuta înțelegerea codului.
Dacă funcția s-ar numi "cond7", don't bother. Dacă funcția s-ar numi
"is_valid_open_request", o poți crea.
On Fri, Feb 28, 2020, 9:17 AM Teodor Popescu via so
wrote:
> Bună ziua,
>
> Putem întâlni situații în care avem suficient de multe condiții
> într-un if încăt linia să depășească un prag de bun simț (să spunem,
> 100 de caractere).
> Presupunem următoarea secvență de cod:
> if (CONDIȚIE_1 || CONDIȚIE_2 || CONDIȚIE_3 || CONDIȚIE_4 ||
> CONDIȚIE_5) {
> instr;
> }
>
> Nu am găsit în standardul pentru Linux Kernel o soluție pentru aceste
> situații, dar am identificat 3 metode prin care am putea aborda aceste
> cazuri:
>
> 1) Refactorizarea codului prin adăugarea unei funcții (care nu va
> apărea și în fișierul .h) astfel:
> int my_function()
> {
> return CONDIȚIE_1 ||
> CONDIȚIE_2 ||
> CONDIȚIE_3 ||
> CONDIȚIE_4 ||
> CONDIȚIE_5;
> }
> if (my_function()) {
> instr;
> }
>
> Dezavantaj: Nu este imediat evidentă condiția, fiind nevoie să
> cauți funcția pentru a înțelege codul.
>
> 2) "Spargerea" condiției pe mai multe linii, astfel:
> if (CONDIȚIE_1 ||
> CONDIȚIE_2 ||
> CONDIȚIE_3 ||
> CONDIȚIE_4 ||
> CONDIȚIE_5) {
> instr;
> }
>
> Dezavantaj: Indentarea instrucțiunilor este identică celei a
> condițiilor, și nu este imediat clar unde se termină condițiile și
> unde încep instrucțiunile.
>
> 3) "Spargerea" condiției pe mai multe linii, astfel:
> if (CONDIȚIE_1 ||
> CONDIȚIE_2 ||
> CONDIȚIE_3 ||
> CONDIȚIE_4 ||
> CONDIȚIE_5)
> {
> instr;
> }
>
> Dezavantaj: Nu se respectă recomandarea generală de a avea acolada
> deschisă pe aceeași linie cu închiderea condiției unui 'if'.
>
> Aveți vreo recomandare legată de acest aspect?
>
> Mulțumesc frumos.
>
> O seară plăcută
> Teodor Popescu
> +40 770 498 496 | teodor.popescu2005 | 335CB
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii
