Differences
This shows you the differences between two versions of the page.
|
poo-ca-cd:administrativ:barem_teme [2024/11/10 16:56] florian_luis.micu [Depunctări generale pentru teme] |
poo-ca-cd:administrativ:barem_teme [2024/11/10 17:58] (current) florian_luis.micu [Don'ts] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Indicații pentru teme ===== | ===== Indicații pentru teme ===== | ||
| + | |||
| + | * Autori: [[miculuis1@gmail.com | Florian-Luis Micu]], [[sorinabuf@gmail.com | Sorina-Anamaria Buf]], [[stefancocioran@gmail.com | Ștefan Cocioran]] | ||
| + | * Ultima modificare: 10 noiembrie 2024 | ||
| Temele urmăresc exersarea cunoștințelor și abilităților voastre. | Temele urmăresc exersarea cunoștințelor și abilităților voastre. | ||
| Line 7: | Line 10: | ||
| 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. | 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. | ||
| - | ==== Recomandări ==== | + | ==== Do's ==== |
| * Alocați suficient timp temelor. E improbabil ca o rezolvare într-un all-night coding sprint să fie de calitate. | * Alocați suficient timp temelor. E improbabil ca o rezolvare într-un all-night coding sprint să fie de calitate. | ||
| Line 13: | Line 16: | ||
| * Fiți consecvenți unui [[:poo-ca-cd:administrativ:coding_style_ide|coding style]]. | * Fiți consecvenți unui [[:poo-ca-cd:administrativ:coding_style_ide|coding style]]. | ||
| * Când scrieți README-ul pentru teme: | * 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ă. | + | * Î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șit să rezolvați o cerință din temă. |
| * Nu reproduceți cerințele din enunț și/sau comentariile din cod. | * Nu reproduceți cerințele din enunț și/sau comentariile din cod. | ||
| * Exprimați-vă concentrat = clar și concis. | * Exprimați-vă concentrat = clar și concis. | ||
| Line 48: | Line 51: | ||
| </note> | </note> | ||
| - | ==== Depunctări generale pentru teme ==== | + | ==== Don'ts ==== |
| - | Temele pe care le primim **trebuie să compileze și să ruleze** pentru a avea posibilitatea de punctaj non-zero. | + | * Evitați folosirea keyword-ului instance of, acesta nu respectă principiile POO, singura excepție fiind în folosirea lui pentru generarea metodei “equals”. |
| + | * Codul înghesuit și nespațiat este greu de înțeles, apelați la IntelliJ pentru a vă formata automat proiectul. | ||
| + | * 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. | ||
| + | * 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. | ||
| + | * 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. | ||
| + | * Nu denumiți constantele necorespunzător. Folosiți litere mari și delimitatorul “_”. | ||
| + | * Nu lăsați cod comentat în proiect. | ||
| + | * Nu includeți fișiere care nu sunt relevante în arhiva proiectului. | ||
| + | * Nu hardcodați testele. | ||
| + | * Evitați programarea în stil C (imperative programming). | ||
| + | * Evitați să includeți cod inutil sau cod care îngreunează execuția programului. | ||
| - | Vom aplica mici depunctări legate de calitatea codului și a abordărilor temelor. Din 10 puncte: | + | <note tip> |
| + | Despre forum: | ||
| + | * 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 (să țineți cont că în weekend se poate răspunde cu o întârziere mai mare). | ||
| + | * 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. | ||
| + | </note> | ||
| - | **Coding style si organizare:** | + | <note warning> |
| - | * -0.1 - cod înghesuit sau prea spațiat | + | Despre programarea în stil C: |
| - | * -0.2 - warning-uri de compilare | + | * Folosiți cât mai multe concepte POO (moștenire, polimorfism, upcast, overloading, overriding etc.) |
| - | * verificați import-urile, variabilele nefolosite, etc | + | * Gândiți temele ca entități care interacționează cu alte entități pentru a programa în stilul POO. |
| - | * între -0.1 și -0.4 - nepăstrarea consistenței pentru comentarii - fie sunt toate comentariile în engleză fie sunt toate în română. | + | * Unele funcționalități pot fi doar niște metode, dar pot apărea următoarele probleme: |
| - | * î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. | + | * Să spunem că aveți de implementat o funcționalitate care printează //eating//, //speaking//, //playing// într-un mod special pentru fiecare tip de animal care vă este oferit la input. |
| - | * între -0.1 și -0.3 - denumiri nepotrivite pentru metode, variabile, clase | + | * Acestea pot fi reprezentate direct ca metode specifice pe care le puteți apela în cadrul unui switch-case. |
| - | * -0.1 - bucăți de cod comentat | + | * Ce faceți dacă trebuie să mai introduceți câteva animale? Ar trebui să creați noi metode în clasa voastră unde procesați logica ceea ce ar face fișierul greu de citit. |
| - | * -0.5 - toate clasele într-un singur fișier | + | * Ce faceți dacă trebuie să adăugați funcționalități noi pentru fiecare tip de animal? Din nou, adăugăm foarte multe metode, ceea ce ar reduce lizibilitatea codului. |
| - | * -0.3 - toate sursele puse într-un pachet | + | * De asemenea, puteți să aveți foarte mult cod duplicat care ar fi putut fi encapsulat într-o clasă Animal care ar fi putut fi moștenită de clasele voastre specializate (ex. Wolf, Dog, Cat etc.). |
| - | * -0.1 - includerea altor fișiere care nu au legătură cu cerința | + | * Totodată dacă nu aplicați corect conceptele POO este posibil să ajungeți la situații în care apelați instance of ca să verificați ce clase trebuie să apelați ceea ce vă reduce codul la o formă de cod scrisă în C (soluția ar fi să folosiți upcasting și o metodă generică suprascrisă conform laboratului în care vi se prezintă upcast/downcast, moștenire, overloading, overriding). |
| - | * -0.1 - includere folder bin in arhivă | + | * Dacă analizați situațiile de mai sus vă puteți da seama că limbajele de tip POO vă reduc drastic din cod și vă oferă extensibilitate pe viitor, adică orice programator vă poate extinde codul mult mai ușor dacă va fi nevoie de feature-uri noi în proiect. |
| + | </note> | ||
| + | ==== Depunctări generale pentru teme ==== | ||
| - | **Documentare:** | + | Temele pe care le primim **trebuie să compileze și să ruleze** pentru a avea posibilitatea de punctaj non-zero. |
| - | * î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:** | + | Vom aplica depunctări legate de calitatea codului și a abordărilor temelor. Din 10 puncte: |
| - | * -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. | + | {{:poo-ca-cd:administrativ:barem_1.png?600|}} |
| - | + | {{:poo-ca-cd:administrativ:barem_2.png?600|}} | |
| - | Pentru abateri minore (de exemplu un nume de metodă folosit neadecvat, in toată tema), se vor pune doar observații cu -0.0. | + | {{:poo-ca-cd:administrativ:barem_3.png?600|}} |
| + | {{:poo-ca-cd:administrativ:barem_4.png?600|}} | ||
| + | {{:poo-ca-cd:administrativ:barem_5.png?600|}} | ||
| + | {{:poo-ca-cd:administrativ:barem_6.png?600|}} | ||
| + | {{:poo-ca-cd:administrativ:barem_7.png?600|}} | ||
| + | <note important> | ||
| + | * 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. | ||
| + | * Dacă aveți întrebări legate de barem puteți să ne contactați pe forum/mail sau Teams. | ||
| + | </note> | ||
