> Znane mi standardy kodowania sugerują najpierw public, potem protected
> i na końcu private - ta kolejność wynika z tego, że czytelnik, który
> zwykle jest użytkownikiem klasy, najbardziej jest zainteresowany
> publicznym interfejsem, więc jest sens go napisać na początku.

A ja właśnie wszędzie widzę i słyszę na odwrót. A już najczęściej, to
kolejność jest zupełnie przypadkowa.

A ja masz typy wyliczeniowe, struktury, metody i w każdym zbiorze w
przedziale od public do private to jak to układasz?

--
Mateusz Bogusz

do góry

On 3 Wrz, 21:30, Karol Y <k...@o...pl> wrote:

> A ja masz typy wyliczeniowe, struktury, metody i w każdym zbiorze w
> przedziale od public do private to jak to układasz?

Dokładnie tak, jak napisałem: public, (protected), private.

Protected w nawiasie, bo prawie nigdy tego nie mam.

Dokładnie tak samo piszę w Javie, czyli najpierw wszystko to, co jest
public. Przy okazji bluzgam zawsze na to, że te publiki tam są przy
każdej nazwie, bo dopiero przy powtórzeniach widać, jak bardzo te
powtórzenia są bez sensu.

Z ciekawostek, w Adzie najpierw idzie sekcja publiczna ale nie
dlatego, że tak ktoś lubi, tylko dlatego, że *gramatyka* tego wymaga i
inaczej się po prostu nie da:

package Foo is

-- cośtamcośtam publiczne

private

-- cośtamcośtam niepubliczne

end Foo;

Konwencja, którą używam w C++, jest z tym tokiem myślenia zgodna -
chociaż nie jest wymuszana przez kompilator.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

