Nazewnictwo

[Wonski]

Cześć,
mam kilka niepewności co do nazewnictwa klas.

1. Czy dobrym zwyczajem jest oznaczać interfejs poprzez dodanie przedrostka "_I"? I czy wtedy również pierwsza litera w nazwie klasy powinna być duza?
Np.:

Kod: [Zaznacz]

class _IInterface
lub
 class _ITest

2. Czy klasy abstrakcyjne które nie są interfejsami tez powinno się oznaczać w jakiś szczególny sposób? np przedrostkiem "_A"? No bo interfejs jest klasa abstrakcyjna, a z kolei klasa abstrakcyjna nie musi być interfejsem. Jak to rozróżnić i czy w ogóle musi istnieć taka potrzeba by to rozróżniać?
W konwencji camelcase ani underscore nigdzie o tym nie wspomniano (no chyba, ze to ja coś przeoczyłem).

3. Czy klasy które implementują wzorce projektowe (tzn te "kanoniczne" gangu czterech) powinny być oznaczane w jakiś szczególny sposób? Tzn przez dodanie nazwy wzorca do nazwy klasy czy może informować o tym w komentarzu albo bezpośrednio w dokumentacji?
Czy może raczej powinno to wynikać już bezpośrednio z implementacji?

[Adanos]

Zazwyczaj w .Net używa się "I" np. "IComparer", w Javie dodaje się na końcu "able" np. "IComparable".
Klas abstrakcyjnych nie oznacza się jakoś szczególnie, możesz nazwać AbstractFactory, co też odpowiada na twoje pytanie dotyczące wzorców.
Nazwy klas (i nie tylko klas) powinny jasno mówić, czym są i do czego służą. Tak więc informowanie tego w komentarzu jest bez sensu. Jak już to można wspomnieć w dokumentacji.

[Wonski]

W sumie to mógłbyś podać źródło lub napisać z jakiej konwencji to pochodzi.
No chyba, ze to ogólnie przyjęte normy/zasady.
Bo w sumie takich szczegółów jest sporo, np jak nazywać i gdzie umieszczać testy jednostkowe i integracyjne, kolejność i grupowanie metod w klasie oraz ich kolejność w pliku cpp..
jak wyróżniać funkcje i klasy zaprzyjaźnione, jakie konwencje/normy za to odpowiadają, etc, etc...

Wiem, ze to szczegóły, ale mimo wszystko istotnie wpływają na komfort pracy innych programistów czytających nasz kod.

[inż. Avallach]

Podaj o jaki język chodzi - to ma spore znaczenie. Część języków ma oficjalne przewodniki stylu, w razie ich braku dobrą wskazówką jest styl kodu ich biblioteki standardowej. Nie wydaje mi się żeby był język gdzie prefixowanie nazw klas podkreślnikiem było zalecaną czy chociaż akceptowaną konwencją.

Jeśli chodzi o C++, polecam Google C++ Style Guide.

[Adanos]

W sumie to mógłbyś podać źródło lub napisać z jakiej konwencji to pochodzi.
No chyba, ze to ogólnie przyjęte normy/zasady.
Bo w sumie takich szczegółów jest sporo, np jak nazywać i gdzie umieszczać testy jednostkowe i integracyjne, kolejność i grupowanie metod w klasie oraz ich kolejność w pliku cpp..
jak wyróżniać funkcje i klasy zaprzyjaźnione, jakie konwencje/normy za to odpowiadają, etc, etc...

Wiem, ze to szczegóły, ale mimo wszystko istotnie wpływają na komfort pracy innych programistów czytających nasz kod.

Nie wiem, czy odnosisz się do wszystkiego, co napisałem, czy do ostatniej części...
Dla C#: https://blogs.msdn.microsoft.com/brada/2005/01/26/internal-coding-guidelines/
Dla Javy: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
Reszta z książki "Czysty kod" Martina.

[Wonski]

Podaj o jaki język chodzi - to ma spore znaczenie. Część języków ma oficjalne przewodniki stylu, w razie ich braku dobrą wskazówką jest styl kodu ich biblioteki standardowej. Nie wydaje mi się żeby był język gdzie prefixowanie nazw klas podkreślnikiem było zalecaną czy chociaż akceptowaną konwencją.

Jeśli chodzi o C++, polecam Google C++ Style Guide.

No tak, chodzi oczywiście o c++.
Kiedyś w jednym z tematów pisałeś, ze co kompilator to inna implementacja biblioteki standardowej. Komitet standaryzacyjny nie dostarcza kodu tylko chyba ogólny koncept co i jak ma wyglądać.
No i jak Ci pokazałem fragment kodu pisany przez developerów microsoftu to podsumowałeś to jako kiepski żart

No a jeszcze jest kwestia, ze istnieje wiele kompilatorów, wiec tym samym istnieje kilka innych stylów. Nie trudno wiec wyobrazić sobie sytuacje gdzie przy projekcie np open-source pracuje kilka osób i każda z nich ma inne narzędzia. 

Ten Google C++ Style Guide jest ogólnie przyjętym standardem?

[inż. Avallach]

