[so] [Tema1] Coding Style - Conditii lungi

Mihai Barbulescu b12mihai at gmail.com
Fri Feb 28 11:41:02 EET 2020


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 <so at cursuri.cs.pub.ro> 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 <so at cursuri.cs.pub.ro> 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


More information about the so mailing list