Pamiętam że Overment kiedyś popełnił materiał o BEM, w jakimś stopniu pokrywa to zagadnienie tworzenia struktury katalogów. Niemniej poprawnych podejść jast ogrom.
5:39 Przyjęło się stosowanie przedrostka "I" w C# z tego względu że w C# przy implementacji interfejsu nie ma słowa "implements" tylko jest : tak jak przy dziedziczeniu po klasie. Przynajmniej mi się tak wydaje z własnej praktyki. Od razu widać, że implementuje to interfejs a nie rozszerza klasę.
@@marcinz9379 Nie no to ze coś jest głupie, ale pomaga w kodzie to nie znaczy że jest głupie. Poza tym kod i tak jest manglowany przez kompilator więc wynikowo i tak będzie to to samo.
Bardzo dobry materiał! Liczę na więcej odcinków poświęconych konwencjom w programowaniu. Dużo przyjemniej się słucha osoby przekazującej wiedzę. Polecam takie materiały jak twój osobom, które czasem uczą się języka Java. To przyczynia się do mniejszego zamieszania podczas code review.
A w jakiej sytuacji chciałbyś nazwać tak samo zarówno interfejs jak i klasę implementującą ten interfejs? Bo brzmi to jak źle zaprojektowany kod, więc jeżeli napotkasz taką sytuację, potraktowałbym to jak czerwoną lampkę, że coś jest nie tak i przemyślał jeszcze raz strukturę kodu.
w przypadku zmiennych boolean nie polecam robic nazwy typu "isActive" bo IDE w wiekszosci przypadkow do czegos takiego utworzy setter "setIsActive" a getter "isIsActive", po prostu samo "active" wystarczy
To jest w sumie temat na odrębną dyskusję:) Bo w tym przypadku nie generalizowałbym tak mocno - są sytuacje, w których dodawanie prefiksu w postaci is / has / was jest zbędne, ale z kolei w innych sytuacjach użycie prefiksu zwiększa czytelność kodu. Co do generowania getterów i setterów w IDE, można to oczywiście różnie skonfigurować, warto też zawsze zweryfikować kod po wygenerowaniu. A na przykład w przypadku Lomboka nie będzie znaczenia czy zmienną nazwiemy active czy isActive, bo Lombok zawsze w tym przypadku wygeneruje getter i setter isActive oraz setActive.
skraceanie userList do users nie zawsze jest praktyczne , ale czasem klasa to więcej niż jeden ekran i można się pogubić czy users to akurat lista czy kolekcja czy jakaś klasa , choć dzisiejsze IDE podpowiadają co to za zmienna
Dla mnie nie ma ani jednego zastosowania, w którym zamieszczanie w nazwie zmiennej informacji o jej typie było uzasadnione. W dobrze zaprojektowanym kodzie, z odpowiednią enkapsulacją, gdy korzystasz z jakiejkolwiek kolekcji, nie powinieneś przejmować się szczegółami implementacji - Twoim zadaniem jest dodać, usunąć, pobrać elementy z tej kolekcji, ale nie powinno mieć dla Ciebie żadnego znaczenia, czy pod spodem jest ArrayList, LinkedList czy HashSet. To autor kodu odpowiedzialnego za operacje na tej kolekcji powinien zadbać już o udostępnienie na zewnątrz odpowiednich metod. A jeżeli czujesz, że musisz dodać do nazwy zmiennej słowo "list", "set" czy "map", warto zatrzymać się na chwilę i zastanowić się, czy faktycznie ten kod jest ok, czy może jednak wymaga on pewnej refaktoryzacji.
Ogólnie się zgadzam, ale długie nazwy zmiennych mogą być problematyczne np. w pythonie często nie ma za dużo miejsca w linijce i równania się rozłażą na kilka linijek co pogarsza czytelność kodu. Trzeba szukać złotego środka pomiędzy nazwą zmiennej, bo za krótka mówi za mało, a za długa pogarsza czytelność. Np. DistanceFromSignalAfterTransformation = DistanceFromSignalBeforeTransformation * TransformationFormula
Ja jeżeli nazywam zmiennie ,klasy lub metody wolę użyć długiej nazwy ale dobrze wyjaśniającej o co chodzi niż krótkiej, która nic nie mówi.Czytając kod innych osób często można spotkać metodę np count() i co ona niby zlicza? arbuzy?
Tak też tego nie lubię. Mam wrażenie, że w pewnym momencie była jakaś moda na jak najkrótsze nazwy. Mamy później takie efekty, że zamiast od razu wiedzieć co robi funkcja to muszę wejść i ją przeanalizować, niepotrzebnie zmarnowany czas. Niektórzy mi mówią, że tak nie powinno się robić, bo po co takie długie nazwy, ale nie mają logicznego argumentu, który by uzasadniał ich punkt widzenia.
Mam pytanie, jak nazwałbyś metodę w kontrolerze która wyciąga dane usera? Pewnie getUser. Metode w serwisie? Również getUser? A metodę wykonującą zapytanie do bazy danych? Też po raz kolejny getUser?
Tak, nie szukałbym tutaj synonimów. Proste "get" jest zdecydowanie najlepszym rozwiązaniem. Ale oczywiście nie zawsze musi to być dokładnie "getUser", bo jeżeli raz pobieramy instancję użytkownika, a raz pobieramy szczegóły związane z użytkownikiem, to wtedy nazwiemy to inaczej. Możemy mieć getUser, getUserDetails, getUserFromDatabase. Wszystko zależy tak naprawdę od kontekstu i od tego, co chcemy zapisać za pomocą kodu. Natomiast jeżeli chodzi o sam czasownik oznaczający pobranie czegoś, to dla mnie w kodzie zawsze jest to get.
Fajnie by było jakby pojawił się też odcinek, w jaki sposób odpowiednio nazywać pliki w projekcie i tworzeniu jego struktury. Materiał bardzo fajny
Albo komentarze, kiedy i jak je pisać
Pamiętam że Overment kiedyś popełnił materiał o BEM, w jakimś stopniu pokrywa to zagadnienie tworzenia struktury katalogów. Niemniej poprawnych podejść jast ogrom.
5:39 Przyjęło się stosowanie przedrostka "I" w C# z tego względu że w C# przy implementacji interfejsu nie ma słowa "implements" tylko jest : tak jak przy dziedziczeniu po klasie. Przynajmniej mi się tak wydaje z własnej praktyki. Od razu widać, że implementuje to interfejs a nie rozszerza klasę.
@@marcinz9379 Nie no to ze coś jest głupie, ale pomaga w kodzie to nie znaczy że jest głupie. Poza tym kod i tak jest manglowany przez kompilator więc wynikowo i tak będzie to to samo.
Dobry materiał. Nie wszyscy zdają sobie sprawę jak bardzo ważne jest nazewnictwo :)
Bardzo dobry materiał! Liczę na więcej odcinków poświęconych konwencjom w programowaniu. Dużo przyjemniej się słucha osoby przekazującej wiedzę. Polecam takie materiały jak twój osobom, które czasem uczą się języka Java. To przyczynia się do mniejszego zamieszania podczas code review.
Bardzo fajny, skondensowany i przystępny materiał. Super :)
Ale super materiał! Bardzo pouczający. Dzięki za filmik.🙏 Mem był extra 😀
7:15
Super, aczkolwiek działa tylko w przypadku gdy język pozwala na przeciążanie metod jak np. Java, w przypadku PHP by to nie wyszło.
Jasna sprawa, w takim przypadku nie mamy zbyt dużej swobody. Wtedy nie ma wyjścia, trzeba dodawać to byId, byName do nazwy.
Dobra lekcja 👍
spoko filmik, pozdrawiam cieplutko
Dzięki i również pozdrawiam!
A jak jest interface Car i chce zrobic class Car ? To jak nazwac jedno lub drugie zeby nie bylo konfliktu nazw?
A w jakiej sytuacji chciałbyś nazwać tak samo zarówno interfejs jak i klasę implementującą ten interfejs? Bo brzmi to jak źle zaprojektowany kod, więc jeżeli napotkasz taką sytuację, potraktowałbym to jak czerwoną lampkę, że coś jest nie tak i przemyślał jeszcze raz strukturę kodu.
Można powiedzieć, że streścił Pan książkę "Czysty Kod", kiedy "Czysta Architektura" ? :D
Sugeruję zrobić materiał na temat dzielenia klas lub metod na pomniejsze w celu refaktoryzacji kodu
w przypadku zmiennych boolean nie polecam robic nazwy typu "isActive" bo IDE w wiekszosci przypadkow do czegos takiego utworzy setter "setIsActive" a getter "isIsActive", po prostu samo "active" wystarczy
jakie ide?
To jest w sumie temat na odrębną dyskusję:) Bo w tym przypadku nie generalizowałbym tak mocno - są sytuacje, w których dodawanie prefiksu w postaci is / has / was jest zbędne, ale z kolei w innych sytuacjach użycie prefiksu zwiększa czytelność kodu. Co do generowania getterów i setterów w IDE, można to oczywiście różnie skonfigurować, warto też zawsze zweryfikować kod po wygenerowaniu. A na przykład w przypadku Lomboka nie będzie znaczenia czy zmienną nazwiemy active czy isActive, bo Lombok zawsze w tym przypadku wygeneruje getter i setter isActive oraz setActive.
@@JakNauczycSieProgramowania Od siebie dodam, że kod czyta się wtedy jak książkę jeśli jest jakiś bardziej skomplikowany proces.
skraceanie userList do users nie zawsze jest praktyczne , ale czasem klasa to więcej niż jeden ekran i można się pogubić czy users to akurat lista czy kolekcja czy jakaś klasa , choć dzisiejsze IDE podpowiadają co to za zmienna
Dla mnie nie ma ani jednego zastosowania, w którym zamieszczanie w nazwie zmiennej informacji o jej typie było uzasadnione. W dobrze zaprojektowanym kodzie, z odpowiednią enkapsulacją, gdy korzystasz z jakiejkolwiek kolekcji, nie powinieneś przejmować się szczegółami implementacji - Twoim zadaniem jest dodać, usunąć, pobrać elementy z tej kolekcji, ale nie powinno mieć dla Ciebie żadnego znaczenia, czy pod spodem jest ArrayList, LinkedList czy HashSet.
To autor kodu odpowiedzialnego za operacje na tej kolekcji powinien zadbać już o udostępnienie na zewnątrz odpowiednich metod.
A jeżeli czujesz, że musisz dodać do nazwy zmiennej słowo "list", "set" czy "map", warto zatrzymać się na chwilę i zastanowić się, czy faktycznie ten kod jest ok, czy może jednak wymaga on pewnej refaktoryzacji.
Brakuje mi dobrych słów, aby dobrze podsumować ten materiał :)
Bardzo mi miło i cieszę się, że Ci się podoba:)
Ogólnie się zgadzam, ale długie nazwy zmiennych mogą być problematyczne np. w pythonie często nie ma za dużo miejsca w linijce i równania się rozłażą na kilka linijek co pogarsza czytelność kodu. Trzeba szukać złotego środka pomiędzy nazwą zmiennej, bo za krótka mówi za mało, a za długa pogarsza czytelność. Np. DistanceFromSignalAfterTransformation = DistanceFromSignalBeforeTransformation * TransformationFormula
Długa nazwa zmiennej lub metody może sugerować, że trzeba zrobić refaktoring ;-)
Będzie filmik jak nazywać rzeczy w językach które nie są typowane? Np. Pjaton
Pierwszy!
😮😮😮😮😮😮
Ale szybko 😮
Ja jeżeli nazywam zmiennie ,klasy lub metody wolę użyć długiej nazwy ale dobrze wyjaśniającej o co chodzi niż krótkiej, która nic nie mówi.Czytając kod innych osób często można spotkać metodę np count() i co ona niby zlicza? arbuzy?
Tak też tego nie lubię. Mam wrażenie, że w pewnym momencie była jakaś moda na jak najkrótsze nazwy.
Mamy później takie efekty, że zamiast od razu wiedzieć co robi funkcja to muszę wejść i ją przeanalizować, niepotrzebnie zmarnowany czas.
Niektórzy mi mówią, że tak nie powinno się robić, bo po co takie długie nazwy, ale nie mają logicznego argumentu, który by uzasadniał ich punkt widzenia.
Gratulacje zostałeś wybrany przez Boga na nowego Mesjasza XD
isNazwa
isPies
czyWybranoWspolneUsytuowanieNaJednymLozkuDzieckoOpiekun()
Hahaha tak, to jest czyste złoto
isExist
Nie mów mi jak mam pisać bobku
Mam pytanie, jak nazwałbyś metodę w kontrolerze która wyciąga dane usera?
Pewnie getUser.
Metode w serwisie?
Również getUser?
A metodę wykonującą zapytanie do bazy danych?
Też po raz kolejny getUser?
Tak, nie szukałbym tutaj synonimów. Proste "get" jest zdecydowanie najlepszym rozwiązaniem.
Ale oczywiście nie zawsze musi to być dokładnie "getUser", bo jeżeli raz pobieramy instancję użytkownika, a raz pobieramy szczegóły związane z użytkownikiem, to wtedy nazwiemy to inaczej. Możemy mieć getUser, getUserDetails, getUserFromDatabase. Wszystko zależy tak naprawdę od kontekstu i od tego, co chcemy zapisać za pomocą kodu. Natomiast jeżeli chodzi o sam czasownik oznaczający pobranie czegoś, to dla mnie w kodzie zawsze jest to get.
@@JakNauczycSieProgramowania ok dzięki!
@@JakNauczycSieProgramowaniaEwentualnie get można zastąpić słowem fetch gdy pobieramy coś używając Resta
isPies
Najpiękniejszy kod w historii!