Ocena projektu po poprawie

Witam, 2 tygodnie temu zadałem post o ocenę mojego systemu logowania i rejestracji, to był ten post: Klik. Dziękuje wszystkim za dobre rady, część z nich zastosowałem w swoim projekcie np. namespace. Niestety część jeszcze ich nie użyłem np. PSR4 czy composer, prosiłbym do tego jakiś ciekawy poradnik, gdzie wszystko jest ładnie wytłumaczone, tylko nie Krzysztofa Stanio bo nie lubię jego poradników. Mam nadzieję że teraz kod wygląda trochę lepiej. Dodałem więcej funkcji do strony. Piszę ten post, aby potem sprawdzić czy mój kod wygląda w miarę w porządku i zapobiec poprawiania kodu zbyt w wielu miejscach. Do tego mam pytanie czy dobrze używam tych namespace.

Kod: https://github.com/ThePatrykOOO/SocialSite

Link do posta: http://patrykfilipiak.pl/social-site-4/

Trochę sugestii by się uzbierało, zależy o ocenę czego dokładnie pytasz i jak ma być dokładna.

Jeśli chodzi o PHP:

Dziwne przestrzenie nazw
```
use SignUp\SignUp as SignUp;
use User\User as User;
```
Skoro klasa nazywa się User to po co jeszcze raz nazywasz ją jako User (as User)? Poza tym przestrzeń nazw User i w niej klasa User też nie brzmi sensownie. I to nie jednorazowy przypadek, bo wszędzie masz np. Error\Error. Polecałbym jednak poznać PSR-4 i Composer, dołączysz plik z autoloadem i będziesz miał dostęp do wszystkich klas poprzez przestrzenie nazw.
https://github.com/ThePatrykOOO/SocialSite/blob/master/php/errors.php#L19
Po co 3 funkcje, które robią dokładnie to samo? Jakbyś miał 30 formularzy na stronie to zrobiłbyś 30 takich samych funkcji?
```
array(PDO::MYSQL_ATTR_INIT_COMMAND =>  "SET NAMES 'UTF8'"));
```
Od zapisu z array() już się raczej odchodzi, osobiście też wolę [].
Praktycznie wszędzie zapisujesz stringi w cudzysłowach. Moim zdaniem to bez sensu w momencie gdy wiesz, że nie pojawi się w nim żadna zmienna do podstawienia.
https://github.com/ThePatrykOOO/SocialSite/blob/master/php/signup.php#L23
strlen() ma problemy z m.in. polskimi znakami, zobacz mb_strlen().
https://github.com/ThePatrykOOO/SocialSite/blob/master/php/signup.php#L53
Chyba dałeś tutaj zły komunikat błędu, bo warunek sprawdza emaila a nie datę.
Taka walidacja:
```
        \SignUp\SignUp::checkName($name);
        \SignUp\SignUp::checkSurname($surname);
        \SignUp\SignUp::checkBirth($birth);
        \SignUp\SignUp::checkEmail($email);
```
Nie wydaje się zbyt praktyczna... Idąc za przykładem powyżej, gdybyś miał 30 formularzy i w każdym 5 pól do sprawdzenia to zrobiłbyś 150 funkcji?
Polecałbym przygotować coś bardziej uniwersalnego, albo nie wynajdywać koła na nowo i użyć czegoś gotowego i znanego, np. https://github.com/Respect/Validation
Prawie wszędzie wywołujesz funkcje statyczne. Raczej dążyłbym do tego, aby tworzyć normalne obiekty, a odchodził od metod statycznych, a u Ciebie ta obiektowość wygląda nieco naciąganie.
```
$question = \Connect\Connect::connect()->prepare($sql);
```
Skoro za każdym razem przy operacji na bazie wywołujesz statyczną funkcję connect() to za każdym razem wykonuje się wpisany w niej kod, czyli utworzenie połączenia z bazą. W konsekwencji tego gdybyś wykonywał kilka razy operacje na bazie, kilka razy będziesz też nawiązywał połączenie. Moim zdaniem bez sensu, połączenie nawiąż raz.
Nazewnictwo zmiennych też czasem jest dziwne, na przykład w powyższej linicje. $question jako nazwa zapytania dodającego użytkownika? Plus za to że nazwy są po angielsku i w cammelCase.
https://github.com/ThePatrykOOO/SocialSite/blob/master/php/connect.php#L11
Trzymanie zmiennych konfiguracyjnych w samym środku klasy to raczej średni pomysł.
Mieszanie HTML i PHP. Byłbym jednak za użyciem systemu szablonów (np. Twig), bo już momentami nie wygląda to czytelnie, a co dopiero za jakiś czas.
Wygląd: w niektórych miejscach kod jest niezgodny z PSR-2, sporo osób się do niego stosuje, więc i Tobie bym polecił.

Jeśli chodzi o pozostałe kwestie:

W HTMLu nie widać zbyt wielu semantycznych znaczników z HTML5. Szkoda.
Widać za to trochę tabelek, na przykład: https://github.com/ThePatrykOOO/SocialSite/blob/master/content/profil-edit-content.php#L14 - w przypadku takim jak formularz chyba próbowałbym się obejść bez niej.
https://github.com/ThePatrykOOO/SocialSite/blob/master/.htaccess#L9
Localhost? Raczej nie powinien się pojawiać na sztywno wpisany bo na finalnym serwerze produkcyjnym będzie trzeba zmieniać.
https://github.com/ThePatrykOOO/SocialSite/blob/master/.htaccess#L19
Wszystkie te reguły są nieco ryzykowne... Pewnie działają jak trzeba, ale problem jest taki, że dopasowane zostanie również wszystko co będzie miało w sobie podane nazwy. To znaczy, że jeśli np. stworzysz plik o nazwie main.css to zamiast niego zostanie zwrócony user/index.php. Polecałbym podawać znaki początku i końca wyrażenia ^$ i wtedy dopasowany będzie adres tylko o dokładnie podanej nazwie. Inna sprawa jest taka, że odchodzi się od robienia reguł w htaccess i robi routing w PHP.
.idea jest niepotrzebna w repozytorium, to tylko pliki Twojego IDE niepotrzebne innym.
Nazewnictwo commitów jest moim zdaniem słabe. Na przykład

Jakoś niewiele mi jako czytelnikowi mówi... Osobiście polecałbym wpisywać krótki opis tego co zostało zrobione (po angielsku). Do tworzenia wersji możesz używać tagów oraz wydań: https://github.com/ThePatrykOOO/SocialSite/tags

Chyba tyle na razie wypatrzyłem. Moim zdaniem w zasadzie ten kod jest do napisania od nowa, ale rozumiem początki. Też kiedyś tak zaczynałem (a nawet gorzej). To moje sugestie, co z tym dalej zrobisz zależy od Ciebie.