Warsztat - Programowanie gier

Marzec 11, 2010, 20:30:03 *
Witamy, Gość. Zaloguj się, lub zarejestruj proszę.

Zaloguj się podając nazwę użytkownika, hasło i długość sesji
Aktualności: Warsztat, Regulamin forum, #warsztat, Wiki, FAQ, NoPaste, Mapa
 
   Strona główna   Pomoc Szukaj Zaloguj się Rejestracja  
Strony: 1 2 3 [4]
  Drukuj  
Autor Wątek: Kod - po polsku czy po angielsku?  (Przeczytany 10662 razy)
Charibo
Member2000
*******

wiadomości: 2323



Zobacz profil WWW
« Odpowiedz #45 : Kwiecień 08, 2007, 18:42:13 »

W sumie moj styl jest podobny do stylu vashpana i pewnie wiekszosci ludzi Smiley

Ale komentarze pisze zazwyczaj po angielsku - jesli chce kod przekazac dalej (na przyklad headery silnikow itp.), a po polsku tylko wtedy, kiedy mam kawalek wymagajacy poprawy. Polski w commentach zwraca moja uwage
Zapisane

Now these points of data make a beautiful line
And we're out of beta we're releasing on time.

Blogassek.
Asmodeusz
Sr. Member
****

wiadomości: 332


Asmodeusz.NET


Zobacz profil WWW
« Odpowiedz #46 : Kwiecień 09, 2007, 01:06:33 »

Komentarze zwykle piszę po polsku - a powód jest prosty: znacznie łatwiej jest mi szybko przeczytać komentarz po polsku, nie muszę się specjalnie koncentrować nad językiem - mogę poświęcić uwagę treści adnotacji. Natomiast sam kod jest pisany w odpowiednim języku programowania (nie mam kompilatora języka polskiego/angielskiego Wink ) z angielskimi nazwami funkcji, zmiennych itp.

