Codul vostru trebuie nu numai să “meargă”, ci și să fie ușor de citit/parcurs și fără potențiale erori (neverificate de sistemul de evaluare automată). Aveți mai jos câteva indicații pentru teme, împreună cu depunctările aferente pentru nerespectarea lor.

• Pentru rezolvarea temelor este impus stilul de coding din kernelul de Linux. Puteți folosi acest wrapper peste checkpatch.pl pentru a vă verifica sursele înainte de a submite temele.
• Folosiți utilitare precum cppcheck, valgrind, Application Verifier pentru verificarea statică/dinamică a codului.
• Dacă nu sunteți siguri pe modul vostru de indentare, folosiți indent sau astyle.
  • Pentru cei care folosesc vim, puteți porni de la acest vimrc
• Creați un README relevant care să nu reproducă enunțul sau comentariile din cod și care să ajute la înțelegerea soluției alese.
• Folosiți lista de discuții dacă aveți întrebări referitoare la coding style sau best practices.
  • Pentru abordări de evitat (bad practices) vă recomandăm lectura articolelor despre Anti-patterns și Code smells.
• Testați-vă tema dincolo de testele automate. O aplicație reușită nu se rezumă doar la trecerea unui subset de teste.
  • Recomandăm să folosiți tehnici de unit testing.
  • Găsiți aici o serie de framework-uri de unit testing.

• Temele care nu se compilează sau nu rulează, indiferent de motive, vor primi punctaj 0; folosiți sistemul vmchecker pentru a verifica rularea/compilarea corespunzătoare a temelor

• -0.2: accesarea unor zone de memorie nevalide (care nu rezultă în mesaj de eroare de tipul “Segmentation fault”): buffer overflow, lucru neadecvat cu funcții pe șiruri; pentru depistarea accesărilor invalide puteți folosi valgrind;
• -0.2: nu se eliberează resursele după utilizarea acestora: nu se eliberează memoria alocată; leak-uri de memorie; recomandăm folosirea utilitarului valgrind pentru a depista leak-urile de memorie din program;
• -0.2: nu se eliberează resursele după utilizarea acestora: nu se închid descriptorii de fișiere (Linux), respectiv handler-ele (Windows)
• -0.2: nu sunt verificate valorile de retur ale funcțiilor; recomandăm folosirea macro-ului DIE, prezent în scheletul de laborator;
• -0.1: nu sunt întoarse coduri de eroare relevante;
• -0.1: folosire alocare dinamică pentru o dimensiune statică (cunoscută la compilare);
• -0.1: folosire buffere statice (dimensiune fixă) acolo unde este nevoie de alocare dinamică (acolo unde dimensiunea se cunoaște doar la runtime);
• -0.1: mult cod duplicat;

• -0.5: definiții de funcții non-statice în headere;
• -0.5: includere a unei surse (exemplu: #include “file.c”); se includ doar fișiere header (exemplu: #include “file.h”);
• -0.1: funcții nepublice (interne modulului) nedefinite folosind identificatorul static; variabile globale nepublice (interne modulului) nedefinite folosind identificatorul static;

• -0.1: folosirea directivelor de compilare condiționată (#ifdef linux …) acolo unde ar fi fost mai modular să se folosească fișiere separate și includere condiționată în fișiere header;

• -0.2: warning-uri de compilare; trebuie folosit, în cadrul compilării, flag-ul -Wall pe Linux și flag-ul /W3, cel puțin, pe Windows;
  • puteți folosi /D_CRT_SECURE_NO_DEPRECATE pentru a evita unele warninguri pe Windows.
• -0.1: fișier Makefile necorespunzător: o singură regulă, nu există target de clean, nu se folosesc dependențe;

• -0.1: folosire de valori hard-coded, în loc să se definească macrodefiniții;
• -0.1: funcții kilometrice (> 150 de linii); dezavantajele unei funcții prea lungi: este dificil de a o citi și înțelege, este predispusă la a conține mai multe defecte, indică un design precar al programului;
• -0.2: funcții “și mai kilometrice” (> 300 de linii);
• -0.1: denumire neadecvată a funcțiilor sau variabilelor (do_stuff, my_var) ;

• În scheletul de cod din laboratoare și din teme este folosit stilul de coding din kernelul Linux. Testul 0 din cadrul checker-ului fiecărei teme verifică automat coding style-ul surselor voastre folosind scriptul checkpatch.pl. Câteva exemple de utilizare a scriptului găsiți aici.
  • Vă puteți folosi de acest wrapper peste checkpatch.pl a verifica sursele folosind criteriile considerate în evaluarea temelor.
  • Pentru mai multe informații despre un cod de calitate citiți pagina de recomandări.
• Exemple de erori de evitat:
  • mai mult de 20 de linii mai lungi de 80 de caractere;
  • cod înghesuit: nu se folosesc spații, nu se folosesc linii libere pentru a separa “paragrafele” de cod;
  • tab-uri amestecate cu spații pentru indentare; folosiți fie numai spații, fie numai tab-uri
  • indentare inconsecventă (uneori există, alteori nu, un TAB, mai multe TAB-uri)
  • mixed line endings (adică atât CRLF – Windows, cât și LF – Unix);
  • trailing whitespace; nu lăsați spații sau tab-uri la finalul liniilor;

• -0.1: linii de cod comentate în surse; pentru debug recomandăm folosirea unui macro – puteți urmări exemplul de aici;
• -0.1: includerea de fișiere binare sau irelevante în arhivă;
• -0.2: cod inutil; prezența unor funcții sau bucăți de cod care nu sunt folosite sau sunt inutile în cadrul programului (de exemplu, se alocă un element și apoi nu se folosește sau se execută cod după apelul exec);

• -0.1: surse nesemnate;
• -0.1: comentarii inadecvate: comentarii nerelevante sau absente;
• -0.1: comentarii cu C99 (// in loc de /* */)
• -0.2: README necorespunzător: nu se descrie soluția, se indică doar comentarii din sursă, copy paste la enunț sau la comentarii.