[Hauleth]

Nazewnictwo w kodzie:

-

PascalCase

- klasy (i inne typy)

-

UPPER_SNAKE_CASE

- stałe

-

lower_camel_case

- metody i zmienne

#programowanie #stylkodowania #flamewar

[R.....m]

@Hauleth: #flamewar? bardziej #czarnolisto

[a.....1]

@Hauleth: przecież te standardy są zależne od języka...

[Hauleth]

@an21: Jak np. w C/C++.

[Rincewind]

@Hauleth: http://www.wykop.pl/wpis/4747075/programowanie-macie-jakies-prawidla-w-nazewnictwie/#comment-10265623

[Hauleth]

@Rincewind: Za prefiksy/postfiksy powinni strzelać. Osobiście wolę

lower_snake_case

bo wtedy od razu widać czy to zmienna czy klasa. Co do ang. to zgadzam się w 100%.

[sylwke3100]

@Hauleth: @RetSnom: @an21: @Rincewind: Ja staram się np stosować nazewnictwo typu :

funcjaCo (np getName) i to mi się wydaje jednyne słuszne niezależnie od języka.

[Hauleth]

@sylwke3100: Tak bardzo nie. Samego stosowania getterów i setterów powinno się unikać, a przynajmniej ich nazywania tak. Ani nie

camelCase

ani stosowanie przedrostków czasownikowych, i.e.

get_name

.

[sylwke3100]

@Hauleth: Podałem przykład. Tak poza tym jakieś wytłumaczenie co do setterów, getterów bo ja nigdy takiego stwierdzenia nie słyszałem tak samo jak tego że się używa typu funkcja_co (nawet to w jakimś większym OSowym projekcie widziałem)

[a.....1]

@sylwke3100: ja zawsze dostosowuję się do standardów języka, w którym piszę. Raz, że taki standard jest wypracowany przez społeczność ludzi, którzy klepią godzinami w konkretnym języku, a więc jest często dosyć "optymalny" i czytelny. Dwa: jeśli pokazuję kod innej osobie, to łatwiej jej czytać ustandaryzowany kod (np. w C# nazwy interfejsów są zapisywane za pomocą notacji węgierskiej i widząc C# ICośtam wiadomo, że to interfejs, czy też nazwy zmiennych prywatnych _cośtam)

[Rincewind]

@Hauleth: Prefix – postfix to temat na holy war, więc nie zagłębiajmy się. ;) To głównie zależy od języka. Ale weźmy taki C++ (nie programowałem w nim od lat, ale wciąż co nieco pamiętam): zawsze robiłem tak, że getter był w postaci

T foo() const

, natomiast setter

T& foo)

. I w takim wypadku samo pole dostawało sufix

_

.

[Hauleth]

@sylwke3100: Jeśli ma być trywialny getter albo setter to lepiej ustawić zmienną jako publiczną, a jeśli robi coś więcej to zazwyczaj nazwa set_blabla jest niewystarczająca. Co innego jednak, jeśli jest to język, w którym nie ma zmiennych publicznych instancji (jak Ruby).

[WolverinePL]

@sylwke3100: Wielu teoretyków do OOP uważa za dobre minimalizowanie przepływu danych między obiektami. Coupling też się zwiększa przez takie coś: Car::Engine::turnOn() vs Car::Engine::setRunning(bool), getter/setter niepotrzebnie eksponuje wnętrze obiektu.

Albo inny przykład:

IObject & GameUniverse::getObject(Identifier id); // IObject *, std::shared_ptr?

std::vector GameUniverse::getAllObjects();

vs

void GameUniverse::forObject(Identifier id, std::function); // lub predykat zamiast id

void GameUniverse::forEachObject(function...);

Tutaj dzięki temu, że Obiekt nie wychodzi poza GameUniverse dużo łatwiej zrobić np locki.