Style nazewnictwa i kodu: WielbłądziStylNazwZmiennychIFunkcji, Obficie::Stosowane::Namespace bez używania globalnego using (jeśli się pojawia dyrektywa using, to tylko wewnątrz funkcji, w której jest używana), stosowanie notacji węgierskiej w nazwach zmiennych ( z oznaczeniem zmiennych wewnętrznych m_, statycznych s_, zmienne globalne są zmiennymi statycznymi struktur - więc g_ odpada, wskaźników na zmienną p_, stałych c_ itp.) oraz oznaczaniem typów (wliczając w to definiowane przez użytkownika typy np. skn - skóra, ptr - wskaźnik (kursor, celownik itp.) ), co niektórych nie wiedzieć czemu denerwuje. Oprócz tego nazewnictwo typów CClass, SStruct, TClassOrStructTemplate, IInterface, GGlobalStruct (struktura zawierająca tylko dane statyczne i prywatny niezaimplementowany konstruktor), EEnum (traktowane jak namespace - nie muszę się martwić konfliktami nazw), oprócz tego stosowane do typów wbudowanych makra z nagłówka windows.h (czyli typedef'y UINT, INT, BYTE, DWORD, BOOL itp.). Do tego należy dodać używanie stałych referencji w miejsce przekazywania przez wartość - ogólnie często używam referencji. Generalnie styl trochę przypominający styl poprzedników - może z wyjątkiem namespace. Przykład kodu pisanego moim stylem:

Kod:
namespace Module {
    namespace Submodule {
        namespace Group {

            // komentarz o danej klasie
            //
            class CClass
            {
                // implementacja
            private:
                // pierwsza grupa zmiennych
                // pierwsza zmienna
                DWORD    m_dwVariable;
                // druga zmienna - wskaźnik na typ szablonowy parametryzowany typen UINT
                TTemplateClass<UINT>*  mp_tc_UINT_Pointer;

                // druga grupa zmiennych
                // stała statyczna
                CAnotherClass sc_acVariable;
                // enum wewnętrzny - dla krótkich enumów i struktur cały zapis jest w jednej linii
                enum WewnetrznyEnum{ Wartosc1, Wartosc2, Wartosc3 };

                // interfejs
            public:
                // funkcja 1
                void Foo(INT iParam, float fParam, const D3DXVECTOR3 &vec3SomeVector) const;
                // funkcja inna, posiadająca referencję niestałą - zwracająca przez nią informacje
                BOOL Bar(INT &r_iReturnVal1, D3DXMATRIX &r_matReturnMatrix);

            };//---
}}}
Zapisane

vashpan
SuperHero Member
******

wiadomości: 1444


Zobacz profil WWW
« Odpowiedz #47 : Kwiecień 13, 2007, 17:14:56 »

Co do namespace tez uzywam ale raczej by odroznic jakies logiczne elementy kodu np. GUI i na pewno mniej niz Asmodeusz Smiley

using uzywam na poczatku plikow zrodlowych ( nie naglowkowych ! ) - ale nie wewnatrz jakiegos modulu, ale jakby na zwewnatrz, czyli kod uzywajacy GUI etc...
Zapisane

blackstar
Newbie
*

wiadomości: 21


Zobacz profil
« Odpowiedz #48 : Kwiecień 13, 2007, 19:01:27 »

Do poki pisalem w QBASICU uzywalem jez. polskiego w kodzie zrodlowym. Potem zaczalem przestawiac sie na Turbo Pascala, sciagnalem jakis kod z internetu, ktory mial byc bardzo pomocny i... komentarze byly po francusku. Od tamtej pory wszystko pisze w 100% po angielsku, bez wyjatkow. To bylo dobre pare lat temu. Ostatnio zauwazylem, ze nawet notatki robie po angielsku. Jakos tak samo wychodzi...

Styl?
Klamry wedlug Linusa, wystepuja zawsze, nawet jesli sa zbedne:
Kod:
void foo()
{ // w przypadku funckji, klas, struktur, enumow - w nastepnej linii
        if(true) { // w kazdym innym przypadku w tej samej linii
               ...;
        } else {
               ...;
        }
}
Tab stop 8. IMO duze wciecia pokazuja struktore kodu tak samo dobrze jak (jesli nie lepiej) klamry w osobnych linijkach, przy czym maja dodatkowa zalete: duzo wiecej kodu miesci sie na ekranie (w pionie)! Jesli przy takich wcieciach brak miejsca (na ekranie) w poziomie to znak, ze prawdopodobnie dany fragment nie jest najlepiej napisany.

Nazwy typow, klas i stuktor FooBarBaz. Nazwy funkcji i zmiennych fooBarBaz. Zmienne lokalne czasem foobar. Notacja wegierska jest, moim zdaniem, bez sensu - kazdy porzadny edytor/IDE pozwala "podejrzec" deklaracje zmiennej przy uzyciu jednego skrotu klawiszowego. Pozatym notacja wegierska narusza zasade DRY (Do not Repeat Yourself) - typ zmiennej okreslony jest w wiecej niz jednym miejscu - jesli chcesz zmienic typ zmiennej musisz poprawic wszystkie jej wystapienia. Wyjatek to przedrostek g_ dla zmiennych globalnych (ktorego uzywam) i m_ dla pol klas (ktorego nie uzywam, ale czasem mysle, ze powinienem).

Nie uzywam przedrostka C do klas, ale czasem zdaza mi sie uzywac I. Jesli chodzi o spacje wokol operatorow to unikam nadmiaru, ale staram sie pokazac strukture wyrazenia (~kolejnosc obliczania), np
Kod:
x = a + b*c - d/e + f*(g-h);
if(foo==0 && (bar-x)>1) { ....

To dotyczy mojego kodu. Jesli modyfikuje czyjs kod, staram sie nie zmieniac konwencji.

Na koniec bardzo polecam ksiazke "Lekcja programowania" Briana Kernighana i Roba Pike'a. Autorow przedstawiac nie trzeba.
Zapisane

"To do the Unix philosophy right, you have to value your own time enough never to waste it. (...) And never work harder than you have to; work smarter instead, and save the extra effort for when you need it."

Eric S. Raymond - The Art of Unix Programming
raver
Sr. Member
****

wiadomości: 372

jestem ninja ;]


Zobacz profil WWW
« Odpowiedz #49 : Kwiecień 14, 2007, 18:15:07 »

My style:
- projekt długi: angielski z wyjątkiem komentarzy, których nie chce mi się przetłumaczyć Tongue
- projekt średni: pół na pół (OpenPlik,BeginGra,KillGracz itp...)
- projekt krótki: zmienne jednoliterowe Smiley tak mi jakoś ładniej wygląda Smiley

Jak mi się totalnie nudzi, to robie sobie jakąś opowieść/bajke/jakiś totalny bezsens... i to całkiem niezła zabawa!
Zapisane

raver's dev blog < na razie nic tam nie ma Smiley
gamecreator
Full Member
***

wiadomości: 118


It's easy to believe it when you don't understand.


Zobacz profil WWW
« Odpowiedz #50 : Lipiec 10, 2007, 00:02:59 »

Cytuj z: blackstar
Od tamtej pory wszystko pisze w 100% po angielsku, bez wyjatkow. [...] Ostatnio zauwazylem, ze nawet notatki robie po angielsku. Jakos tak samo wychodzi...

A kawałek dalej:

Cytuj z: blackstar
Kod:
void foo()
{ // w przypadku funckji, klas, struktur, enumow - w nastepnej linii
        if(true) { // w kazdym innym przypadku w tej samej linii
               ...;
        } else {
               ...;
        }
}

Fajna sprzeczność, hehe Wink

Cytuj z: blackstar
Nie uzywam przedrostka C do klas

Też nie lubię tego przedrostka, bo raz że kojarzy mi się z syfiastymi bibliotekami typu MFC czy VCL, a dwa, że i tak są one zbędne. Przecież jak widzę coś takiego:

Sprite ghost;

to oczywiste jest, że "Sprite" jest nazwą typu, a "ghost" nazwą konkretnego obiektu. Więcej mnie nie interesuje ;-J

A co do dylematu angielski vs. polski, to też się nad tym zastanawiam w związku z kursami na mojej stronie. Z jednej strony polskie nazwy i komentarze ułatwiają [a niektórym to nawet umożliwiają Tongue] zrozumienie kodu. Z drugiej strony fajnie by było mieć też wersję angielską strony, skoro już w miarę znam ten język, a z robieniem dwóch wersji językowych tego samego kodu to już może być za dużo roboty, możliwe że niepotrzebnej. A w kodzie słowa kluczowe i tak są już po angielsku, nazwy funkcji bibliotecznych są po angielsku, więc ten polski język tam trochję nie pasuje Tongue Na dodatek głupio niekiedy wyglądają nazwy, gdy się usunie polskie znaki diakrytyczne [np. "wystapil blad", "dol", "gora" itp.  ;-P]. No i nazwy angielskie są jakoś takie bardziej zwięzłe. Z powyższych względów w końcu zaczynam się skłaniać w kierunku kodu po angielsku.
Komentarze chciałem pozostawić po polsku, ale też mam niemiłe wspomnienia z przeglądania cudzego kodu z komentarzami w nieznanych mi językach [np. hiszpańskim, niemieckim, nie mówiąc już o chińskim, gdzie nawet nie miałem takiej czcionki i widziałem same krzaki ;-P], więc chyba najlepszy jest jednak język angielski, zarówno do kodu, jak i do komentarzy. Ten język znają wszyscy programiści [a jak nie znają, to mają ciężkie życie ;-P], więc jest uniwersalny.
« Ostatnia zmiana: Lipiec 10, 2007, 00:13:45 wysłane przez gamecreator » Zapisane

SasQ
http://sasq.programuj.com/
Co robi rasowy Linuxowiec po zejściu z Mount Everest?
umount everest
Cheesy
Cytadela
Full Member
***

wiadomości: 153


Paranoid Android


Zobacz profil WWW
« Odpowiedz #51 : Lipiec 10, 2007, 00:07:45 »

Ja nie mam jakiegos wiekszego stylu no moze orprocz tego ze lubie "wciskac" kod w rozne dziwne miejsca, co czesta konczy sie niezlym mieleniem kompa. Jednym slowem lubie robic sobie niezly burdel w kodzie. Ale to chyba jest raczej offtop. Co do samego nazywania to raczej jest tak ze zmienna nazywam pierwszym lepszym klawiszem Cheesy.
Zapisane

a może jednak C++... Jea!
---
www.kacperDEV.prv.pl | www.kacperdev.wordpress.com
if (1+1==3)  cout << "komputer jest chory";
nilphilus
Sr. Member
****

wiadomości: 495

:->


Zobacz profil WWW
« Odpowiedz #52 : Lipiec 10, 2007, 00:34:22 »

My style:
- projekt długi: angielski z wyjątkiem komentarzy, których nie chce mi się przetłumaczyć Tongue
- projekt średni: pół na pół (OpenPlik,BeginGra,KillGracz itp...)
- projekt krótki: zmienne jednoliterowe Smiley tak mi jakoś ładniej wygląda Smiley

Jak mi się totalnie nudzi, to robie sobie jakąś opowieść/bajke/jakiś totalny bezsens... i to całkiem niezła zabawa!

Kod takiego średniego projektu musi dziwnie wyglądać Tongue
małego zresztą też ;->

a co do komentarzy, zawsze po polsku i zawsze robione tylko dlatego żeby oddzielić poszczególne funkcje klasy ;-]
Kod:
/*************************
** OPIS                 **
*************************/
Zapisane

