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]

Bez komentarza dokładnie wiadomo co się dzieje. Nie musisz tego dodawać w komentarzu. Generalinie unikaj inline comments. Jeśli kod nie jest czytelny i musisz go komentować to znak, żeby zmienić kod (a nie dodawać komentarz).

Nope. Przydatne komentarze są przydatne. Ale komentuje się bloki kodu, a nie pojedyncze linijki. No chyba, że używamy jakiegoś hacka... ale takie rzeczy to najczęściej w cssie.

[Xelah]

Nope. Przydatne komentarze są przydatne. Ale komentuje się bloki kodu, a nie pojedyncze linijki. No chyba, że używamy jakiegoś hacka... ale takie rzeczy to najczęściej w cssie.

A sytuacji, gdzie komentarz jest przydatny jest jak na lekarstwo. Tak na szybko to jedyne co mi przychodzi do głowy, to praca z zewnętrznymi bibliotekami, które na przykład indeksują od 1 a nie od 0 i we własnym kodzie masz na przykład "$index + 1". Ale to są wyjątki. We własnym kodzie poza phpdoc metod (co wchodzi, co wychodzi i czy wyrzuca wyjątki) komentarz jest zawsze zbędny. A jeśli widzisz, że musisz dodać komentarz to zazwyczaj znaczy, że coś z kodem jest nie tak.
Wiem, że nazwenictwo metod i klas jest trudne. Tak samo jak rozbijanie mednej większej metody na mniejsze o sensownych nazwach. Ale to właśnie pozwala na kompletne uniknięcie komentarzy. Do tego trzymanie się SOLID (ze szczególnym naciskiem na S i D) bo wtedy jak na dłoni widać co jest gdzie i po co.

PS. To zna chyba każdy programista bez względu na język programowania, ale to bardzo dobrze oddaje wagę prawidłowego nazwenictwa:
"There are two hard things in computer science. Cache invalidation, naming things and off-by-one errors."