Propozycja nazewnictwa i oznaczeń kodu w językach obiektowych
klops
ser...@gazeta.pl
hmm... parę uwag z mojej strony :D
wg mnie, zaproponowane nazewnictwo zmiennych, (przyrostki 'g-', 'm-', 'l-', 'a-', ...)
tylko zaciemniają obraz i napewno nie dążą do utworzenia prostego i przejrzystego kodu:
1) Istnieje dodatkowa praca przy wpisywaniu odpowiednich przyrostków.
2) Zastosowanie przyrostków zmniejsza potrzebę tworzenia unikalnych nazw,
co ułatwia powstawanie nieczytelnych 'potworków':
int changeValue(int aValue) {
int lValue = mValue;
mValue = aValue;
return lValue;
}
zamiast czytelniejszej wersji:
int changeValue(int newValue) {
int oldValue = value;
value = newValue;
return oldValue;
}
3) Rozumiem, że zastosowanie przyrostków ma ułatwić odgadnięcie rodzaju zmiennej po jej nazwie,
co ma zmniejszyć liczbę potencjalnych pomyłek w dużym kodzie. W małym kodzie natomiast nie
widać tego ułatwienia, gdyż na pierwszy rzut oka widać, czy zmienna jest zmienną lokalną, globalną,
parametrem funkcji czy też zmienną klasy.
Osobiście należę do szkoły w myśl której, programmy powinno się pisać jak najprościej (KISS)
w związku z tym podejrzliwie patrzę na wszystkie czynności, które zbytnio ułatwiają powstawanie
dużych i skomplikowanych porcji kodu.
4) Występowanie przyrostków nieznacznie, ale utrudnia refaktoring - przy zmianie rodzaju zmiennej
(np. zmienną globalną zamieniamy na zmienną klasy) musimy dodatkowo zmienić nazwę zmiennej.
Pozdr,
SD
klops
> On Mon, 13 Sep 2010 20:32:58 +0200
> klops<kl...@klopsserver.pl> wrote:
>
>> Nazewnictwo proste, logiczne i superskuteczne!!!
>> http://nazewnictwo.cba.pl/
>
> hmm... parę uwag z mojej strony :D
>
> wg mnie, zaproponowane nazewnictwo zmiennych, (przyrostki 'g-', 'm-', 'l-', 'a-', ...)
> tylko zaciemniają obraz i napewno nie dążą do utworzenia prostego i przejrzystego kodu:
Może nie doążą do prostego i przejrzystego kodu, ale czynią kod prostym
i przejrzystym
> 1) Istnieje dodatkowa praca przy wpisywaniu odpowiednich przyrostków.
Ale robota! Jeden dodatkowy znak i wciśnięcie klawisza Shift przy
pisaniu reszty nazwy zmiennej.
> 2) Zastosowanie przyrostków zmniejsza potrzebę tworzenia unikalnych nazw,
> co ułatwia powstawanie nieczytelnych 'potworków':
>
> int changeValue(int aValue) {
> int lValue = mValue;
> mValue = aValue;
> return lValue;
> }
Wg mnie to jest super czytelne i od razu widać co się dzieje. A jak
chcesz se dopisywać old i new to możesz zapisać:
int changeValue(int aNewValue) {
int lOldValue = mValue;
mValue = aNewValue;
return lOldValue;
}
Tle że dopisywanie new i old jest kosztowniejsze od pisania m, a, l.
> 3) Rozumiem, że zastosowanie przyrostków ma ułatwić odgadnięcie rodzaju zmiennej po jej nazwie,
> co ma zmniejszyć liczbę potencjalnych pomyłek w dużym kodzie. W małym kodzie natomiast nie
> widać tego ułatwienia, gdyż na pierwszy rzut oka widać, czy zmienna jest zmienną lokalną, globalną,
> parametrem funkcji czy też zmienną klasy.
Akurat! Szczególnie w programach Unixowych tego za cholerę nie widać!
> Osobiście należę do szkoły w myśl której, programmy powinno się pisać jak najprościej (KISS)
Właśnie proponowany sposób oznaczania kodu jest jak najbardziej KISS. A
z resztą te oznaczenia nie mają żadnego związku z architekturą programu
czyli nie wpływają na komplikacje, czyli nie są przeciw KISS!
> w związku z tym podejrzliwie patrzę na wszystkie czynności, które zbytnio ułatwiają powstawanie
> dużych i skomplikowanych porcji kodu.
Na obecnym etapie podejrzewam, że jeszcze nie jedno uproszczenie i
ułatwienie można będzie wymyśleć.
> 4) Występowanie przyrostków nieznacznie, ale utrudnia refaktoring - przy zmianie rodzaju zmiennej
> (np. zmienną globalną zamieniamy na zmienną klasy) musimy dodatkowo zmienić nazwę zmiennej.
To fajowe zminiać zmienne globalne na zmienne klasy! Znaczy, że ktoś nie
źle spaprał projekt. A naprawa tego musi kosztować - bez cuduw!
ser...@gazeta.pl
klops <kl...@klopsserver.pl> wrote:
> > wg mnie, zaproponowane nazewnictwo zmiennych, (przyrostki 'g-', 'm-', 'l-', 'a-', ...)
> > tylko zaciemniają obraz i napewno nie dążą do utworzenia prostego i przejrzystego kodu:
>
> Może nie doążą do prostego i przejrzystego kodu, ale czynią kod prostym
> i przejrzystym
>
> > 1) Istnieje dodatkowa praca przy wpisywaniu odpowiednich przyrostków.
>
> Ale robota! Jeden dodatkowy znak i wciśnięcie klawisza Shift przy
> pisaniu reszty nazwy zmiennej.
Niestety - jestem leniwy, i przyciskanie dodatkowo klawisza Shift, oraz wprowadzanie oznaczeń
znacznie odbiegających od języka potocznego ('aValue' jeszcze by przeszło, gorzej z 'gValue',
czy też 'mValue') spowalnia prędkość wklepywania kodu. Ale znów - to tylko moje osobiste
odczucie, i myślę, że po pewnym treningu takie przedroskti by nie przeszkadzały zbytnio.
Ale myślę, że zanim to nastąpi, to popełniłbym dużo pomyłek...
> > 2) Zastosowanie przyrostków zmniejsza potrzebę tworzenia unikalnych nazw,
>
> Wg mnie to jest super czytelne i od razu widać co się dzieje. A jak
> chcesz se dopisywać old i new to możesz zapisać:
> int changeValue(int aNewValue) {
> }
> Tle że dopisywanie new i old jest kosztowniejsze od pisania m, a, l.
Nie przeczę, że dopisywanie 'new' i 'old' nie jest kosztowniejsze. Chciałem tylko wykazać, że posiadając
już unikalne nazy (poprzez zastosowanie magicznych przyrostków) nie jesteśmy już zmuszani do tworzenia
sensowniejszych nazw.
> > 3) Rozumiem, że zastosowanie przyrostków ma ułatwić odgadnięcie rodzaju zmiennej po jej nazwie,
> > co ma zmniejszyć liczbę potencjalnych pomyłek w dużym kodzie. W małym kodzie natomiast nie
> > widać tego ułatwienia, gdyż na pierwszy rzut oka widać, czy zmienna jest zmienną lokalną, globalną,
> > parametrem funkcji czy też zmienną klasy.
>
> Akurat! Szczególnie w programach Unixowych tego za cholerę nie widać!
Tutaj się zgadzam - w większości programów Unixowych, głównie tych pisanych w C, takie oznaczenie
ułatiwłyby czytelność i zarządzalność kodem.
Ogólnie moje myśli krążyły wokół progarmowania obiektowego (dokładniej Java ;) ), a tutaj zmiennych
globalnych raczej się nie używa, najwyżej może być problem w rozróżnieniu zmiennych statycznych
od zmiennych klasy. Odróżnienie zmiennych lokalnych od zmiennych przekazanych w argumentach metody
nie jest problemem - metody na ogół są proste. W przypadku w którym metoda ma >100 linijek najpierw
zastanowiłbym się nad uproszczeniem jej, dopiero później wprowadzałbym ułatwiające oznaczenia.
>
> > Osobiście należę do szkoły w myśl której, programmy powinno się pisać jak najprościej (KISS)
>
> Właśnie proponowany sposób oznaczania kodu jest jak najbardziej KISS. A
> z resztą te oznaczenia nie mają żadnego związku z architekturą programu
> czyli nie wpływają na komplikacje, czyli nie są przeciw KISS!
w tym przypadku KISS ma u mnie szersze znaczenie - w miarę możliwości stosuję ją do każdej czynności
związanej z rozwojem oprogramowania: architektury, dokumentacji, formatowania kodu itd...
> > w związku z tym podejrzliwie patrzę na wszystkie czynności, które zbytnio ułatwiają powstawanie
> > dużych i skomplikowanych porcji kodu.
>
> Na obecnym etapie podejrzewam, że jeszcze nie jedno uproszczenie i
> ułatwienie można będzie wymyśleć.
Jestem za uproszczeniami. Tylko nie za bardzo w kierunku:
"... nazwy metod statycznych zaczynamy od przyrostka 's-', a nazwy metod privatnych od przyrostka 'p-'... "
... itd ;)
> > 4) Występowanie przyrostków nieznacznie, ale utrudnia refaktoring - przy zmianie rodzaju zmiennej
> > (np. zmienną globalną zamieniamy na zmienną klasy) musimy dodatkowo zmienić nazwę zmiennej.
> To fajowe zminiać zmienne globalne na zmienne klasy! Znaczy, że ktoś nie
> źle spaprał projekt. A naprawa tego musi kosztować - bez cuduw!
Niestety, patrząc z perspektywy mojego doświadczenia, spapranych kodów jest zbyt dużo.
Podsumowując, Twoja propozycja nie jest zła: napewno się sprawdza w niektórych zastosowania.
Podobie jak notacja węgierska, jest jednak nieprzydatna kiedy stosuje się ułatwiające życie edytory.
Nasuwa mi się jeden wniosek: nie ma uniwersalnej notacji. Używana notacja zależy w dużej mierze od
wykorzystywanego języka programowania, narzędzi a także osób uczestniczących w projekcie (.. itd).
Pozdr,
SD
Daniel Mróz
>> Nazewnictwo proste, logiczne i superskuteczne!!!
>> http://nazewnictwo.cba.pl/
że powyższa propozycja nie jest niczym nowym. To jest zmodyfikowana
Notacja Węgierska (http://pl.wikipedia.org/wiki/Notacja_w%C4%99gierska)
i AFAIR nie przyjęła się ona bardzo dawno temu, właśnie ze względu
na "zaciemnianie".
Nie ma chyba sensu wynajdywać koła na nowo.
Pozdrawiam
Beorn
--
Daniel 'Beorn' Mróz <be...@alpha.pl> http://127.0.0.1/beorn
[GIT d s:- a-@ C++++ UL++++$ P+ L++++ E--- W+ N+++ o? K- w---]
[O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*]
[ r++ y+ ]