Powinieneś doskonale znać swoje ograniczenia i się nimi nie przejmować.
Reg
Member2000
*******

wiadomości: 3614



Zobacz profil WWW
« Odpowiedz #53 : Lipiec 10, 2007, 09:16:02 »

Cytuj
A co do dylematu angielski vs. polski, to też się nad tym zastanawiam w związku z kursami na mojej stronie.
Ciekawie jest popatrzeć, jak to robią w różnych książkach. Większość książek niestety tłumaczy także identyfikatory na polski, ale są i takie (np. "C++ dla programistów gier", wyd. Helion), gdzie komentarze są po polsku, a identyfikatory po angielsku.
Zapisane

SceNtriC
Newbie
*

wiadomości: 17



Zobacz profil
« Odpowiedz #54 : Lipiec 10, 2007, 09:42:26 »

Jeśli chodzi o nazwy zmiennych i komentarze, to odpowiednio używam angielskiego i polskiego. Zmienne lepiej po prostu komponują się z resztą instrukcji, gdy są w języku angielskim, natomiast polskie komentarze są dla mnie i póki nie chcę kodu przekazywać gdzieś dalej, tak pozostanie (jeszcze zwykle są one uporządkowane według kolumny Tongue ). Ogólnie ostatnio zacząłem używać notacji przeznaczenie_pierwsza(e) litera(y) typu zmiennejNazwaZmiennej (np. t_uStrengthExp)- dzięki temu wiem przynajmniej do czego zmienna służyła i jakiego jest typu bez zgłębiania się w klasę.

