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@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@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 _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii