Tworzenie portfolio - prośba o ocenę kodu

Odpowiedz Nowy wątek
2019-08-13 11:35
0

Cześć.
Na początku chciałem Wam powiedzieć, że bardzo się cieszę z dołączenia do forum. Mam nadzieję że będzie to przyjemność odwzajemniona :)

Kilka słów o sobie:
Jestem Grzesiek i mam 24 lata. Jeszcze 3,5 roku temu nie wiedziałem kompletnie nic o programowaniu.
Obecnie jestem po 3 roku studiów na informatyce.
Pracuję również zawodowo - mam w tej chwili ok. 10 miesięcy doświadczenia (3 miesiące praktyk + 7 miesięcy zatrudnienia na UoP).
W pracy piszemy głównie w C++, choć zdarzają się też inne języki - jak np. C lub Python.

Z języków i technologii, które poznałem, najbardziej lubię C++ (zwłaszcza od standardu C++11 wzwyż).
Wiem też o nim zdecydowanie najwięcej (co nie znaczy że uważam się za eksperta - wiele słyszałem o tym, jak trudny jest to język i wiem że jeszcze wiele się muszę nauczyć).
Chcę się dalej rozwijać jako programista C++ i stawać coraz lepszym specjalistą.

Częścią tego planu jest tworzenie portfolio.
Do tego celu przeznaczyłem swoje konto na Githubie.
Będą tam trafiały projekty, które chciałbym "pokazać światu".
Nie tylko po to, żeby się pochwalić.
Głównie dlatego, że zależy mi na opinii bardziej doświadczonych programistów.
Osób, dzięki którym mogę stać się jeszcze lepszym.
Nie ukrywam również, że te portfolio zamierzam wykorzystywać na swoich przyszłych rozmowach o pracę.

Będę bardzo wdzięczny za wszystkie uwagi i sugestie, dotyczące moich projektów.
Są to obecnie 3 projekty: NumericSolitaire, ContextFreeGrammar oraz SchoolStatistics.
Z czasem planuję rozszerzać portfolio o kolejne projekty.
Szczegóły nt. każdego projektu są w plikach README, dlatego tutaj nie będę się rozpisywał na ten temat.

Jeszcze raz z góry dziękuję za wszystkie Wasze opinie w tej sprawie. :)

Pozostało 580 znaków

2019-08-13 11:42
0
  1. Nie ma w README.md jak to odpalić.
  2. Nie ma makefile.
  3. Nie ma bazy danych.
1. Możesz rozwinąć swoją myśl? Nie do końca zrozumiałem. 2. O który projekt Ci chodzi? Dla NumericSolitaire oraz ContextFreeGrammar nie ma potrzeby pisać make'a (jest tylko jedna jednostka kompilacji), zaś w projekcie SchoolStatistics jest qmake. Zresztą ja zawsze budowałem projekt w Qt Creatorze, tak mi było wygodniej. 3. "Bazą danych" jest plik tekstowy. Takie było założenie tego projektu. Oczywiście chodzi o projekt SchoolStatistics, pozostałe projekty nie potrzebują bazy danych. - galgreg 2019-08-13 13:23

Pozostało 580 znaków

2019-08-13 11:55
0

Nie Masz żadnych testów, czyli potencjalnie jest tam pełno bugów - raczej nie można na tych programach polegać.


SchoolStatistics napisałem w całości, stosując TDD. Jest tam dużo testów. Pozostałe projekty faktycznie nie mają testów, a nie ma ich ponieważ w momencie pisania nie miałem na to czasu - wolałem się skupić na ogarnięciu innych rzeczy, takich jak algorytm rozwiązania czy szybkość wykonywania. Normalnie wiem o tym, że testy są bardzo ważne. W pracy piszę ich bardzo dużo. Jednak tutaj sobie to odpuściłem, bo uznałem że są ważniejsze rzeczy do ogarnięcia. Może kiedyś dołożę brakujące testy, ale nie w najbliższym czasie, bo obecnie mam urwanie głowy ;) - galgreg 2019-08-13 21:06

Pozostało 580 znaków

2019-08-13 12:03
0

Nazwy plików, branchy i commit msgi po polsku - zła praktyka.

w ContextFreeGrammar widzę 6 commitów 1 dnia zmieniająca jeden plik, i to z takim samym commit msgiem. Lepszy byłby 1 czy 2 przemyślane.

No i strasznie dziwne dziwne wcięcia w kodzie, np.:
void print(
const set<string> &printedSet,
string setName,
unsigned i,
unsigned j,
unsigned k) {

Dzięki za cenny feedback. Co do wcięć, tak nauczyłem się w pracy. Chodzi o to, żeby nie przekraczać limitu 80 znaków na wiersz. Moim zdaniem zwiększa to czytelność kodu, choć jest to pewnie kwestia gustu. - galgreg 2019-08-13 13:29
Argumenty w nowych liniach są ok jak dla mnie. Bardziej chodziło mi o klamrę { w tej samej linii co (. I używanie tabów co przynajmniej na githubie jest pokazywane jako dość szerokie wcięcie. Spacje są lepiej zdefiniowane, wszędzie będą wyglądać podobnie. - okmanek 2019-08-13 13:38
Taby faktycznie bywają kłopotliwe (zwłaszcza jak piszesz w Pythonie :P). Co do klamer, to z tego co wiem są na to (co najmniej) dwa podejścia. W pracy mamy narzucone, żeby klamrę pisać w tej samej linii co koniec nagłówka funkcji. Ja w swoich prywatnych projektach też tak piszę, żeby nie ryzykować że mi się później w pracy pomiesza :) - galgreg 2019-08-13 21:20

Pozostało 580 znaków

2019-08-13 14:01
0

@galgreg:

  1. Powiedz swojej mamie by odpaliła ten kod. Pewnie jej się nie uda, ale gdyby np. było tam napisane, że aby to skompilować i uruchomić trzeba w terminalu napisać make build itd. to pewnie by sobie poradziła.
  2. Nie ma znaczenia ile plików. Wydaje mi się że powinniśmy być makefile, choć przyznaję dawno nie pisałem w C/C++.
  3. No to to sa zle założenia. Dla mnie jest to błędna praktyka.

Pozostało 580 znaków

2019-08-14 09:20
0

Kilka uwag odnośnie projektu SchoolStatistics

  1. Staraj się tworzyć obiekty przy pomocy make_unique<>() CoreGuidelines
  2. Funkcje nie zgłaszające żadnych wyjątków powinny posiadać noexcept w swojej definicji.
  3. Pomyśl o funkcjach zwracających dane ( np. size_t Grades::maxAllowedCount() ) jako o funkcjach inline.
  4. Dobrym pomysłem jest użycie własnego namespace.
  5. W kodzie nie widzę komentarzy - może przydał by się QDoc lub doxygen i porządna dokumentacja kodu.
edytowany 1x, ostatnio: TomaszLiMoon, 2019-08-14 09:28

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0