standaryzacja nazw, notacji

Witam, w kazdym jezyku jest jakas notacja standardowa, czy to wegierska czy to javowa (jak to nazwac?)
No i ja rowniez jak sobie tworze jakies klasy to zwykle ich obiekty zaczynam m_xxObiekt gdzie xx powinien mi mowic mniej wiecej co to za klasa.
Na necie jest wiele przydatnych mniej lub bardzidj znanych klas, komponentow tworzonych przez ludzi.
Nie myslicie ze dobrze by byo gdyby piszacy tkie klasy, i chcacy je udostepniac szerzej powinni sugerowac standard notaji podczas uzywania tejze klasy??

No bo np.: ja w swoich programach np.: pdnosze sie do klasy CPerson poprezz powiedzmy m_psOsoba, ale ktos inny w jakims projekcie zrobi inaczej, i dobreze by bylo zeby jak ktos udostepnil klase CPerson to zeby nakierowal wszystkich na uzywaie takiej samej notacji, wtedy troszke ulatwiloby to przeladanie cudzych kodow.
Albo Wy jakie macie spostrzezenia na ten temat? Bo moze bzdury gadam.

Znalazłem fajną klasę A, używającą notacji B, którą chciałbym użyć w projekcie.
Inna klasa, do innego zastosowania C, znaleziona w sieci, używa notacji D.
Czy swój projekt, wykorzystujący klasy A i C pisać w notacji B czy D? A może nie przerabiać już napisanego w 50% swojego projektu w notacji E?

Chyba rozumiesz o co mi chodzi :)

Kazdy ma swoj styl i swoje upodobania. I pÓÓÓÓki nie ma jakiegos przymusu czy wymogu to kazdy pisze jak chce. Ale profesjonalny kod od razu mozna poznac.

Ja próbuje pisać coraz "profesjonalniej" tylko jak to robić?

int Liczba;

Wystarczy czy powinno to wyglądąć:

int i_Liczba;

Czy jeszcze inne filozofie macie? :)
Skąd się uczyć jak pisać kod? Gdzie można znaleźć jakieś źródło idealne? Z chęcią się zapoznam. Szczególnie mnie interesuje c++.

Ja próbuje pisać coraz "profesjonalniej" tylko jak to robić?

int Liczba;

Wystarczy czy powinno to wyglądąć:

int i_Liczba;

Szukasz tego "profesjonalizmu" nie tam gdzie trzeba :) Pisz po prostu tak, zeby inna osoba wiedziala co jest do czego i tyle.

Dryobates: nie chodzi mi o takie zagmatwanie ;)
Piszesz klase powiedzm CHtmlParser
i sugerujesz zeby ludzie uzywali skrotu do niej : hp
a czy to bedzie m_hpStrona , hpStrona, l_hpStrona , hp_Strona to juz ich sprawa.

markoot napisał(a)

Dryobates: nie chodzi mi o takie zagmatwanie ;)
Piszesz klase powiedzm CHtmlParser
i sugerujesz zeby ludzie uzywali skrotu do niej : hp
a czy to bedzie m_hpStrona , hpStrona, l_hpStrona , hp_Strona to juz ich sprawa.

Myślę, że takie sugestie powinny być na zasadzie przykładów.
Tzn. tworząc dokumentację, pisać należy przykłady użycia kodu i tam stosować "sugerowaną" składnię. Wówczas nie ma uczucia, że ktoś "zmusza" nas do tego, a jedynie przyzwyczajamy użytkownika (jak zacznie od metody kopiuj - wklej).

W ogóle jestem zwolennikiem umieszczania krótkich przykładów w ilości możliwie największej jak się da :)

Ja staram sie zawsze stosowac czytelna notacje, nawet kosztem dluzszego pisania nazw klasy/zmiennej czy klasy. Zauwazylem jednak ze stosuje rozna notacje w zaleznosci od technologii jakiej uzywam.

Przykladowo w Delphi jest to styl wielbladzi, nie stosuje notacji wegierskiej. Oczywiscie obowiazkowo nazwy klas od litery 'T' ;) Natomiast w PHP wszystko malymi literami (rowniez nazwy klas), brak stylu wielbladziego - np. $my_login zamiast $MyLogin. W CSS roznie, bo raz wielbladzi, raz z uzyciem _ zawsze zaczynam nazwe selektora od malej litery ;)

W C# podobnie jak w Delphi, tyle ze oczywiscie z pominieciem "T" na poczatku nazwy. Takie sytuacje mozna by mnozyc :)

Ogolnie mysle ze to wynika z ogolnie przyjetych standardow. No, moze zle sie wyrazilem... np. w PHP taki sytl przyjelem na poczatku nauki.

Poza tym najważniejsza rzecz to to, żeby być wiernym swojemu stylowi - nie pisać w jednym projekcie tak, a w innym siak, albo, co gorsza, w różnych fragmentach tego samego projektu stosować różne sposoby pisania (oczywiście nie dotyczy to modułów autorstwa kogoś innego bądź np. napisanych przy okazji innego projektu).

Jeżeli chodzi o Delphi to umownie wszystkie zmienne prywatne (inaczej pola klasy, fields) rozpoczyna się od litery F. Tak samo jak setter'y rozpoczyna się od Set, a getter'y od Get (zachowując oczywiście styl wielbłądzi).

Eric Gunnerson w swojej książce o C# zwraca uwage ze w tym języku dobrym zwyczajem jest

• stylem PascalCasing nazywać wszystko co bedzie widoczne z zewnątrz klasy (np. klasy, wyliczenia, metody) a parametry metod stylem camelCasing (czyli jak to mówi Adam "wielbłądzim")
• prywatne składowe metodą camelCasing
• klasy zdarzeń powinny kończyc sie słowem "EventArgs", klasy wyjątków "Exception", klasy atrybutów "Attribute"
• nazwy interfejsów zaczynać wielką literą I
• nie zaleca się stosowania notacji węgierskiej bo w C# ważniejsza jest czytelność kodu, a nie informacja o typach

brodny napisał(a)

Poza tym najważniejsza rzecz to to, żeby być wiernym swojemu stylowi - nie pisać w jednym projekcie tak, a w innym siak

Polemizowałbym. Ja podobnie jak Adam dostosowuję notację do:

1. Zespołu w jakim pracuję
2. Języka jaki stosuję

Punkt pierwszy jest oczywisty. Aby nie wyszedł miks niezdatny do czytania.
Co do drugiego, powód jest podobny. Śmiesznie wygląda kod paskalowy w c, kod c w javie, kod javy w pythonie, a czasem wprost nie jest możliwe zastosowanie 'swojego' stylu (spróbuj pisać zmienne z małej litery z prologu ;) ).

Fakt, nie dopowiedziałem. Miałem na myśli, żeby 2 te same projekty pisane w tym samym języku nie różniły się zbytnio, jeśli chodzi o styl kodowania. A co do programowania w grupie to to już zupełnie inna bajka, nie jesteśmy sami, więc dostosowujemy się do założeń przyjętych przez cały zespół. W każdym razie ważna jest konsekwencja :)