Temele urmăresc exersarea cunoștințelor și abilităților voastre.

Așadar, urmărim nu doar cod care “merge”. Rezolvările voastre trebuie să nu fie predispuse la erori și să poată fi citite/parcurse/înțelese cu ușurință.

De asemenea, urmărim aplicarea principiilor orientate pe obiect. Acesta este unul dintre scopurile materiei și depășește limbajul de programare cu care lucrăm. Șansele sunt ca majoritatea codului pe care îl veți scrie ca software engineers să fie orientat-obiect. Vom urmări cu strictețe respectarea acestor principii în temele voastre.

• Alocați suficient timp temelor. E improbabil ca o rezolvare într-un all-night coding sprint să fie de calitate.
• Nu scrieți codul din prima, ci alocați timp abordării și design-ului.
• Fiți consecvenți unui coding style.
• Când scrieți README-ul pentru teme:
  • Încercați să creați README-uri care să reflecte structura internă a proiectelor voastre (ierarhii de clase, ierarhii de pachete), dar și interacțiunea dintre entități mai ales când descrieți cum ați reuși să rezolvați o cerință din temă.
  • Nu reproduceți cerințele din enunț și/sau comentariile din cod.
  • Exprimați-vă concentrat = clar și concis.
  • Este de apreciat să ne descrieți chiar și problemele pe care le-ați avut și cum ați ajuns la soluțiile actuale.
  • Dacă folosiți structuri de date/algoritmi avansați, design pattern-uri sau chiar mecanisme mai avansate Java, este bine să menționați aceste lucruri în README, deoarece în unele etape acestea pot fi considerate puncte bonus.
  • Apreciem foarte mult feedback-ul vostru, deci puteți lăsa la final un feedback constructiv care va fi folosit pentru ajustarea temelor viitoare.
  • Lungimea README-ului nu trebuie să fie copleșitoare, vă recomandăm să vă incadrați în maxim 100 de rânduri, câte 80 de caractere pe linie.
• Comentariile din cod:
  • Puneți comentarii în cod semnificative deasupra semnăturii metodelor folosind JavaDoc.
  • Comentariile trebuie sa fie concise și să descrie funcționalitatea de bază a metodei.
  • Puteți scrie comentarii și în corpul metodelor dacă aveți un flux mai complicat de instrucțiuni, dar codul vostru Java ar trebui să fie destul de ușor de înțeles dacă vă folosiți de funcționalități POO.
• Despre organizarea codului:
  • Organizați codul cât mai bine în pachete și clase.
  • Clasele ar trebui să fie scurte și să conțină metode foarte bine modularizate.
  • Un proiect bun sau chiar enterprise conține sute de clase, tocmai pentru a decupla cât mai bine funcționalitățile aplicației.
• Despre feature-uri:
  • Încercați să folosiți cunoștințe avansate din lab pentru a rezolva cerința temei, deoarece acestea vă pot învăța sa creați un cod mai sigur prin mecanisme de error handling sau sincronizare sau chiar un binar mai mic și mai ușor de înțeles prin folosirea unei sintaxe mai scurte.
  • Folosiți feature-uri noi Java dacă vă ajută.
• Folosiți Git pentru a vă versiona proiectul. Trebuie să aveți minim 3 commit-uri sugestive.
• Soluția voastră trebuie să folosească cât mai mult concepte POO învățate la laborator.
• Folosiți cu încredere forumurile pentru orice: neclarități, coding style, best practices, etc.
• Folosiți principiile Object Oriented:
  • Păstrați încapsularea
  • Folosiți polimorfismul
  • Abstractizați și programați "by contract"
  • Respectați principiile SOLID, DRY și KISS.

Temele pe care le primim trebuie să compileze și să ruleze pentru a avea posibilitatea de punctaj non-zero.

Vom aplica mici depunctări legate de calitatea codului și a abordărilor temelor. Din 10 puncte:

Coding style si organizare:

• -0.1 - cod înghesuit sau prea spațiat
• -0.2 - warning-uri de compilare
  • verificați import-urile, variabilele nefolosite, etc
• între -0.1 și -0.4 - nepăstrarea consistenței pentru comentarii - fie sunt toate comentariile în engleză fie sunt toate în română.
• între -0.1 și -0.4 - nepăstrarea consistenței pentru denumiri - fie sunt toate în engleză fie în română. Puteți avea însă denumirile și comentariile în limbi diferite.
• între -0.1 și -0.3 - denumiri nepotrivite pentru metode, variabile, clase
• -0.1 - bucăți de cod comentat
• -0.5 - toate clasele într-un singur fișier
• -0.3 - toate sursele puse într-un pachet
• -0.1 - includerea altor fișiere care nu au legătură cu cerința
• -0.1 - includere folder bin in arhivă

Documentare:

• între -0.1 și -0.5 - comentarii absente sau irelevante
• -0.1 - comentarii de tip TODO în cod
• între -0. și -0.5 - Javadoc necorespunzător, incomplet, irelevant; inclus și documentarea lipsă sau incorectă a parametrilor metodelor
• (variabil, în funcție de alocarea punctajului fiecărei teme) Readme necorespunzător, lipsă, conținut irelevant, etc

Design, implementare:

• -0.5 - cod duplicat
• între -0.1 și -0.3 hardcodări
  • folosiți constante și enum-uri în locul valorilor numerice/String-urilor literali
• -0.1 - metode șau variabile nefolosite
• între -0.1 și -0.5 - metode lungi (> 100 de linii) care ar fi putut fi sparte, bucăți mari de logică în main etc
• între -0.1 și -0.5 - clase și metode cu multiple roluri/responsabilități/side-effects. La prima tema se vor da mai mult drept warning. (-0.0).
• -0.1 - print-uri prin cod
• între -0.2 și -0.5 - ruperea încapsulării
• între -0.2 și -0.5 - modificatori de acces folositi necorespunzator (e.g. metode lăsate publice care de fapt ar trebui să fie private)
• -0.1 - instanceof-uri și teste de tip in situații în care putea fi folosit polimorfismul
• -0.5 - folosirea tipurilor “raw” în loc de tipurile parametrice (generic) e.g. new ArrayList() în loc de new ArrayList<String>()
• (variabil, -0.2 până la -2 sau peste) design rigid, greoi, inextensibil, bug-prone

Lista nu este exhaustivă. Evaluatorii pot aplica depunctări mai mari decât cele prezentate aici, în funcție de numărul de apariții ale greșelilor sau de gravitatea lor.

Pentru abateri minore (de exemplu un nume de metodă folosit neadecvat, in toată tema), se vor pune doar observații cu -0.0.