Scopul acestei pagini este de a vă familiariza cu practicile recomandate limbajelor POO. Un cod scris corect poate fi mult mai ușor scalat, depanat și înțeles atunci când se folosesc niște reguli consacrate, astfel dorim ca și voi să puteți începe să urmăriți aceste reguli chiar de la soluționarea temelor voastre.

1. Î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ă. 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. Totodată, 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.
2. 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.
3. 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.
4. Î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.
5. Folosiți feature-uri noi Java dacă vă ajută, dar aveți grijă ca acestea să fie prezente și în versiunea de JDK de pe VmChecker.
6. Folosiți Git pentru a vă versiona proiectul. Trebuie să aveți minim 3 commit-uri sugestive.
7. Soluția voastră trebuie să folosească cât mai mult concepte POO învățate la laborator.

1. Evitați folosirea keyword-ului instance of, acesta nu respectă principiile POO, singura excepție fiind în folosirea lui pentru generarea metodei “equals”.
2. Codul înghesuit și nespațiat este greu de înțeles, apelați la IntelliJ pentru a vă formata automat proiectul.
3. Nu folosiți nume nesugestive pentru variabile, clase și metode. Clasele descriu containere sau entități, variabilele reprezintă în general substantive, iar metodele încep adesea cu un verb.
4. Nu folosiți snake_case pentru denumirea claselor, variabilelor și a metodelor. Pachetele pot fi denumite urmând sintaxa camelCase, dar și sintaxa snake_case.
5. Nu creați toate clasele într-un singur pachet. Folosiți cât mai multe pachete pentru a grupa logic codul, puteți crea chiar pachete în pachete.
6. Nu denumiți constantele necorespunzător. Folosiți litere mari și delimitatorul “_”.
7. Nu lăsați cod comentat în proiect.
8. Nu includeți fișiere care nu sunt relevante în arhiva proiectului.
9. Nu hardcodați testele.
10. Evitați programarea în stil C (imperative programming).
11. Evitați să includeți cod inutil sau cod care îngreunează execuția programului.

Pentru clarificări vă recomandăm să folosiți forum-ul aferent temei, urmând ca întrebarea voastră să primească un răspuns cât de curând. Evitați întrebările foarte specifice care oferă hint-uri la soluționarea temei. De asemenea, verificați forumul periodic pentru update-uri și pentru întrebări ca să nu se creeze intrebări duplicate.