Wszelkie enumy piszę dużymi literami (a poszczególne wartości poprzedzam pierwszymi literami nazwy enuma), a nazwy klas zawsze poprzedzam literą C dzięki czemu mając instrukcję CItem Item; wiem od razu o co chodzi. Wszelkie odstępy też stosuję, zwykle nawet z przesadą.

Tak mniej więcej przedstawia się mój sposób pisania kodu Tongue

Pozdrawiam
Zapisane

Nevermind77
Newbie
*

wiadomości: 21


Zobacz profil
« Odpowiedz #55 : Lipiec 10, 2007, 10:34:25 »

A ja piszę specyficznie.

Prefiksy małymi literami. Stosuję "c" dla klas, dzięki temu mogę utworzyć obiekt typu cObjectManager pod nazwą ObjectManager. Zamierzam również zacząć stosować "m" przed polami klasy i "g" przy zmiennych globalnych, właśnie tego mi brakowało! ;] 

W zależności od złożoności projektu stosuje "e" przed enumeracją lub namespace. Dzięki namespacowi mam na przykład:

Kod:
namespace Field
{
   enum Type
   {
       Water,
       Road,
       ...
   }
}

A potem używam bardziej dla mnie czytelnie:

Kod:
if ( Field::Road == FieldType ) ...

