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 scoreuri (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 scoreuri pentru a va ajuta sa detectati mai usor unde sunt probleme.

In general, cu cat score-ul 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
 
return cond
 
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. Deobicei chiar sunt preferate variabilele cu nume mai lungi si explicite.

• La etapa 1, scorul global cu 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 deobicei 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.