Indicații pentru teme

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 OO. 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:
  • nu reproduceți cerințele din enunț și/sau comentariile din cod
  • explicați ideile, deciziile și abordările voastre
  • exprimați-vă concentrat = clar și concis
  • formatați-l corespunzător - linii de 80 de caractere max, paragrafe, etc
• 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"

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 intr-un singur fisier
• -0.3 - toate sursele puse intr-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
• (variabil, începând de la -0.2) Javadoc necorespunzător, incomplet, irelevant; inclus și documentarea lipsă sau incorectă a parametrilor metodelor
• -0.1 - lipsă Javadoc generat sau script de generare. Această depunctare nu se va aplica dacă pentru o anume temă nu este necesară exportarea de documente Javadoc.
• (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 î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
• -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.

Ce considerăm util să conțină un fișier README pentru o temă la POO:

• componentele soluției: rolurile lor și relațiile dintre ele
  • nu este necesar să luați pe rând fiecare clasă și să îi descrieți câmpurile și metodele, pentru asta există javadoc.
• flow-ul dintre componente - e.g. cum se realizează o anumite acțiune, ce clase sunt implicate.
• probleme întâmpinate (dacă ați avut)