Dzięki temu widzę lepiej do czego przyrównuje. Poza tym staram się pisać w instrukcjach warunkowych:

Kod:
if ( Stała == Zmienna )

Dzięki czemu gdy zamiast "==" wpiszę "=" kompilator wyświetli błąd. Nawiasy klamrowe zawszę piszę w nowej linii a po normalnych "(" i przed ")" stosuję spację żeby nazwa zmiennej czy funkcji była lepiej widoczna. No chyba że jest to "Funkcja()", to nie ma czego lepiej widzieć. Wink

To czy użyję nawiasów po "if" gdy chcę wpisać jedną instrukcję zależy od tego jak długa jest ta instrukcja. Przy pętlach zawsze używam nawiasów.

Operatora trójargumentowego staram się używać tylko przy przypisaniu wartości zmiennej.

Piszę zawsze z wielkiej litery, jeżeli nie ma prefiksu, czyli JakaśZmienna lub mJakaśZmienna. Nazwy staram się pisać po angielsku chyba że np. chcę tylko coś chwilowo sprawdzić to piszę kawałek kodu po polsku żeby znaleźć błąd czy coś przetestować.

Staram się nie pisać zbyt długiego kodu w jednej linii i przez to korzystam ze zmiennych pomocniczych.

Kod:
int X1 = // Obliczenia
int Y1 = // Obliczenia
int X2 = // Obliczenia
int Y2 = // Obliczenia

rect( X1, Y1, X2, Y2 )

A nie jakieś długaśne wywołania które ciągną się i ciągną się...

Entery staram się oszczędzać bo jakoś nie czuję żeby 10 enterów dawało większą przejrzystość od 3. Chyba że kogoś podnieca że ma projekt na 5 000 linii z czego 4000 to entery. Wink

Chyba jako jeden z nielicznych tutaj zgromadzonych stałe... piszę normalnie. Tak jak zwykłe zmienne. Po prostu według mnie szpetnie wyglądają wielkie litery, rażą mnie i często zapominam o tym żeby przytrzymać shift.

Angielski kod jest czytelniejszy od polskiego. Po polsku ciężko mi się pisze. Jakoś trudno znaleźć odpowiednie słowa i trudno skonstruować nowe, łatwe do zapamiętania. Poza tym są jakieś nieporęczne. "PobierzX" zamiast "GetX"? Wink

Mam pewien problem ze skrótowcami, nie mam żadnego "systemu" odnośnie ich.

Dokumentację tworzyć będę doxygenem w języku... zależnym od potrzeby i wygody, niektóre rzeczy łatwiej opisać mi po angielsku niż po polsku, a niektórych nie trzeba w ogóle dokumentować bo nazwy mówią same za siebie. Wink
« Ostatnia zmiana: Lipiec 10, 2007, 10:36:45 wysłane przez Nevermind77 » Zapisane
novo
Hero Member
*****

wiadomości: 502



Zobacz profil WWW
« Odpowiedz #56 : Lipiec 10, 2007, 20:16:29 »

Ja od paru lat pisze komentarze po angielsku(na poczatku mialem z tym problemy) i ostanio okazalo sie ze sie to bardzo oplacilo. Znalazlem prace i w firmie mamy wymog zeby wszystkie komentarze byly po angielsku wlasnie. Teraz nie musze sie spinac, bo robie to automatycznie. Chociaz nigdy nie bralem tego pod uwage decydujac sie na angielskie komentarze. Bardziej myslalem o ewentualnym upublicznieniu kodu. Ale teraz jestem dzieki temu do przodu Smiley