> pojedyncze projekty jakie pisalem to poki co skala
> co najwyzej 30-40 modulow (kazdy modul ma u mnie
> zwyczajowo kilkaset do tysiaca pareset lini)
`
jak np patrze (troche i niedokladnie) na to jaki uklad
i zaleznosci (zgrubsza) maja moduly (plikowe przestrzenie
dokladniej bo niecialo mi sie tego kompilowac do
odzielnych modulow i inkludowalem to wszystko do
jednego pliku) w mojej niedokonczonej gierce
'space bots sigma ) to i tak nasuwa to pewne wnioski

-> winMain.obj // frame (setup/arch)
-> setupGl.obj // frame (setup)
-> WndProc.obj // frame (arch)

-> keyHandlers.obj // frame (arch)
-> entityPlayerShip.obj // entity agent
-> entitiesRockets.obj // entity agents
-> saveLoad.obj // support
-> hud.obj // support agent
->

-> mouseHandlers.obj // frame (arch)
-> entityPlayerShip.obj // entity agent

-> mainLoop.obj // frame (arch)
-> entityPlayerShip.obj // entity agent
-> hud.obj // support agent
-> entitiesAsteroids.obj // entity agents
-> entitiesStations.obj // entity agents
-> entitiesBases.obj // entity agents
-> entitiesSlayers.obj // entity agents
-> entitiesRockets.obj // entity agents
-> entitiesCruisers.obj // entity agents
-> // entity agents
-> // entity agents
-> // entity agents
-> // entity agents
-> // entity agents
-> // entity agents
-> // entity agents
-> // entity agents
-> // entity agents
->
->
->
->
->
->



--> utilsLog.obj //utils
--> utilsMath.obj
--> utilsSound.obj
--> utilsShapes.obj
-->


np takie ze charakterystyczne ze polaczenia miedzy
modulami sa zwykle (z natury mozna powiedziec) jednostronne
(typu 'uses') albo ze zasadniczo moduly te dziele sie na
trzy {cztery} rodzaje: utilsy, frame (szkielet aplikacji)
i moduly encji wlasciwych agentow sceny - {pozatym jeszcze ew
'support' dla sceny (jak np hud i takie rzeczy)



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

w sumie to ostatnio zrezygnowalem z obslugi klawiatury
i myszy w wndproc na rzecz bloku GetAsyncKeyState'ow
w kazdej ramce i sam schemat sie uproscil

main
setup
loop
input
agents

utils


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> Konwencja, którą używam w C++, jest z tym tokiem myślenia zgodna -
> chociaż nie jest wymuszana przez kompilator.

Pomysł jest nawet dobry, ale ja na początek to bym jednak chciał, żeby
już w zespole pisali jak chcą, ale wszyscy przynajmniej tak samo. Bo
gdzie nie trafiam, tam każdy programista ma swój "styl" ;-o

--
Mateusz Bogusz

do góry

On 4 Wrz, 08:04, Karol Y <k...@o...pl> wrote:

> ja na pocz tek to bym jednak chcia , eby
> ju w zespole pisali jak chc , ale wszyscy przynajmniej tak samo. Bo
> gdzie nie trafiam, tam ka dy programista ma sw j "styl" ;-o

Najwyraźniej trafiasz do zespołów, które nie mają szefa (lidera).

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

> On 4 Wrz, 08:04, Karol Y <k...@o...pl> wrote:

>

> > ja na pocz tek to bym jednak chcia , eby

> > ju w zespole pisali jak chc , ale wszyscy przynajmniej tak samo. Bo

> > gdzie nie trafiam, tam ka dy programista ma sw j "styl" ;-o

>

> Najwyraźniej trafiasz do zespołów, które nie mają szefa (lidera).

>

swiat liderów to totalny koszmar głąbów, lepiej jest mz czuc osobiste
zwiazki i konotacje z czyms dokladnie przeciwnym



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On 2-9-2011 22:17, Maciej Sobczak wrote:
> On 2 Wrz, 14:04, "Sarr."<s...@g...pl> wrote:
>> na tej samej zasadzie mozna by zapytac o kolejnosc sekcji: public,
>> protected i private czy tez odwrotnie...
>
> Znane mi standardy kodowania sugerują najpierw public, potem protected
> i na końcu private - ta kolejność wynika z tego, że czytelnik, który
> zwykle jest użytkownikiem klasy, najbardziej jest zainteresowany
> publicznym interfejsem, więc jest sens go napisać na początku.

zapytam tak, czy sa to sztywne standardy kodowania czy nie sa to raczej
luzne sugestie na ten temat? nie zawsze czytelnik jest zainteresowany
sekcja public, na przyklad: mam klase A, ktore ma kilka protected pure
virtuali i caly public interfejs [kilka get/set, uzywany przez
aplikacje]. 'uzytkownik' to inny programista, ktory bedzie implementowal
te virtuale w swojej klasie dziedziczac z A, wiec lepiej jest mu
'pokazac' od razu zaczynajac od sekcji protected a nie zmuszajac do
przewijania calej sekcji public [gdyby od niej zaczac]. nie jestem
zwolennikiem sztywnych standardow, bo zawsze znajdzie sie cos co pokaze,
ze inaczej mozna czytelniej.

>> a gdzie typedefy w tym
>> wszystkim.
>
> To zależy, czy są publiczne, czy nie, bo patrz wyżej.
>
>> niekiedy chcac przestrzegac z gory ustalonych regul robi sie
>> straszny bajzel w .h.
>
> Właśnie po to są te reguły, żeby bajzlu nie było.

wlasnie z tym standardem robi sie niekiedy niezly bajzel, 3 sekcje,
kazda z seria funkcji, typedef'ow, niekiedy dodatkowych struct'ow i
enum'ow. czasem chcialo by sie miec typedefy razem, enumy i dodatkowe
struct'y tez razem. chyba, ze ktos lubi scrollowac mamrtoatac pod nosem
'ten enum w protected to byl gdzies pod ta cala kopa public a przed tymi
typedefami z private, nosz szlag, gdziez on jest...' [tego oczywiscie
nie traktowac grobowo powaznie, bo jest ctrl+f ;]

pozdrawiam,
Sarr.

do góry

On 2011-09-05, Sarr. <s...@g...pl> wrote:
> On 2-9-2011 22:17, Maciej Sobczak wrote:
>> On 2 Wrz, 14:04, "Sarr."<s...@g...pl> wrote:
>>> na tej samej zasadzie mozna by zapytac o kolejnosc sekcji: public,
>>> protected i private czy tez odwrotnie...
>>
>> Znane mi standardy kodowania sugerują najpierw public, potem protected
>> i na końcu private - ta kolejność wynika z tego, że czytelnik, który
>> zwykle jest użytkownikiem klasy, najbardziej jest zainteresowany
>> publicznym interfejsem, więc jest sens go napisać na początku.
>
> zapytam tak, czy sa to sztywne standardy kodowania czy nie sa to raczej
> luzne sugestie na ten temat? nie zawsze czytelnik jest zainteresowany
> sekcja public,

Ale najczęściej jest. Rzadziej jest zainteresowany sekcją protected,
czyli dostępną jedynie dla klas pochodnych. Próbujesz na siłę wymyślać
przykłady.

>>> a gdzie typedefy w tym
>>> wszystkim.
>>
>> To zależy, czy są publiczne, czy nie, bo patrz wyżej.
>>
>>> niekiedy chcac przestrzegac z gory ustalonych regul robi sie
>>> straszny bajzel w .h.
>>
>> Właśnie po to są te reguły, żeby bajzlu nie było.
>
> wlasnie z tym standardem robi sie niekiedy niezly bajzel, 3 sekcje,
> kazda z seria funkcji, typedef'ow, niekiedy dodatkowych struct'ow i
> enum'ow.

Odłóż apostrof, bo sobie nim oko wybijesz.
http://poradnia.pwn.pl/lista.php?id=6142

> czasem chcialo by sie miec typedefy razem, enumy i dodatkowe
> struct'y tez razem. chyba, ze ktos lubi scrollowac mamrtoatac pod nosem
> 'ten enum w protected to byl gdzies pod ta cala kopa public a przed tymi
> typedefami z private, nosz szlag, gdziez on jest...' [tego oczywiscie
> nie traktowac grobowo powaznie, bo jest ctrl+f ;]

Po to są standardy, żeby zawczasu ustalić jak to ma wyglądać i żeby
programista wiedział czego się spodziewać. Lepiej czasem poprzewijać niż
za każdym razem się zastanawiać gdzie jest opis struktury danych.

--
Secunia non olet.
Stanislaw Klekot

do góry

> A ja masz typy wyliczeniowe, struktury.
Często robiłem jeden plik inkludowany globalnie z (prawie) wszystkimi:
typedefs
const
enum
struct
class
Nie chcę powiedzieć że używanie globalnie czegoś co jest potrzebne tylko w
kilku plikach stanowi dobrą metodę. Pierwsza wada to kompilacja wszystkiego
od nowa - ale kodu miałem z reguły mniej niż 1-2MB i kompilacja szła szybko.
Podobnie nie miałem problemów z niebezpieczeństwem przypadkowego użycia czegoś,
co było dostępne. Generalnie - nigdy nie żałowałem że taki projekt zrobiłem.
Pozdrawiam




--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry