No pull request

[valentinogrean]

So this is the review:

• why refactor.py; the name of the file should have more meaning in the context of a project
• initial comments; do they bring value?
• '''First Project already refactored''' ??? what is the reason for this comment
• figures=["circle","triangle","cube"]; why not an OOP implementation?
• the biggest issue I have with the linking between the items from figures and formulas; this might work in a science project in Python, but this is a very bad practice for a project in production (maintenability, reliability, etc). Please use OOP constructs so that you can make sure that the formula is for the correct shape;
• what happens if I have 3 circles, one triangle and no cubes?
• def clock(func): why do you need function?

Weak implementation; very insecure code; no OOP; needs strong refactoring.

[VulpeanuAdrian]

Buna seara, va multumesc pentru ca ati gasit timp in weekend pentru review. Legat de punctele dumeanvoastra:

• Total de acord legat de nume, comenturile initiale nu au nici o valorea.
• Legat de implementarea de OOP , mi s-a parut prea simplu sa primeasca la constructor figura si sa afiseze formula ...de aceea am dorit sa folosesc un tip special de date... named tuples, mi s-a parut mai pythonic insa pot sa o refac dupa mentiuniile dumeavoastra, imi va fi mult mai simplu decat implementarea initiala....
• def clock (func) ar trebui sa fie folosit in mod normal ca si decorator de timp @clock de functie imi va returna timpul de executie... este un decorator generic de timp facut de mine, l-am scris pentru a continua implementarea pentru subiectul 2( aveam de gand sa fac un joc de bingo/loto si sa am ca output dupa cate incercari s-au extras 6 numere random intre primele 6 si cat timp a durat...).

Imi puteti spune va rog ziua.ora pentru prezentare a subiectului 1/2

[valentinogrean]

Hello,

Te rog sa citesti cu atentie requirement urile problemei :). Nu intotdeauna ce este mai simplu este si mai bun. In al doilea rand aici ne intereseaza mai mult partea de "clean code" (adica sa fie o implementare robusta) si mai putin partea de functionalitate. Eu recomand sa faci 2 proiecte diferite, din acelasi considerent. In ultimul rand, am discutat despre concepte si implementari OOP - recomand sa urmaresti aceste principii, chiar daca lucrezi in Python. Pythonic nu inseamna neaparat OOP.

Legat de alte intrebari, prezentari etc, vei afla informatii in classroom, documentul cu reqs sau la laborator.

Numai bine, Valentin

On Sun, Jun 6, 2021 at 9:13 PM VulpeanuAdrian @.***> wrote:

Buna seara, va multumesc pentru ca ati gasit timp in weekend pentru review. Legat de punctele dumeanvoastra:

• Total de acord legat de nume, comenturile initiale nu au nici o valorea.
• Legat de implementarea de OOP , mi s-a parut prea simplu sa primeasca la constructor figura si sa afiseze formula ...de aceea am dorit sa folosesc un tip special de date... named tuples, mi s-a parut mai pythonic insa pot sa o refac dupa mentiuniile dumeavoastra, imi va fi mult mai simplu decat implementarea initiala....
• def clock (func) ar trebui sa fie folosit in mod normal ca si decorator de timp @Clock https://github.com/Clock de functie imi va returna timpul de executie... este un decorator generic de timp facut de mine, l-am scris pentru a continua implementarea pentru subiectul 2( aveam de gand sa fac un joc de bingo/loto si sa am ca output dupa cate incercari s-au extras 6 numere random intre primele 6 si cat timp a durat...).

Imi puteti spune va rog ziua.ora pentru prezentare a subiectului 1/2

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/VulpeanuAdrian/DesignPatern/issues/1#issuecomment-855439260, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABF35MOBKD5NX3EZHV4H3F3TRO3ERANCNFSM46GCP3AQ .