notacja węgierska - pałna lista zasad.
Karol
używania Notacji Węgierskiej. Może na msdn?
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Marcin 'Qrczak' Kowalczyk
> Gdzie mogę znaleźć pełną (najpowszechniej używaną) listę zasad
> używania Notacji Węgierskiej. Może na msdn?
Zasada nr 1: nie stosować notacji węgierskiej.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Tomek
> Dnia 02-02-2007, pią o godzinie 12:36 +0000, Karol napisał(a):
>
>> Gdzie mogę znaleźć pełną (najpowszechniej używaną) listę zasad
>> używania Notacji Węgierskiej. Może na msdn?
>
> Zasada nr 1: nie stosować notacji węgierskiej.
>
Karol
> > Zasada nr 1: nie stosowaÄ notacji wÄ gierskiej.
> >
> Zasada nr 2: w razie problemĂłw patrz punkt 1 :D
Bardzo zabawne, możesz sobie nie stosować jak programujesz
kilku linijkowe programy typu
printf("hello, world");
Twoja Zadadą nr 3 powinna brzmieć: jak nie masz nic mądrego do powiedzenia
nie odzywaj się.
Sławomir Szczyrba
>> > Zasada nr 1: nie stosowaÄ notacji wÄ gierskiej.
>> Zasada nr 2: w razie problemĂłw patrz punkt 1 :D
> Bardzo zabawne, możesz sobie nie stosować jak programujesz
> kilku linijkowe programy typu
> printf("hello, world");
> Twoja Zadadą nr 3 powinna brzmieć: jak nie masz nic mądrego do powiedzenia
> nie odzywaj się.
>
Sławek
--
________
_/ __/ __/ BOFH excuse 258: That's easy to fix, but I can't be bothered.
\__ \__ \_______________________________________________________________
/___/___/ Sławomir Szczyrba steev/AT/hot\dot\pl
Marcin Gil
> Gdzie mogę znaleźć pełną (najpowszechniej używaną) listę zasad
> używania Notacji Węgierskiej. Może na msdn?
>
http://en.wikipedia.org/wiki/Hungarian_notation
i zerknij na linki na dole.
A w ten sposób znajdiesz choćby to:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/html/hunganotat.asp
-Marcin
Paweł Kierski
> Tomek <tomasz...@vp.pl> napisał(a):
>
> > > Zasada nr 1: nie stosowaÄ? notacji wÄ?gierskiej.
> > >
> > Zasada nr 2: w razie problemĂłw patrz punkt 1 :D
>
> Bardzo zabawne, możesz sobie nie stosować jak programujesz
> kilku linijkowe programy typu
> printf("hello, world");
Pokaż w takim razie sytuacje w większym programie, gdzie bez notacji
węgierskiej trudno się obyć.
--
Paweł Kierski
ne...@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
JimVonMoon
<karol120...@gazeta.pl> wrote:
>Bardzo zabawne, możesz sobie nie stosować jak programujesz
>kilku linijkowe programy typu
>printf("hello, world");
To w sumie ironia, bo gdybys kiedys napisal cokolwiek bardziej
zlozonego to wiedzialbys dlaczego nie powinno sie stosowac notacji
wegierskiej i pochodnych. Szczegolnie w dobie IDE, w ktorych wystarczy
najechac kursorem na zmienna i juz wiesz jakiego jest typu.
--
Jakub Nowakowski
http://www.jimvonmoon.net/ - my site.
http://rss.jimvonmoon.net/ - free RSS via WAP reader.
Marcin 'Qrczak' Kowalczyk
> Bardzo zabawne, możesz sobie nie stosować jak programujesz
> kilku linijkowe programy
http://msdn2.microsoft.com/en-us/library/ms229045.aspx
JimVonMoon
<qrc...@knm.org.pl> wrote:
>http://msdn2.microsoft.com/en-us/library/ms229045.aspx
"Do not use Hungarian notation."
Hehe, niezle - czy to nie czasem w MS wymyslono notacje wegierska?
Chyba sie w koncu wycofali ze swojego wynalazku. :-)
Jakub Lisowski
w <epvd54$oj3$1...@inews.gazeta.pl> napisał:
> Tomek <tomasz...@vp.pl> napisał(a):
>
>> > Zasada nr 1: nie stosowaÄ notacji wÄ gierskiej.
>> >
>> Zasada nr 2: w razie problemĂłw patrz punkt 1 :D
>
> Bardzo zabawne, możesz sobie nie stosować jak programujesz
> kilku linijkowe programy typu
> printf("hello, world");
> Twoja Zadadą nr 3 powinna brzmieć: jak nie masz nic mądrego do powiedzenia
> nie odzywaj się.
ROTFL.
Znasz może jakieś zalety notacji węgierskiej że jej tak bronisz?
ja czyli jakub
--
Z zaparkowanego Forda Fulkersona wysiedli generał Grant i porucznik
Revoke.
Jedrzej Dudkiewicz
> >kilku linijkowe programy typu
> >printf("hello, world");
>
> To w sumie ironia, bo gdybys kiedys napisal cokolwiek bardziej
> zlozonego to wiedzialbys dlaczego nie powinno sie stosowac notacji
> wegierskiej i pochodnych. Szczegolnie w dobie IDE, w ktorych wystarczy
> najechac kursorem na zmienna i juz wiesz jakiego jest typu.
Przypominam, że założeniem notacji węgierskiej nie jest oznaczanie typu,
tylko przeznaczenia. Wiesz, "system jest dobry, tylko wypaczenia są złe".
JD
JimVonMoon
<jedrzej.d...@poczta.interia.pl> wrote:
>Przypominam, że założeniem notacji węgierskiej nie jest oznaczanie typu,
>tylko przeznaczenia. Wiesz, "system jest dobry, tylko wypaczenia są złe".
Chyba nie do konca rozumiem.
Powiedzmy, ze mamy zmienna "szTitle" (czyli zero-terminated string
zawierajacy jakis tytul). Co tu swiadczy o przeznaczeniu? Bo "sz" to
jest okreslenie typu, a o przeznaczeniu wg mnie swiadczy tu tylko
"Title" (ale to juz nie jest element zadnej notacji).
A jesli to jest wlasnie to wypaczenie to jak wyglada przyklad
niewypaczony? :-)
Sam uzywam "pPointer" i "m_member", ale zasady notacji wegierskiej co
najmniej utrudniaja pielegnacje kodu.
d d
> >http://msdn2.microsoft.com/en-us/library/ms229045.aspx
>
> "Do not use Hungarian notation."
> Hehe, niezle - czy to nie czasem w MS wymyslono notacje wegierska?
> Chyba sie w koncu wycofali ze swojego wynalazku. :-)
>
Javie ) i nie ma tak wielu typow pochodnych. Ale ja w C++ z chęcią stosuję
uproszczoną wersję tj. n-number, sz-string, p-pointer, i kilka innych.
Ścislych regul nie da się chyba opracować, a w każdym razie prowadzilo by to
do jakis strasznych koszmarkow.
Jedrzej Dudkiewicz
> >tylko przeznaczenia. Wiesz, "system jest dobry, tylko wypaczenia są złe".
>
> Chyba nie do konca rozumiem.
> Powiedzmy, ze mamy zmienna "szTitle" (czyli zero-terminated string
> zawierajacy jakis tytul). Co tu swiadczy o przeznaczeniu?
Nic :) To świadczy tylko o tym, że to co bierzesz za "notację węgierską",
jest bastardyzacją tzw. "właściwej notacji węgierskiej." Przeczytałem
dokument Simonyia
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/ht
ml/hunganotat.asp) jakiś czas temu i dopiero wtedy zrozumiałem rozziew
między teorią notacji a praktycznym wykorzystaniem. Tam są trzy tabele:
Table 1. Some examples for procedure names
Table 2. Standard type constructions
Table 3. Standard qualifiers
Table 4. Some common primitive types
Obecnie używana notacja węgierska to tylko ostatnia, czwarta tabela. I taka
notacja jest, oczywiście, nic nie warta. W szczególności pisanie:
class SomeClass;
SomeClass oSomeClassInstance;
gdzie "o" oznacza "object" "no bo jak miałem to nazwać, iosc, jak instance
of some class?", jest bez sensu.
Dalej - w jednym z mini-projektów zastosowałem notację węgierską, w C, i
sprawdziła się raczej dobrze. Nie był to żaden silver bullet, ale dało mi
to:
a) asumpt do zastanowienia się nad stylem
b) jaki taki pogląd na notację węgierską
c) przekonanie, że używana w większości projektów notacja węgierska jest
notacją węgierskawą
Co nie znaczy, że namawiam do stosowania tejże albo jestem gotowy wbijać się
we flame, czy warto ją stosować czy nie.
JD
Sebastian Kaliszewski
> On Fri, 2 Feb 2007 15:27:51 +0100, "Jedrzej Dudkiewicz"
> <jedrzej.d...@poczta.interia.pl> wrote:
>
>
>>Przypominam, że założeniem notacji węgierskiej nie jest oznaczanie typu,
>>tylko przeznaczenia. Wiesz, "system jest dobry, tylko wypaczenia są złe".
>
>
> Chyba nie do konca rozumiem.
> Powiedzmy, ze mamy zmienna "szTitle" (czyli zero-terminated string
> zawierajacy jakis tytul). Co tu swiadczy o przeznaczeniu?
To jest własnie wypaczenie.
> Bo "sz" to
> jest okreslenie typu, a o przeznaczeniu wg mnie swiadczy tu tylko
> "Title" (ale to juz nie jest element zadnej notacji).
> A jesli to jest wlasnie to wypaczenie to jak wyglada przyklad
> niewypaczony? :-)
Polecam:
http://www.joelonsoftware.com/articles/Wrong.html
pzdr
\SK
JimVonMoon
<s...@get.it.off.to.reply.z.pl> wrote:
>Polecam:
>http://www.joelonsoftware.com/articles/Wrong.html
Uf, przeczytalem.
Faktycznie - o ile w C i jezykach bez porzadnej kontroli typow taka
notacja moze sie przydac (o ile opisuje logike, a nie typy) to w
C++/C#/Java i innych jezykach z porzadnym, statycznym systemem typow
nie widze powodu do takiego zasmiecania nazw zmiennych.
Wezmy ten przyklad z artukulu - ten z tym safe i unsafe stringiem
wysylanym do przegladarki. W porzadnym jezyku moge sobie stworzyc
poprostu typy SafeString i UnsafeString (implementacja moze byc ta
sama - chodzi o odrebnosc typow), odpowiednio zdefiniowac operatory <<
dla strumienia wyjsciowego (tak zeby ten dla UnsafeString np. rzucal
assert, wyjatek albo byl prywatny) i mam porzadnie zapewnione
bezpieczenstwo, a nie jakies szmanskie mumbo-jumbo polegajace na
nazywaniu zmiennych. Argument, ze "moje oczy naucza sie rozpoznawac po
paru tygodniach pisania miejsca, w ktorych sa bledy" to brzmi
smiesznie. W koncu podczas pisania moge miec gorszy dzien i cos
zapomniec/przeoczyc, a nowy programista przez pierwsze tygodnie bedzie
pisal bledny i niezgodny z konwencja kod. Takie cos mija sie z celem
gdy moge zapewnic sobie bezpieczenstwo gwarantowane przez kompilator
albo zmusic bledy do ujawniania sie od razu podczas testow programu.
Jarosław Staniek
> Dnia 02-02-2007, pią o godzinie 12:36 +0000, Karol napisał(a):
>
>> Gdzie mogę znaleźć pełną (najpowszechniej używaną) listę zasad
>> używania Notacji Węgierskiej. Może na msdn?
>
> Zasada nr 1: nie stosować notacji węgierskiej.
Popieram. Skupiając się na OOP, podam konkretny przykład: np. w projektach
takich jak KDE (to nie jest parę linii [1]) stosuje się prawie wyłącznie
prefiks m_ dla danych skłądowych, ewentualnie p_ dla prywatnych. Z rzadka
argumenty metody mają prefix 'a' aby uniknąć konfliktu z tak samo nazwaną daną
składową.
Coraz częściej zbyt dużą liczbę zmiennych dostępnych w danym bloku
kodu/definicji klasy skutecznie ogranicza się przez stosowanie przestrzeni
nazw oraz d-pointerów [2]. W najnowszej iteracji (Qt4/KDE4) doszło zalecenie
by mocno ograniczać liczbę argumentów (w tym opcjonalnych) w metodach klas, a
szczególnie w konstruktorach. To w pewnym stopniu dodatkowo eliminuje problem
ze zbyt dużą liczbą nazw.
Sama potrzeba przypomnienia sobie do czego zmienna/stała służy i jak wygląda
deklaracja zmiennej mnie niepokoi: sugeruje m.in. że
- jest zadeklarowana globalnie (sic!), albo
- kod nie jest nawet napisany strukturalnie i np. jej deklaracja znajduje się
tysiące linni wyżej...
[1] http://www.ohloh.net/projects/272
[2] http://en.wikipedia.org/wiki/Opaque_pointer
--
regards / pozdrawiam, Jaroslaw Staniek
Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org
d d
> On Fri, 2 Feb 2007 15:27:51 +0100, "Jedrzej Dudkiewicz"
> <jedrzej.d...@poczta.interia.pl> wrote:
>
> >Przypominam, że założeniem notacji węgierskiej nie jest oznaczanie typu,
> >tylko przeznaczenia. Wiesz, "system jest dobry, tylko wypaczenia są złe".
>
> Chyba nie do konca rozumiem.
> Powiedzmy, ze mamy zmienna "szTitle" (czyli zero-terminated string
> zawierajacy jakis tytul). Co tu swiadczy o przeznaczeniu? Bo "sz" to
> jest okreslenie typu, a o przeznaczeniu wg mnie swiadczy tu tylko
> "Title" (ale to juz nie jest element zadnej notacji).
> A jesli to jest wlasnie to wypaczenie to jak wyglada przyklad
> niewypaczony? :-)
> Sam uzywam "pPointer" i "m_member", ale zasady notacji wegierskiej co
> najmniej utrudniaja pielegnacje kodu.
>
Byłbyś zdziwiony, gdyby się okazało, że Title to jest np. obiekt klasy
DOMElement, CSSStyle lub zwykła liczba ...
Bronek Kozicki
> Dalej - w jednym z mini-projektów zastosowałem notację węgierską, w C, i
> sprawdziła się raczej dobrze. Nie był to żaden silver bullet, ale dało mi
"w C" - to tłumaczy wszystko. Notacja węgierska jest protezą na brak
statycznego bezpieczeństwa typów.
B.
--
Remove -trap- when replying. Usun -trap- gdy odpisujesz.
JimVonMoon
<adam_mic...@gazeta.pl> wrote:
>Byłbyś zdziwiony, gdyby się okazało, że Title to jest np. obiekt klasy
>DOMElement, CSSStyle lub zwykła liczba ...
Nie ukrywam, ze gdyby Title bylo liczba to bym sie zdziwil. :-]
BobyX
>> Zasada nr 1: nie stosować notacji węgierskiej.
>Popieram. Skupiając się na OOP, podam konkretny przykład: np. w projektach
>takich jak KDE (to nie jest parę linii [1]) stosuje się prawie wyłącznie
>prefiks m_ dla danych skłądowych, ewentualnie p_ dla prywatnych. Z rzadka
>argumenty metody mają prefix 'a' aby uniknąć konfliktu z tak samo nazwaną
>daną składową.
Z konfliktem pomiędzy nazwą argumentu i składowej można sobie poradzić bez
tego:
class A {
private:
int x;
public:
A(int x) : x(x) { }
A(int x, bool) {
this->x = x;
}
}
A co do prefixowania składowych to lepiej m_ niż samo _, co jest zastrzeżone
dla bibliotek... Podkreślenie na końcu IMHO wygląda zgrabniej, ale gorzej
sprawdza się w kontekstowych podpowiadaczach składni gdzie poza składowymi
pojawiają się nazwy typów widoczne w bieżącym scope...
Pozdrawiam,
BX
Maciej Pilichowski
<qrc...@knm.org.pl> wrote:
>Dnia 02-02-2007, pią o godzinie 12:36 +0000, Karol napisał(a):
>
>> Gdzie mogę znaleźć pełną (najpowszechniej używaną) listę zasad
>> używania Notacji Węgierskiej. Może na msdn?
>
>Zasada nr 1: nie stosować notacji węgierskiej.
Czemu i ktorej notacji wegierskiej? Oryginalnej, czy tej wypaczonej
(m.in. przez MS)?
milego dnia, hej
--
Maciej "MACiAS" Pilichowski http://bantu.fm.interia.pl/
Sektor van Skijlen
> JimVonMoon <nom...@devnull.com> napisał(a):
Nie zdziwiłbym się. Albo wiem, co to oznacza, albo bez większego problemu
(dowolny w miarę nowoczesny edytor programisty) znalazłbym sobie definicję.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethouris(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"
Sebastian Kaliszewski
>>Polecam:
>>http://www.joelonsoftware.com/articles/Wrong.html
>
>
> Uf, przeczytalem.
> Faktycznie - o ile w C i jezykach bez porzadnej kontroli typow taka
> notacja moze sie przydac (o ile opisuje logike, a nie typy) to w
> C++/C#/Java i innych jezykach z porzadnym, statycznym systemem typow
> nie widze powodu do takiego zasmiecania nazw zmiennych.
W Javie nie będziesz miał operatorów -- kod bezpieczny będzie kiepsko
czytelny. Tak więc Javę możesz od razu skreślić.
W pozostałych też nie jest aż tak lekko, patrz niżej...
> Wezmy ten przyklad z artukulu - ten z tym safe i unsafe stringiem
> wysylanym do przegladarki. W porzadnym jezyku moge sobie stworzyc
> poprostu typy SafeString i UnsafeString (implementacja moze byc ta
> sama - chodzi o odrebnosc typow), odpowiednio zdefiniowac operatory <<
> dla strumienia wyjsciowego (tak zeby ten dla UnsafeString np. rzucal
> assert, wyjatek albo byl prywatny)
A co jak operatorów masz więcej? Nie ma lekko -- pisanie wszystkiego z palca
zapewnia szybkie spuchnięcie kodu ponad miarę.
Weź sobie sytuację typu edytor wysiwyg (nawet prosty).
masz:
pozycja x w oknie
pozycja y w oknie
pozycja x względem początku tekstu
pozycja y względem początku tekstu
szerokosć w pixelach
wysokość w pixelach
nr wiersza
nr znaku w wierszu
nr znaku w tekscie
długość napisu w tekscie (w znakach)
pozycja x w tekscie, w punktahc drukarskich
pozycja y w tekscie, w punktahc drukarskich
szerokość w punktach drukarskich
wysokość w punktach drukarskich
itd.
Teraz podefiniuj wszystkie operatory jak należy -- żeby było bezpiecznie.
Rozsądnym wyjściem może być wtedy generator kodu, np. jaki popełnił Maciek
Sobczak.
http://msobczak.com/prog/typegen/
Ale to nie koniec!
Pozsostaje kwestia całego otoczenia (bibliotek, itd), które spodziewa się
typów znanych i lubianych ale nic nie mówiących:
string, int, double, itd...
No bo jakaś tam np. biblioteka okienkowa spodziewa się typów standardowych
(oby!) a nie twoich WindowXPixelPosition...
Można więc zrobić jawne konwertery -- ale wtedy jesteśmy w punkcie wyjścia
-- wizualna inspekcja :)
pzdr
--
Sebastian Kaliszewski
Sebastian Kaliszewski
>>>http://msdn2.microsoft.com/en-us/library/ms229045.aspx
>>
>>"Do not use Hungarian notation."
>>Hehe, niezle - czy to nie czasem w MS wymyslono notacje wegierska?
>>Chyba sie w koncu wycofali ze swojego wynalazku. :-)
>>
>
> To się tyczy .Net, gdzie kontrola typów nie jest już tak ważna ( tak samo w
> Javie ) i nie ma tak wielu typow pochodnych.
Huh???
> Ale ja w C++ z chęcią stosuję
> uproszczoną wersję tj. n-number, sz-string, p-pointer, i kilka innych.
> Ścislych regul nie da się chyba opracować, a w każdym razie prowadzilo by to
> do jakis strasznych koszmarkow.
Ale to akurat załatwie sensowny edytor. Jeśli już koniecznie notacja
węgierska, to ta prawdziwa a nie herezje -- w nazwie zakodowane jest
znaczenie logiczne wartości.
pzdr
\SK
JimVonMoon
<s...@get.it.off.to.reply.z.pl> wrote:
>W Javie nie będziesz miał operatorów -- kod bezpieczny będzie kiepsko
>czytelny. Tak więc Javę możesz od razu skreślić.
Bez operatorow tez sie da. Akurat przeciazenie operatora to byl tylko
przyklad. W Jave mogloby byc.
output.println(safeString); // ok
output.println(unsafeString); // rzuci wyjatek lub jest private
Jak na moj gust wyglada to niezle.
>A co jak operatorów masz więcej? Nie ma lekko -- pisanie wszystkiego z palca
>zapewnia szybkie spuchnięcie kodu ponad miarę.
>
>Weź sobie sytuację typu edytor wysiwyg (nawet prosty).
>
>masz:
> pozycja x w oknie
> pozycja y w oknież
> [ciach]
Tutaj akcesory beda znacznie bardziej eleganckie od operatorow.
Argumentu o spuchnieciu kodu nie rozumiem bo i tak musze jakos te
atrybuty poustawiac - czy przez operatory, czy przez akcesory, czy
jeszcze jakos inaczej - to nie ma znaczenia bo i tak trzeba odpowiedni
kod napisac. No chyba, ze ktos zadeklaruje te atrybuty jako publiczne,
ale to juz jego sprawa. ;-)
>Rozsądnym wyjściem może być wtedy generator kodu, np. jaki popełnił Maciek
>Sobczak.
>
> http://msobczak.com/prog/typegen/
Jeszcze nie znam, ale zapowiada sie niezle. :-)
>Ale to nie koniec!
>
>Pozsostaje kwestia całego otoczenia (bibliotek, itd), które spodziewa się
>typów znanych i lubianych ale nic nie mówiących:
> string, int, double, itd...
>No bo jakaś tam np. biblioteka okienkowa spodziewa się typów standardowych
>(oby!) a nie twoich WindowXPixelPosition...
No coz, cudow nie ma i na pewno zawsze znajda sie mniej bezpieczne
punkty styku miedzy roznymi modulami i przed tym nie zabezpieczy zadna
notacja. W koncu cudza biblioteka moze posiadac swoja notacje (oby
nie!), ktora nie musi byc zgodna z nasza.
Zreszta zmodyfikujmy troche ten przyklad z artykulu. Uzywamy
zewnetrznej biblioteki CGI - do wypisywania tekstu sluzy nam
Output::print(string). Metoda print przyjmuje jakis standardowy
string. Udowodnij mi przewage tego:
string usText;
Output::print(usText); // blad; wyjdzie podczas zmudnej inspekcji
nad tym:
UnsafeString text;
Output::print(text); // blad; wyjdzie od razu podczas kompilacji
Jedyna przewaga jaka widze to brak koniecznosci tworzenia typu
UnsafeString. Ale skoro bezpieczenstwo aplikacji stanowi priorytet to
moze warto dopisac pare linijek, zeby zapewnic sobie prawdziwe
bezpieczenstwo, a nie proteze w postaci notacji.
>Można więc zrobić jawne konwertery -- ale wtedy jesteśmy w punkcie wyjścia
>-- wizualna inspekcja :)
Niejawne konwertery to faktycznie tutaj kiepski pomysl. Ale jawne to
jak najbardziej ok. W koncu programista musi byc swiadom na pewnych
etapach co przesyla i gdzie. Wazne zeby tych etapow bylo jak najmniej
(przynajmniej w granicach danego modulu). ;-)
Wydaje mi sie, ze najwiekszym problemem wiekszosci jezykow jest brak
mechanizmow do szybkiego tworzenia odrebnych typow danych. Dlatego
zawsze zalowalem, ze typedef tak naprawde tworzy tylko aliasy (w sumie
niewiele wiecej niz #define). Tym bardziej musze przyjrzec sie
bibliotece Macka. Na pierwszy rzut oka wyglada calkiem, calkiem... :-)
Maciej Sobczak
> Wydaje mi sie, ze najwiekszym problemem wiekszosci jezykow jest brak
> mechanizmow do szybkiego tworzenia odrebnych typow danych.
Gorzej. Największym problemem jest to, że tłum pędzi w stronę języków
całkowicie dynamicznie typowanych, w których klepią całe systemy z
bazami danych w tle. Potem ten sam tłum pisze sobie nawzajem poradniki o
tym, jak należy nazywać zmienne. Śmiech na sali.
> Dlatego
> zawsze zalowalem, ze typedef tak naprawde tworzy tylko aliasy (w sumie
> niewiele wiecej niz #define).
Silne typedefy by się naprawdę przydały.
> Tym bardziej musze przyjrzec sie
> bibliotece Macka. Na pierwszy rzut oka wyglada calkiem, calkiem... :-)
Jest problem ze stringami. Standardowy string ma tak duży interfejs, że
nie chciało mi się go duplikować w generatorze. Dodatkowo, różne klasy
do stringów mają ten interfejs różny a nie chciałem zakładać, że
użytkownik będzie zawsze korzystał z std::string. Efekt jest taki, że
właściwie każda operacja poza kopiowaniem i przypisaniem wymaga dostępu
do wewnętrznego obiektu, który w tym celu jest składową publiczną.
Niestety ale typegen nie daje pełnego rozwiązania dla stringów -
przynajmniej na razie. Rozwiązaniem jest oczywiście dopisanie do
generatora serii popychaczy dla wszystkich metod z std::basic_string, i
być może opcja, która to wyłącza.
Z dobrych nowin - typegen to open source, więc możesz go w tym kierunku
udoskonalić samodzielnie. ;-)
Alternatywnie, piszesz osobne funkcje szablonowe do operacji na
stringach, które ukryją fakt dostępu do tej publcznej składowej. Tych
funkcji będzie na pewno mniej, niż jest wszystkich metod w std::string,
więc może być to opłacalne podejście, ale wtedy interfejs stringów w
programie będzie odbiegał od standardu.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Sebastian Kaliszewski
> JimVonMoon wrote:
>
>> Wydaje mi sie, ze najwiekszym problemem wiekszosci jezykow jest brak
>> mechanizmow do szybkiego tworzenia odrebnych typow danych.
>
>
> Gorzej. Największym problemem jest to, że tłum pędzi w stronę języków
> całkowicie dynamicznie typowanych, w których klepią całe systemy z
> bazami danych w tle. Potem ten sam tłum pisze sobie nawzajem poradniki o
> tym, jak należy nazywać zmienne. Śmiech na sali.
W tych językach pisze się bardziej zwięźle i łatwo stosunkowo skomplikowane
rzezcy zapisać w paru linijkach. Opera się na na generalnie słusznym
założeniu, że programiści nie są zwykle idiotami i wiedzą co piszą, a kod ma
być przedewszystkim czytany.
Z drugiej storny w przypadku systemów o krytycznych wymaganiach nie ma tak
lekko i nie należy chodzić na skróty.
Trzeba o prostu dostosować narzędzie do zadania.
BTW. w językach dynamicznych możesz sobie tak samo ograniczać dostępne
operacje -- tylko sprawdzenie będzie w czasie wykonania.
>> Dlatego
>> zawsze zalowalem, ze typedef tak naprawde tworzy tylko aliasy (w sumie
>> niewiele wiecej niz #define).
>
> Silne typedefy by się naprawdę przydały.
I jeszcze to co jest w Typegen -- lukier do generowania "oczywistych" operacji.
np, zamiast:
width operator+ (width l, int r)
{
return l.get_val() + r;
}
width operator- (width l, int r)
{
return l.get_val() - r;
}
móc napisać:
width operator{+, -}(width, int) auto(width::get_val);
albo
width operator auto{+, -} (width, int): width::get_val;
i już.
składnia jadnoznaczna i bez nowych słów kluczowych :)
Kolejna rzecz to sensowna konstrukcja w miejsce czasami proponowanego (ale
kłopotliwego w sensownej realizacji) przeciążenia operatora .
pzdr
\SK
Sektor van Skijlen
> > Gorzej. Największym problemem jest to, że tłum pędzi w stronę języków
> > całkowicie dynamicznie typowanych, w których klepią całe systemy z
> > bazami danych w tle. Potem ten sam tłum pisze sobie nawzajem poradniki o
> > tym, jak należy nazywać zmienne. Śmiech na sali.
> W tych językach pisze się bardziej zwięźle i łatwo stosunkowo skomplikowane
> rzezcy zapisać w paru linijkach. Opera się na na generalnie słusznym
> założeniu, że programiści nie są zwykle idiotami i wiedzą co piszą, a kod ma
> być przedewszystkim czytany.
Niestety powszechna praktyka jest taka, że programiści zwykle co prawda nie są
idiotami i wiedzą, co piszą, tylko jak inni to potem czytają, to albo nie mają
zielonego pojęcia, co inni napisali, albo dochodzą do wniosku, że ten, kto to
pisał, nie wiedział, co pisał. A kod ma być przede wszystkim kompilowany i
wykonywany. Powiedzmy, wdrażany.
> BTW. w językach dynamicznych możesz sobie tak samo ograniczać dostępne
> operacje -- tylko sprawdzenie będzie w czasie wykonania.
W jaki sposób np.? I czy nie jest to czasochłonne?
Sebastian Kaliszewski
>>>Gorzej. Największym problemem jest to, że tłum pędzi w stronę języków
>>>całkowicie dynamicznie typowanych, w których klepią całe systemy z
>>>bazami danych w tle. Potem ten sam tłum pisze sobie nawzajem poradniki o
>>>tym, jak należy nazywać zmienne. Śmiech na sali.
>
>>W tych językach pisze się bardziej zwięźle i łatwo stosunkowo skomplikowane
>>rzezcy zapisać w paru linijkach. Opera się na na generalnie słusznym
>>założeniu, że programiści nie są zwykle idiotami i wiedzą co piszą, a kod ma
>>być przedewszystkim czytany.
>
>
> Niestety powszechna praktyka jest taka, że programiści zwykle co prawda nie są
> idiotami i wiedzą, co piszą, tylko jak inni to potem czytają, to albo nie mają
> zielonego pojęcia, co inni napisali, albo dochodzą do wniosku, że ten, kto to
> pisał, nie wiedział, co pisał.
Zwykle nie mam problemów z odczytaniem czyjegoś kodu np. w Pythonie, ale już
z Perlem bywa kiepsko.
Tak samo, nie mam kłopotów z kodem w C++ napisanym w naszej firmie, gdy
napisane jest to zgodnie z obowiązującym u nas podręcznikiem stylu. Niestety
w przypadku kodu obcego bywa już rozmaicie.
Ergo. liczy się czytelny zapis.
Co mi po tym, że kod się statycznie kompiluje skoro jest logicznie bez
sensu. Problem przy czytaniu kodu jest nie z dopasowaniem typów do zmiennych
-- to idzie łatwo, tylko ze zrozumieniem, dlaczego użyto takiej a nie innej
konstrukcji. Jeśli kod jest przejrzysty i nieupstrzony nieistotnymi
szczegółami to łatwiej mogę wyśledzić o co w nim chodzi.
> A kod ma być przede wszystkim kompilowany i
> wykonywany. Powiedzmy, wdrażany.
Ale żeby był wdrażane musi być utrzymywany -- czyli głównie czytany.
>>BTW. w językach dynamicznych możesz sobie tak samo ograniczać dostępne
>>operacje -- tylko sprawdzenie będzie w czasie wykonania.
>
> W jaki sposób np.? I czy nie jest to czasochłonne?
Zwykłe mechanizmy obiektowości. Obiekt nie ma metody, nie da się na nim
zadziałać.
To jest szczególnie silne w przypadku wielometod (jeśli język to ma).
pzdr
--
Sebastian Kaliszewski
Sektor van Skijlen
> Zwykle nie mam problemów z odczytaniem czyjegoś kodu np. w Pythonie, ale już
> z Perlem bywa kiepsko.
No niestety ;)
W przypadku języka C niestety mam bardzo podobne wrażenie. Może to wynika z
faktu, że większość programistów daje się przypasować do dwóch schematów:
jedni to ci, co nigdy-w-życiu nie przestawią się na nic innego, niż C (no,
może na Javę, co jest dla mnie zastanawiającym, acz częstym zjawiskiem), a
drudzy to ci, którzy bardzo chętnie zostawiliby C i przeszli na C++. Jeśli
czytasz kod pisany przez tych pierwszych - a z przyczyn zasadniczych takiego
kodu znajdziesz znacznie więcej - to usiądź dobrze na krześle i zabezpiecz
sobie dużą ilość czasu.
> Tak samo, nie mam kłopotów z kodem w C++ napisanym w naszej firmie, gdy
> napisane jest to zgodnie z obowiązującym u nas podręcznikiem stylu. Niestety
> w przypadku kodu obcego bywa już rozmaicie.
Skąd my to znamy :)
> Ergo. liczy się czytelny zapis.
Zgadza się - i temu właśnie zwykle służą przeglądy kodu.
> Co mi po tym, że kod się statycznie kompiluje skoro jest logicznie bez
> sensu. Problem przy czytaniu kodu jest nie z dopasowaniem typów do zmiennych
> -- to idzie łatwo, tylko ze zrozumieniem, dlaczego użyto takiej a nie innej
> konstrukcji. Jeśli kod jest przejrzysty i nieupstrzony nieistotnymi
> szczegółami to łatwiej mogę wyśledzić o co w nim chodzi.
No i właśnie przegląd kodu powinien takie sytuacje wyłapać.
Nb. - jak pamiętam jeszcze moje inspekcje za czasów Motoroli, to właśnie
najwięcej zgłaszanych uwag miało kwaifikację "maintainability". No bo
inspekcja ma głównie temu właśnie służyć.
> > A kod ma być przede wszystkim kompilowany i
> > wykonywany. Powiedzmy, wdrażany.
> Ale żeby był wdrażane musi być utrzymywany -- czyli głównie czytany.
Zgadza się.
Z inspekcjami sprawa jest właśnie taka - jeśli cztery osoby (a nawet minimum
dwie niezależne osoby) czytając ten kod wiedzą o co w nim chodzi, to znaczy,
że będzie wiedziała również jakakolwiek inna osoba, któa do niego siądzie.
> >>BTW. w językach dynamicznych możesz sobie tak samo ograniczać dostępne
> >>operacje -- tylko sprawdzenie będzie w czasie wykonania.
> >
> > W jaki sposób np.? I czy nie jest to czasochłonne?
> Zwykłe mechanizmy obiektowości. Obiekt nie ma metody, nie da się na nim
> zadziałać.
No dobrze, ale w jakiś sposób to trzeba w obiekcie/klasie zaznaczyć. Pytam po
prostu, czy zadanie okrajania obiektu nie jest czasochłonne.
Zauważ, że jest wiele "potencjału" na różne bezpieczne i wygodne kwestie w
językach, które są czasochłonne. Zarządzający lubią wtedy twierdzić, że
wartość dodana niewielka, a czas pracy programisty kosztuje.
Sebastian Kaliszewski
[ciach -- nic dodac nic ująć]
>>>>BTW. w językach dynamicznych możesz sobie tak samo ograniczać dostępne
>>>>operacje -- tylko sprawdzenie będzie w czasie wykonania.
>>>
>>>W jaki sposób np.? I czy nie jest to czasochłonne?
>
>
>>Zwykłe mechanizmy obiektowości. Obiekt nie ma metody, nie da się na nim
>>zadziałać.
>
>
> No dobrze, ale w jakiś sposób to trzeba w obiekcie/klasie zaznaczyć. Pytam po
> prostu, czy zadanie okrajania obiektu nie jest czasochłonne.
Generalnie tak samo jak w C++ -- różnica jest taka jak wszędzie indziej
między językami statycznie a dynamicznie typowanymi -- check jest w runtime.
Tzn zamiast wbudowanego string czy robisz sobie typ unsafeString, które ma
mniej metod i nie pozwala się "na pałę" wypisać (tzn print czy co tam jest w
języko go nie rozumie). Czyli robisz to samo co w C++.
Generalnie wiadomo też, że języki dynamicznie typowane dają wolniejszy kod
(typowo dobrze zoptymalizowane kompilatory Common Lispa dają kod który w
benchmarkach wychodzi circa o połowe wolniej niż robiący to samo kod w C).
Spytaj też Qrczaka, jak wychodzi z wydajnością jego Koguta (też kompilowany
i dynamicznie typowany).
> Zauważ, że jest wiele "potencjału" na różne bezpieczne i wygodne kwestie w
> językach, które są czasochłonne. Zarządzający lubią wtedy twierdzić, że
> wartość dodana niewielka, a czas pracy programisty kosztuje.
W typowo używanych językach sprawa zależy od mocy stystemu typów i lukru
pozwalajacego pewne rzezcy zapisać krócej.
Stąd np w C nie ma senswonego wyjścia poza nieschizmatyczną notacją
węgierską. W Javie należałoby sporo się zastanowić (operatory).
W językach typu C#, C++, Ruby, Python można rzecz załatwić poprzez system
typów, ale w C# i C++ jest to zawsze sporo pisania (i przydają się mocno
rzeczy typu Typegen Maćka). W Pythonie czy Rubym można sobie zrobić
mechanizm lukrujący, pozwalający utworzyć typ z wyciętymi niektórymi
metodami innego typu drogą skrótową. To, że samo tworzenie takiego typu nie
musi być jakoś super wydajne nie stanowi problemu -- typ tworzy się raz a
używa wielokrotnie.
pzdr
--
Sebastian Kaliszewski