Pozdr.
novo.
Zapisane

From all the things I've lost I miss my mind the most.
devblog
k_b
Hero Member
*****

wiadomości: 968


Świr i dziwoląg


Zobacz profil WWW
« Odpowiedz #57 : Lipiec 10, 2007, 20:32:14 »

Cytuj
A co do dylematu angielski vs. polski, to też się nad tym zastanawiam w związku z kursami na mojej stronie.
Ciekawie jest popatrzeć, jak to robią w różnych książkach. Większość książek niestety tłumaczy także identyfikatory na polski, ale są i takie (np. "C++ dla programistów gier", wyd. Helion), gdzie komentarze są po polsku, a identyfikatory po angielsku.
W książkach wydawanych przez Heliona identyfikatory w kodach nie są tłumaczone - jedynie komentarze.
Zapisane

GG: 6346008 (często na niewidocznym)
Jam samuraj, zdobywający wiedzę lecz oszczędny w słowach, pełen pogardy dla śmierci lecz w każdej chwili gotowy na koniec Drogi...
gamecreator
Full Member
***

wiadomości: 118


It's easy to believe it when you don't understand.


Zobacz profil WWW
« Odpowiedz #58 : Lipiec 10, 2007, 22:59:16 »

Na pewno nie we wszystkich, bo pamiętam że gdzieś widziałem przetłumaczone ;-J

A co do stylu... hmm.. to może ja też pokażę jak piszę ;-J

Ogólnie preferuję styl wielbłądzi gdzie się da, bo jest bardziej zwięzły niż z podkreślnikami [no i jak słusznie juz ktoś zauważył, podkreślniki wymagają więcej przyciśnięć klawiszy, a i tak trzeba nabijać shift ;-J]. Podkreślniki stosuję bardzo rzadko. Stosuję to dla wszystkich nazw, włącznie z nazwami stałych [nie lubię nazw pisanych w całości wielkimi literami, bo są nieczytelne].

Nazwy typów danych [struktur, klas, enumów, typedefów itp.] zaczynam od wielkiej litery, a konkretnych obiektów od małej. Robię tak dlatego, żeby dało się zrobić to, o czym ktoś tu wspomniał: ObjectManager objectManager, czyli stosowanie tej samej nazwy dla typu i dla obiektu tego typu [to nie to samo, co CNazwaKlasy, co uważam za nadmiarowe, bo już przecież sama składnia mówi gdzie jest nazwa typu, a gdzie nazwa obiektu]. Trochę to takie Javowe i zastanawiam się, czy odwrotnie nie byłoby bardziej logicznie ;-) W końcu nazwa własna obiektu to prawie jak imię, więc może powinno być z dużej ;-) w przeciwieństwie do pospolitej nazwy klasy, do której on należy ;-D [joke]

Nie używam i nienawidzę notacji węgierskiej. O ile w językach ze słabym typowaniem ma to jakiś sens, to w C++ już jest właściwie niepotrzebne. Od pamiętania typów mam kompilator i nie pozwalam mu się obijać ;-)  a nazwy obiektów daję takie, żebym sam mógł się później domyślić "z kontekstu", jakiego są typu [jeśli się zastanawiam, znaczy złą nazwę wybrałem ;-J]. We własnym kodzie unikam też prefiksów, typu wxCośtam, glCośtam, SDL_cośtam, bo od tego są namespace'y ;-J  Ilość tekstu do napisania jest w sumie taka sama, nie licząc operatora :: ;-P za to zyskuję na tym możliwość aliasowania tych przedrostków i włączania wybranych elementów z namespace'a.

