Proszę o sprawdzenie mojego projektu z OOP Opcje

[adrianpl20]

Witam.

Ostatnio w ramach nauki Gita i programowania obiektowego w php, napisałem sobie taką podstawę frameworka/CMSa (jak zwał tak zwał). Chciałbym prosić o sprawdzenie mojego kodu i konstruktywną krytykę.
Czy taki kod nadaje się do pokazania pracodawcy?

Głównie prosiłbym o sprawdzenie i ewentualne poprawienie mnie z:
- wyrzucanie/wyłapywanie wyjątków - czy dobrze to robię, może w złym miejscu wyrzucam/wyłapuję ?
- główny plik index.php który wszystkim kieruje - czy czegoś tam nie powinno być może? Czy prawidłowo zrobiłem wyłapując tam wyjątki przy wywoływaniu akcji kontrolera?
- routing
- struktura plików
- instancje w klasach - czy gdzieś może powinna być instancja a jej nie ma, lub gdzieś nie powinno jej być zdecydowanie?

Wiem, że tu prawie nic nie ma i wielu rzeczy brakuje, ale to tylko w ramach nauki (IMG:style_emoticons/default/smile.gif)

https://github.com/adrianpl20/oop

[Tuminure]

A jeśli widzisz, że musisz dodać komentarz to zazwyczaj znaczy, że coś z kodem jest nie tak.

Nie. Komentarz traktuję jako streszczenie kodu, a nie jego wyjaśnienie. Szybciej mi przeczytać jedną linijkę komentarza, niż 10 linijek kodu. Warto też dodać, że początkujące osoby powinny pisać komentarze częściej, gdyż ich kod często prócz streszczenia, potrzebuje też wyjaśnienia.

Zaledwie nie sugerowałbym, by unikał komentarzy (gdyż to znaczy, że całkowicie z nich zrezygnuje). Z czasem zauważy, które jego komentarze są potrzebne, a które nie.

Całej reszty nie komentuję, gdyż z resztą się w pełni zgadzam.

[Xelah]

Nie. Komentarz traktuję jako streszczenie kodu, a nie jego wyjaśnienie. Szybciej mi przeczytać jedną linijkę komentarza, niż 10 linijek kodu.

Nie zgodzę się. Łatwiej przyczytać nazwę metody (i klasy), jej parametry wejściowe i wyjściowe niż jakikolwiek komentarz. Jeśli po tym dalej nie wiesz co się dzieje, to śmiem twierdzić, że problem leży w kodzie a nie w braku komentarza.

Warto też dodać, że początkujące osoby powinny pisać komentarze częściej, gdyż ich kod często prócz streszczenia, potrzebuje też wyjaśnienia.

Zaledwie nie sugerowałbym, by unikał komentarzy (gdyż to znaczy, że całkowicie z nich zrezygnuje). Z czasem zauważy, które jego komentarze są potrzebne, a które nie.

Tutaj też się nie zgodzę. Raz wyuczonych złych nawyków bardzo trudno się pozbyć. Dlatego dalej uważam, że od samego początku powinno się traktować komentarze wyłącznie jako ostateczność i to tylko w sytuacji, jeśli kodujemy na granicy. We własnym kodzie możesz napisał naście tysięcy linijek kodu i nie porzebować ani jednej linijki komentarza.

Poza tym komentarze mają jeszcze jeden, o wielei większy problem. Często opisuję jakiąś ogólną koncepcję czy logikę tego, co się dzieje w środku. Potem kod jest poddawany ciągłej re-faktoryzacji i zmianą. Mało kto pamięta o komentarzach. Nie mówiąc o sytuacjach, gdzie komentarz mówi coś w stylu "tu robię tak bo metoda X w klasie Y działa tak i tak". Potem ktoś zmienia klasę Y i nawet nie wie, że gdzieś tam w szerokim świecie jest już nieaktualny komentarz.

Absolutnie nie twierdzę, że komentarze są kompletnie zbędne. Ale powinno się ich używać tylko w na prawdę uzasadnionych sytuacjach.

A patrząc na kod autora wiele komentarzy mówi dokładnie to damo to linijka pod komentarzem. To jest tylko niepotrzebne śmiecenie kodu i na pewno nie przyniesie niczego dobrego.

PS. A do wyjaśnienia kodu służą testy jednostkowe. Wystarczy na nie popatrzeć i już wiesz co i jak działa i czego się spodziewać po kodzie.