Wasze konwencje nazewnicze, nieszablonowy styl kodu.

0

Macie jakiś swój nieszablonowy styl kodu?

3

chyba jednak cały myk polega na tym aby stosować ogólnie przyjęty styl pisania kodu

0

Jeśli mowa o "stylu" (jak w treści posta), to o obrębie danego teamu spokojnie można umówić się na inną konwencję, niż reszta świata. Zwłaszcza jeśli chodzi o detale, bo nieraz to rzecz gustu.

Natomiast jeśli mówimy - jak to z kolei ujmuje tytuł wątku - o konwencji nazewniczej, to jest inna sprawa, niż styl, więc nie wiem, o co autorowi chodziło. W kwestii nazewnictwa wątpię, czy w ogóle istnieje, ani czy jest nawet możliwa jakaś oficjalna, ogólna konwencja, która miałaby się stosować do wszystkich projektów świata. Można co najwyżej mówić o pewnych ogólnych wytycznych, "rules of thumb".

0

@V-2
@abrakadaber
Miałem na myśli nazewnictwo prywatnych właśności klasy(metod, zmiennych), może też publicznych argumentów, lokalnych zmiennych - to co jest widoczne tylko z warsztatu.
Nie wyszedł mi opis, nie przemyślałem.

Ja np zawsze piszę metody i zmienne prywatne jednym ciągiem lowercase, a argumenty i zmienne lokalne normanym CamelCase.
Tak po prostu łatwiej mi się koduje, odnajduje we własnym kodzie.

1

Już podobny temat był

Ogólnie przyjęte jest, że prywatne pola, lokalne zmienne i parametry piszemy camelCasem (ja pola prywatne poprzedzam jeszcze podkreślnikiem). Dla pozostałych nazw używa się PascalCase'a. End of story (coś pominąłem?).

Ja osobiście używam jeszcze tej samej konwencji dla pól chronionych (protected) co dla prywatnych, czyli camelCase.

Moim zdaniem pisanie lowercasem jest nieprzejrzyste. weźnapisztakjakąśdłuższązmienną i masz się potem wpatruj.

4

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions - jeśli ktoś się tego nie trzyma, to pisze w jakimś swoim Suahili, a nie w C#.

0

A niech se będzie, ważne, że jest wyraźny kontrast między publicznymi.
Będziesz się wpatrywał jak będziesz chciał coś zmienić niżej w logice.

camelCase niszczy mi mózg : D
Pewnie przez indywidualne poczucie estetyki.

Jestem za unifikacją API, warsztat niech sobie każdy ma jaki chce, co komu do tego.

1

Będzie miał coś do tego ktoś, kto po kilku latach będzie szukał błędu w Twoim kodzie, podczas gdy Ty będziesz już daleko niewiadomogdzie.

1

To nie wiem, ja jestem wyjątkowo odblokowany, czy Wy jesteście wyjątkowo poblokowani.
Jeśli kod jest dobry, to nie zmieni tego jakaś głupia konwencja nazewnicza.
Chyba, że w notatniku przeglądacie.

1
Brunatny Samiec napisał(a):

Jeśli kod jest dobry, to nie zmieni tego jakaś głupia konwencja nazewnicza.

Jedną z cech dobrego kodu jest brak głupich konwencji nazewniczych.

0

Jestem za unifikacją API, warsztat niech sobie każdy ma jaki chce, co komu do tego.

Takie myślenie jest krótkowzroczne. Cały kod musi być zadbany, bo cały kod musi być utrzymywany.

Jeśli kod jest dobry, to nie zmieni tego jakaś głupia konwencja nazewnicza.

Ja uważam lowercase za nieczytelny, ale używaj konwencji jakiej chcesz Ty i Twój zespół. Byle nie byłaby to konwencja liter alfabetu (np. a, b, c, d, itd)

0
Brunatny Samiec napisał(a):

Jeśli kod jest dobry, to nie zmieni tego jakaś głupia konwencja nazewnicza.

W praktyce jedno z drugim się wiąże. W dobrym kodzie zazwyczaj nie znajdziemy bezsensownych konwencji, a kiepska konwencja nie przepowiada dobrego kodu.

2

Jestem za unifikacją API, warsztat niech sobie każdy ma jaki chce, co komu do tego.

Ale o jakiej unifikacji mowa jeśli jedna klasa (publiczna) będzie trzymała się jednych standardów, a klasa "obok" (wewnętrzna) będzie trzymała się innych? Koniec końców w kodzie robi Ci się miszmasz. Jaki tego sens? To jakiś efekt wieku buntowniczego czy coś?

4

Każdy powinien być w stanie usiąść nad cudzym kodem, i z miejsca zacząć nad nim pracować. Ludzie jeżdżą na wakacje, ludzie odchodzą z pracy, przychodzą na ich miejsce nowi, a kod zostaje. Zły to znak, jeśli ktoś jest "ekspertem od klasy InvoiceProvider" :) Niedobrze, jeśli trzeba z projektem czekać, aż Radek wróci z Teneryfy, a nowy programista, próbując połapać się w kodzie, doznaje objawów wstrząsu anafilaktycznego.