Kiedyś w jednym z tematów pisałeś, ze co kompilator to inna implementacja biblioteki standardowej. Komitet standaryzacyjny nie dostarcza kodu tylko chyba ogólny koncept co i jak ma wyglądać.

C++ o ile się orientuję jest w tej kwestii raczej wyjątkiem niż regułą. Java i C# mają tylko jedną "oficjalną" implementację biblioteki standardowej - tworzoną przez twórców samego języka. Domyślam się że tak samo w przypadku projektów całkowicie otwartoźródłowych, jak Python.
W przypadku C++ dodatkowo konwencje biblioteki standardowej są rzeczywiście bardzo nieczytelne. Ale trzeba pamiętać że to kod przeznaczony głównie dla kompilatora i z konieczności bardzo, bardzo zoptymalizowany. Absolutnie się na nich nie wzoruj.

Google C++ Style Guide nie jest powszechnie przyjętym standardem - o ile się orientuję jego open-source'owa publikacja jest całkiem niedawna, tak do półtora roku. Ale jest bardzo rozsądny i popiera go autorytet firmy która za nim stoi. Korzystają z niego choćby przy pisaniu Chromium. Dobrze przynajmniej go znać. Na pewno siega po niego sporo projektów choćby otwartoźródłowych. A i łatwiej będzie Ci się nauczyć wewnętrznych korporacyjnych guidelinów kiedy będziesz już wcześniej znał coś przynajmniej częściowo się z nimi pokrywającego. Z drugiej strony np u nas coding guideline jest i tak z automatu weryfikowany narzędziem na CI który ściga mailami osoby commitujące coś niezgodnego z zasadami. Używanie Google C++ Style Guide ma dodatkową zaletę - u nas sprawdzanie części reguł musieliśmy zaimplementować sami, bo nie miały gotowej implementacji w używanym przez nas do walidacji narzędziu (Clang Static Analyzer, a wcześniej moje autorskie narzędzie w Javie). A np implementacje reguł z Google C++ Style Guide'a są dostępne otwartoźródłowo.

[Wonski]

Ale trzeba pamiętać że to kod przeznaczony głównie dla kompilatora i z konieczności bardzo, bardzo zoptymalizowany.

No ale w jaki sposób nieczytelne nazwy wpływają na wydajność?
Chodzi o to, ze dłuższa nazwa typu _jakis_tam_wskaznik jest gorsza od nazwy _ptr bo komputer potrzebuje więcej pamięci na jej przechowanie i w operacje na niej są bardziej złożone obliczeniowo?
Przecież nazwa to tylko alias a komputer posługuje się adresami, które zawsze maja taki sam rozmiar.
No chyba, ze ja tu czegoś nie rozumiem.

No i mimo wszystko to jednak kod bibliotek standardowych powinien być czytelny, by w razie problemow moznaby przeanalizować kod i zrozumieć jego działanie. Takie praktyki jak w visualu to stanowczo utrudniają.

[inż. Avallach]

Nie wpływają na wydajność, nie to miałem na myśli. Raczej chodzi o specyfikę niskopoziomowego kodu biblioteki standardowej, który do tego zazwyczaj używa featurów specyficznych dla danego kompilatora, sporej liczby ustawianych przez niego makr i zabezpieczonego przed "zepsuciem" makrami użytkownika, od kodu właściwych aplikacji.
Problem nieczytelnego kodu biblioteki standardowej ma nie tylko Microsoft - GCC też nie przoduje jeśli chodzi o czytelne konwencje:

Kod: [Zaznacz]

00080 #ifdef __GXX_EXPERIMENTAL_CXX0X__
00081       explicit
00082       vector(size_type __n)
00083       : _Base(__n), _M_guaranteed_capacity(__n) { }
00084
00085       vector(size_type __n, const _Tp& __value,
00086          const _Allocator& __a = _Allocator())
00087       : _Base(__n, __value, __a), _M_guaranteed_capacity(__n) { }
00088 #else
00089       explicit
00090       vector(size_type __n, const _Tp& __value = _Tp(),
00091          const _Allocator& __a = _Allocator())
00092       : _Base(__n, __value, __a), _M_guaranteed_capacity(__n) { }
00093 #endif
00094
00095       template<class _InputIterator>
00096         vector(_InputIterator __first, _InputIterator __last,
00097            const _Allocator& __a = _Allocator())
00098         : _Base(__gnu_debug::__base(__gnu_debug::__check_valid_range(__first,
00099                                      __last)),
00100         __gnu_debug::__base(__last), __a),
00101       _M_guaranteed_capacity(0)
00102         { _M_update_guaranteed_capacity(); }
00103
00104       vector(const vector& __x)
00105       : _Base(__x), _Safe_base(), _M_guaranteed_capacity(__x.size()) { }
W każdym razie - nie wydaje mi się to być godnym do naśladowania. Tutaj problem jest opisany szerzej:
http://stackoverflow.com/questions/4180166/why-is-the-code-in-most-stl-implementations-so-convoluted
http://stackoverflow.com/questions/13881915/why-does-the-stl-boost-c-coding-style-differ-so-much-from-everyone-elses
http://stackoverflow.com/questions/1460936/why-stl-implementation-is-so-unreadable-how-c-could-have-been-improved-here