Pe Moodle, pe langa punctajul pe testele unitare de pe checkerul local, daca aveti punctaj maxim, o sa primiti si un scor pe coding style, la etapa 1 arata ceva de genul:

Total Score: xx/100
Coding Style
	global score: x.xx
	accept function score: x.xx
	subset construction function score: x.xx

Scopul acestui scor este de a incuraja studenti sa reitereze pe codul scris, pentru a obtine un cod mai bun.

Datorita faptului ca este ceva experimental, daca alegeti sa ignorati complet scoreurile primite NU o sa aduca niciun fel de depunctare, dar daca participati aveti posibilitatea de a primi mici bonusuri.

Dupa trecerea unui deadline la o etapa, o sa apara aceste scoruri (in urmatoare cateva zile), aveti voie sa retrimiti oricate submisii doriti fara nicio depunctare (comform regulamentului) pentru a imbunatati calitatea codului, cu conditia ca pana in deadline sa fii obtinut minim 0.7p. Daca nu ati obtinut cele 0.7p, tot aveti voie sa retrimiteti, dar o sa pastrati acea depunctare de 0.3p.

Ce incercam noi sa surprindem prin aceste metrici este complexitatea codului scris. Ele sunt impartite in mai multe scoruri pentru a va ajuta sa detectati mai usor unde sunt probleme.

In general, cu cat scorul este mai mic, cu atat codul vostru este mai complex (valorile pot ajunge si negative).

Orice scor peste 5 este desirabil, inseamna ca calitatea codul este “peste medie”.

Ce incercam sa surprindem este daca codul vostru este complex intr-un mod nenecesar, diverse coduri pot fi mai complexe/mai putin complexe datorita problemelor si cerintelor care le rezolva, asta nu face codul pentru o problema mai bun sau prost ca cel pentru alta, de asta metricile noastre sunt specifice problemei si cerintelor din proiect.

• Un aspect important care afecteaza scorul primit este codul redundant, secvente de cod care nu au niciun scop clar duc la o complexitate nenecesara.

Exemple:

if cond:
	return True
return False
 
# ar fi echivalent cu un return, if-ul e redundant
 
if {special_case}:
	{do_somthing}
 
{general_case}
 
# atunci cand {special_case} are defapt acelasi behaviour si pe {general_case}

• Nemodularizarea, scrierea aceleiasi secvente de mai multe ori in detrimentul abstractizarii ei intr-o functie poate duce la complexitate nenecesara.

• Scorul poate sa fie prost si pentru ca exista o alta metoda mai usoara de a rezolva problema, e posibil sa trebuiasca sa schimbati complet abordarea.

NOTE: asta nu e o lista exhaustiva

• Linii goale, spatierea nu are NICIUN efect asupra complexitati, chiar poate ajuta sa faca un cod mai usor de citit.
• Comentariile nu afecteaza in niciun fel scorul primit.
• Numele variabilelor, x nu e un nume mai bun ca variabila_foarte_lunga_si_explicita, ele sunt echivalente in contextul metricilor folosite. De obicei chiar sunt preferate variabilele cu nume mai lungi si explicite.

• La etapa 1, scorul global nu include functiile de remap_states, atat din DFA cat si din NFA, orice faci in aceasta functie nu contribuie la scor, pentru ca cerinta era optionala.
• Un scor global foarte mic, dar scoruri extrem bune pe functii de obicei inseamna ca ati folosit functii auxiliare pentru majoritatea implementari. Asta nu e ceva rau, dar daca scorul global este mic, e posibil ca aceste functii auxiliare sa fie prea complexe. Pentru a localiza putin punctajul sa va dati seama unde sunt probleme puteti sa faceti functiile auxiliare functii locale pentru accept si subset_construction, astfel o sa fie luate in calcul la complexitatea celor doua functii si puteti sa va dati seama care set de functii auxiliare era prea complex, sau daca erau amandoua.