Dlatego podejście "warsztat niech sobie każdy ma jaki chce", jest słabe, bo projekt to nie jest zbiór prywatnych warsztatów, ale jeden wspólny warsztat. Każdy powinien się w nim poruszać bezpiecznie i z łatwością, a to jest możliwe dzięki standaryzacji podejścia w całym kodzie.

0

A jak to jest z tymi podkreślnikami przed nazwami prywatnych pól? Widzę, że dużo ludzi je stosuje, ale już np. w przykładowym kodzie @somekind ich nie ma.

0

Podkreślniki to chyba jedna z tych rzeczy co do których trzeba dość do konsensusu. W poprzednim projekcie przy którym pracowałem uzywalismy ich, w obecnym nie. Prywatnie je używam.

Nawet w Microsofcie zdania są podzielone. W większości kodu i przykładów stosują podkreślniki, ale nie zawsze.

0

I na prawdę utrudnia Wam to czytanie kodu? Abstrakcyjnie konwencja jest ta sama: kontrast między przeznaczeniem własności.

Jak można się o podkreślniki kłocić.
Wy jesteście nienormalni chyba.

Jestem indywidualistą, a nie buntownikiem.

Chciałem się tylko powymieniać konwencjami, może coś lepszego znalazłbym dla siebie.

0

Nikt tutaj się nie kłóci o podkreślniki. Chyba Ty jesteś nienormalny jeśli widzisz tu jakieś kłótnie z tym związane. Sorry ale to Ty wyskoczyłeś pierwszy z obrażaniem...

Jestem indywidualistą, a nie buntownikiem

Możesz być nawet księżną ale pracując w grupie liczy się dobro grupy (oraz osób które będą z tym kodem pracować w przyszłości). Tu nie ma miejsca na jakieś "widzi mi się".

2

Jedyna sytuacja, gdzie zrobiłem głupie nazewnictwo, to ostatnio, pisząc DLLkę, umieściłem w niej funkcję: "JustLoadAndDontCare" :)
Dllka ma za zadanie odczytać pełną geometrię i inne informacje z plików ifc. Używa wewnętrznie IFC++, ale żeby odczytać tym plik trzeba narobić jeszcze kilka fikołków. Więc postanowiłem umieścić taką dodatkową funkcję, która już robi wszystko, co podstawowe i wystarczające w większości przypadków :)

2

Podkreślniki czy ich brak to kwestia umowna. Tak jak formatowanie nawiasów klamrowych. Wartością konwencji nie jest konkretne rozwiązanie (z których wiele może być równorzędnych), ale spójność. Wolę brzydką konwencję, ale stosowaną konsekwentnie, niż w przemieszaniu z moją ulubioną. Nie ma najmniejszych wątpliwości, co jest lepsze.

Jako programiści musimy sporo myśleć i utrzymywać w głowie wyobrażenia złożonych, abstrakcyjnych systemów.

screenshot-20181004120930.png

Każda pierdoła, która niepotrzebnie absorbuje choćby 1% naszej koncentracji, jest wrogiem z definicji. Każde wymuszone, dodatkowe 0,2s zastanowienia się - co właśnie przeczytałem - to jak próg zwalniający na drodze, "mental bump". Oczywiście, że nas to nie zablokuje, jedziemy dalej, ale jakby wysysa energię. I jeśli się uderza w takie garby na jezdni sto razy dziennie, to się pod koniec dnia objawi jako narosła frustracja. A jeśli już mam być pod koniec dnia sfrustrowany, niech chociaż będzie ku temu jakaś lepsza przyczyna, niż praca z "indywidualistą".

4
nobody01 napisał(a):

A jak to jest z tymi podkreślnikami przed nazwami prywatnych pól? Widzę, że dużo ludzi je stosuje, ale już np. w przykładowym kodzie @somekind ich nie ma.

Osobiście zazwyczaj stosuję this.. Tam akurat nie chciało mi się tego dopisywać.
W pracy często mam podkreślniki, ale sam ich nie lubię, bo kojarzą mi się z notacją węgierską. Tylko to nie jest żaden duży problem dla mnie.

Brunatny Samiec napisał(a):

I na prawdę utrudnia Wam to czytanie kodu? Abstrakcyjnie konwencja jest ta sama: kontrast między przeznaczeniem własności.

Tak, trudniej przeczytać numberofcustomerswithoutdatedpayments niż numberOfCustomersWithOutdatedPayments.

Jestem indywidualistą, a nie buntownikiem.

Na pewno jesteś bucem. I to raczej niezbyt bystrym, skoro w swoim wątku wyzywasz ludzi, którzy próbują odpowiadać.

Chciałem się tylko powymieniać konwencjami, może coś lepszego znalazłbym dla siebie.

Wyzywanie ludzi od nienormalnych niewątpliwie zachęca do wymiany poglądów. ;]

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