Jeśli chodzi o klamerki, to jedynie przy blokach funkcji i klas mam zasadę, by umieszczać je obie w pierwszej kolumnie, w nowych liniach. Jednak w przypadku instrukcji warunkowych, switchy, pętli itp. raczej "zacieśniam" ;-) albo wogóle pomijam klamry tam, gdzie nie są potrzebne. Oczywiście robię wtedy wcięcia tak, żeby było wiadomo która instrukcja jest zależna od warunku. Wcięcia robię zazwyczaj na dwie.. góra trzy spacje, i na tyle mam ustawiony tab-stop.  Używam też gdzieniegdzie spacji w nawiasach i wyrażeniach, jeśli mogą poprawić czytelność.

W klasach publiczny interfejs daję zawsze pierwszy, w całości, by nie trzeba było do niego przewijać kilka ekranów zbędnego tekstu prywatnej części klasy ;-J  Składowych raczej nie poprzedzam żadnymi przedrostkami typu m_cośtam, tylko nadaję im jakieś sensowne nazwy. W akcesorach zazwyczaj nie daję get i set, tylko daję im takie same nazwy, a rozróżniam je po tym, że getCośtam() zawsze jest const, a setCośtam nigdy nie będzie const ;-J

Jeśli używam namespace'ów, to zazwyczaj najpierw deklaruję co jest w danym namespace'u, a dopiero później rozwijam definicję. Dzięki temu na początku nagłówka mam "skrót" tego, co siedzi w danej przestrzeni nazw i nie muszę zbytnio wcinać kodu tych definicji ;-J

Jeśli w klasie są jakieś krótkie funkcje [np. akcesory], które powinny być inline, piszę je w nagłówku na zewnątrz klasy, poprzedzając słówkiem inline. Staram się nie zaśmiecać definicji klasy, bo jej interfejs można traktować jako dokumentację, więc powinno to być jak najbardziej czytelne.

Ogólnie kieruję się paroma zasadami, a za każdą taką zasadą mam jakieś rationale, które uzasadnia jej stosowanie.

OK, to jeszcze mały snip jak to wygląda:
Kod
namespace Graphics {
  class Sprite;
  class SpookyGhost;
  bool testCollision(const Sprite& a, const Sprite& b);
  //...
}
 
class Graphics::SpookyGhost : public Graphics::Sprite
{
 public:
   int skladnik1;
   bool visible() const;  //Akcesor typu "Get". Zwraca true, gdy duszek widoczny.
   void visible(bool newState);  //Akcesor typu "Set". Ustawia nowy stan widocznosci.
   void scarePlayer(const Player& player);  //Jakas metoda.
   //...
 private:
   bool visibility;
   //...
};
 
inline bool Graphics::SpookyGhost::visible() const
{
  return visibility;
}
 
//w pliku .cc :
void Graphics::SpookyGhost::scarePlayer(const Player& player)
{
  if ( computeDistance(*this, player) < 10) {
    visible( !visible() );  //pokaz sie
    while (!player.scaredToDeath())  {
      sayBoo();
      makeNoise();
    }
  }
  else  setDirection( player.currentPosition() );
}
//gdzies w uzyciu... :
SpookyGhost spookyGhost, whiteGhost, greenGhost;

//EDIT: Buu chyba jakiś autoformater tu jest, bo wcięło mi pojedyncze spacje przed "public" i "private". W ogóle to polskie znaki w kodzie [np. w komentarzach] zmieniało mi w referencje znakowe HTML, dlatego musiałem napisać je bez polskich liter. Szybka edycja też jest zrąbana - dodaje jakieś znaczki-dziwaczki w miejscu spacji.
« Ostatnia zmiana: Lipiec 10, 2007, 23:21:23 wysłane przez gamecreator » Zapisane

SasQ
http://sasq.programuj.com/
Co robi rasowy Linuxowiec po zejściu z Mount Everest?
umount everest
Cheesy
Strony: 1 2 3 [4]
  Drukuj  
 
Skocz do:  

Hosting: Polska Strefa - Ogłoszenia
Powered by SMF 1.1.7 | SMF © 2006, Simple Machines LLC