🚀 go-pugleaf

On Wed, 22 Sep 2010 08:03:44 +0200
klops <klops@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