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.

• Stabiliți-vă un stil de coding și fiți consecvent cu acesta.
• 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.
• 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: warning-uri de compilare; trebuie folosit, în cadrul compilării, flag-ul -Wall pe Linux
• -0.2: mai mult de 20 de linii mai lungi de 80 de caractere;
• -0.1: mult cod duplicat;
• -0.1: cod înghesuit: nu se folosesc spații, nu se folosesc linii libere pentru a separa “paragrafele” de cod;
• -0.1: folosire de valori hard-coded, în loc să se definească macrodefiniții;
• -0.1: tab-uri amestecate cu spații pentru indentare; folosiți fie numai spații, fie numai tab-uri
• -0.1: indentare inconsecventă (uneori există, alteori nu, un TAB, mai mult TAB-uri)
• -0.1: mixed line endings (adică atât CRLF – Windows, cât și LF – Unix);
• -0.1: trailing whitespace; nu lăsați spații sau tab-uri la finalul liniilor;
• -0.1: surse nesemnate;
• -0.1: funcții kilometrice (> 150 de linii);
• -0.2: funcții “și mai kilometrice” (> 300 de linii);
• -0.1: definiții de funcții non-statice în headere;
• -0.1: funcții nepublice (interne modulului) nedefinite folosind identificatorul static; variabile globale nepublice (interne modulului) nedefinite folosind identificatorul static;
• -0.1: linii de cod comentate în surse; pentru debug recomandăm folosirea unui macro – puteți urmări exemplul de aici;
• -0.1: comentarii inadecvate: comentarii nerelevante sau absente;
• -0.1: denumire neadecvată a funcțiilor sau variabilor (do_stuff, my_var) ;
• -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: includerea de fișiere binare sau irelevante în arhivă;
• -0.2: nu se eliberează memoria alocată; leak-uri de memorie;
• -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: 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.2: README necorespunzător: nu se descrie soluția, se indică doar comentarii din sursă, copy paste la enunț sau la comentarii;
• -0.1: fișier Makefile necorespunzător: o singură regulă, nu există target de clean, nu se folosesc dependențe;
• -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;