O tym jak nazywać zmienne.

Ogólnie mówiąc: odpowiedzialność WikiPage zależy od tego, czym dokładnie zarządza

Czyli nazwa jest niejednoznaczna, więc nazwa jest zła;)

Tak jak już to podkreślił @Alueril, post był konkretnie o notacji węgierskiej i innych konwencji nie skreślam. Ba, napisałem nawet, by mieć dokładnie jedną konwencję w całym projekcie i jej się trzymać

Chciałbym zauważyć, że nie negujesz tylko notacji węgierskiej, ale przy okazji również stwierdziłeś, że prefiksy są bezsensowne:

Chcąc skorzystać z podpowiadania nazwy zmiennej nie ma sensu wpisywać zbędnych prefiksów i kilka kolejnych znaków, by uniknąć długich list z kandydatami (np. po wpisaniu samego m_).

Ja nie uważam, że prefiksy są bezsensowne i sądzę, że więcej osób ma podobne zdanie do mojego.

/edit:

Ogólnie rzecz biorąc, jak napisałem na początku postu, nie wszyscy muszą zgodzić się ze wszystkimi radami, które zostały w tym poście zawarte. Posiadam relatywnie mało doświadczenia i cały czas się uczę. Poza tym kwestia nazewnictwa jest zależna w dużym stopniu od programisty, a każdy ma swoje ulubione konwencje, co z resztą @Alueril już zaznaczył podając przykłady :)

Nie sądzę, aby pod kątem 'dobrych porad' stosownym było przemycanie stwierdzeń, że 'coś jest bezsensu' skoro jest to stosowane w milionach projektów.

Jeśli mnie pamięć nie myli, to te książki nie uczą programowania od zera, a są dedykowane osobom, które te wiedzę posiadają

Pierwsza omawia wszystkie tematy od właściwie od zera a druga jest kierowana dla osób całkowicie zielonych.

Mieszasz konteksty.

Nie mieszam. Kod nie zawsze się czyta w IDE, więc nie można użyć argumentu, że notacja węgierska jest zła bo ma się IDE. Każdy patch czy większość wysłanych codereview zawiera tylko fragmentu kodu.

a przynajmniej roztropniejsi tak robią

Jeżeli się da to jest fajnie :) W poprzedniej pracy praca z IDE była uciążliwa. Kod się indeksował źle, makra źle rozwijały, typy źle rozwijały w IDE. Owszem, była to kwestia złego zarządzania kodem ale sytuacja była odziedziczona po pewnej Szwedzkiej firmie, gdzie większość projektów tak wygląda. Dlatego dużo ludzi wolało vima.

Przeczytałeś to, co było pod zacytowanym przez Ciebie nagłówkiem [...]

Generalnie chodziło mi o to, że było brak kontekstu rozmiaru zmiennych względem dostępności tej zmiennej w kodzie. Najkrótsza dobrze opisana nazwa nie musi być idealna dla zmiennej globalnej bo będzie łatwo przypadkiem ją przesłonić.

Jednak generalnie prawie każdy z tych tematów jest kontrowersyjny mniej lub bardziej, autor książki Kod Doskonały porównuje te kwestie (razem z formatowaniem kodu i stosowaniem goto) do wojen religijnych :)

W LLVM i w większości boosta z kolei nie ma żadnych takich ozdobników. W przypadku C++ nie ma sensu wysuwać żadnych wniosków na podstawie jednego codebase, bo w przeciwieństwie do praktycznie każdego innego mainstreamowego języka nie ma żadnej pojedynczej konwencji i każdy pisze, jak chce.

Boost to de-facto duży zbiór szablonów i innych bardziej lub mniej użytecznych klas. Jakoś na przestrzeni lat nie zauważyłem, aby boost był chętnie używaną biblioteką przez deweloperów. Boost był przez moment 'fajny' dostarczając funkcjonalności, które bardzo się przydawały przy wytwarzaniu oprogramowania i nie było ich w standardzie C++. Teraz w standardzie mamy sekcje krytyczne, wątki i inteligentne wskaźniki, więc deweloperzy raczej nie chcą wciągać przeszło 100MB kodu źródłowego do projektu tylko po to, aby ewentualnie użyć jednego czy dwóch prostych narzędzi, które w tej bibliotece można znaleźć (w końcu po co zaśmiecać intellisense całą masą symboli, które się wciągną przy dołączaniu jednego pliku nagłówkowego).

W LLVM i w większości boosta z kolei nie ma żadnych takich ozdobników.

A z tego stwierdzenia wynika, że każdy pisze kod jak mu się podoba i w zasadzie jak się pojawi kolejna osoba z jakąś biblioteką dla boosta to równie dobrze może użyć kolejnej wydumanej konwencji. Tym samym z tego wynika, że projekt jest źle zarządzany skoro nie ma jednego, spójnego standardu.

A co do pisania 'this' aby wyróżnić, że zmienna należy do klasy to sądzę, że prędzej zrobi się burdel w kodzie i każdy będzie pisał jak mu wygodniej (to po pierwsze), a po drugie zamiast krótkiego prefiksu np. m_XYZ robi się zmienna o nazwie this->XYZ, czyli idea skracania zapisu skończyła się jego istotnym wydłużeniem. Prefiksy czy też sufiksy mają swoje zalety, więc nie negowałbym ich istnienia w żadnym wypadku, a treść tego artykułu właśnie to sugeruje.