Ocena projektu PHP - Forum

Question

Cześć. Tworzę swój pierwszy projekt oparty na wzorcu mvc. Jest to proste forum. Proszę o uwagi, co jest źle, co bardzo źle itd. Pewnie sporo się znajdzie (niektóre rzeczy jeszcze nie dopracowane, inne zrobione tak, aby działały, ale same rozwiązania wydają mi się słabe).

Co na tym forum można robić?

• przeglądać tematy pogrupowane na kategorie
• stworzyć konto, zalogować się, zmienić hasło
• stworzyć nowy temat, odpowiedzieć w temacie (zalogowany użytkownik)
• usuwać tematy i posty (admin)

Póki co to tyle. Na froncie właściwie nic ładnego nie ma, skupiam się tu tylko na backendzie 

link

 

Answer 1

1. Do repo nie wrzucasz katalogu vendor

2. Nie przestrzegasz standardów PSR

3. Używaj use

4. Możesz używać return type-hintów

5. Możesz korzystać z yoda conditions

abstract class Access {
    public function __construct() {
    }

?

6. 

return @$_SESSION[$key];

wyrzuć małpe

7. 

class Database extends PDO {

zrobiłbym extends \PDO

To tak na szybko.

Comments

5. Możesz korzystać z yoda conditions

Nie wiem czemu wszyscy tak się uparli na to Yoda conditions. To jest tak niesamowicie niewygodne, że aż mnie głowa boli jak widzę. Jedyny profit jest dla samego programisty i tylko w przypadku, gdy porównuje za pomocą ==/=== coś do zmiennej. W każdym innym przypadku używanie yoda conditions jest zbędne. 

Poza tym wystarczy pisać testy i używać potrójnego '=' zamiast podwójnego, żeby uniknąć pomyłek związanych z przypisaniem zamiast porównaniem. 

---

Poza tym wystarczy pisać testy i używać potrójnego '=' zamiast podwójnego, żeby uniknąć pomyłek związanych z przypisaniem zamiast porównaniem. 

Spróbuj tak w Propelu  Korzystam z Yoda cond., bo wg mnie czytelniejsza jest intencja porównania. 

zrobiłbym extends \PDO

Z kolei to jest dla mnie niezrozumiałe. Najpierw piszesz mu use, a potem sam sobie przeczysz. 

---

abstract class Access {
    public function __construct() {
    }

?

Konstruktor rodzica można wywołać z klasy dziedziczącej, więc to jest jak najbardziej prawidłowe. Inna sprawa, to dlaczego ta klasa jest abstrakcyjna. Bo jeśli jedynie chcemy uniemożliwić tworzenie nowych instancji tej klasy, to wystarczy ustawić konstruktor jako prywatny.

---

Bo jeśli jedynie chcemy uniemożliwić tworzenie nowych instancji tej klasy, to wystarczy ustawić konstruktor jako prywatny.

To IMO zła praktyka. Jeśli rzeczywiście nie chcesz tworzyć instancji to skorzystaj z abstract. Jeśli klasa posiada zbyt wiele konkretnych cech, jak na byt abstrakcyjny, to lepiej użyć traita+interface. Prywatne konstruktory to domena singletonów. 

---

@Mariusz08, wprowadziłem kilka zmian, dodałem deklaracje typów - tutaj chyba trzeba by zrobić wyłapywanie ew. błędów. Z błędów z ptk.2, które znalazłem to: 

• brak pustych linii po namespace i use
• subnamespacesy zaczynające się z malej litery
• klamry przy klasach i metodach (?)
• else if zamiast elseif

 

 

---

Jeszcze tylko nazewnictwo zmiennych, klamry, itd. Polecam lekturę

zrobiłbym extends \PDO Z kolei to jest dla mnie niezrozumiałe. Najpierw piszesz mu use, a potem sam sobie przeczysz.

Niby tak - ale jakoś weszło mi w nawyk to, żeby przed funkcją/klasą wbudowaną w PHP pisać \. np. \PDO, https://github.com/symfony/symfony/blob/f834c9262b411aa5793fcea23694e3ad3b5acbb4/src/Symfony/Component/Cache/Traits/PdoTrait.php#L50

 

---

Ale to pisał Fabpot, a Ty