On 06/02/2014 19:41, witek wrote:
> Mateusz Loskot wrote:
>> On Tuesday, 4 February 2014 08:07:00 UTC, Adam Wysocki wrote:
>>> [...]
>>>
>>> A jak Wy to robicie? Trzymacie się zasady "jeden plik - jedna klasa",
>>> czy
>>> raczej "jeden plik - jeden funkcjonalny moduł"?
>>
>> Jakiś czas temu gdzieś na SO napotkałem na zasadę Alexa Martelliego
>> dot. organizacji plików/modułów/pakietów w Pythonie:
>> logical unit of packaging, czyli kto kogo wymaga i używa.
>>
>> I mimo, że to Python, staram się to stosować jako zasadę
>> w organizacji kodu (jakiegokolwiek).
>> Nawet w C++, modułem może być jeden plik, para .h/.cpp jak lub więcej,
>>
>> Pozdrawiam,
>>
>
> cała teoria na dwóch stronach
> http://en.wikipedia.org/wiki/Cohesion_(computer_scie
nce)
> http://en.wikipedia.org/wiki/Coupling_(computer_prog
ramming)


IMHO, Martelli jakoś zwięźlej to ujał ;)

Pozdrawiam,
--
Mateusz Loskot, http://mateusz.loskot.net

do góry

Mateusz Łoskot wrote:
> On 06/02/2014 19:41, witek wrote:
>> Mateusz Loskot wrote:
>>> On Tuesday, 4 February 2014 08:07:00 UTC, Adam Wysocki wrote:
>>>> [...]
>>>>
>>>> A jak Wy to robicie? Trzymacie się zasady "jeden plik - jedna klasa",
>>>> czy
>>>> raczej "jeden plik - jeden funkcjonalny moduł"?
>>>
>>> Jakiś czas temu gdzieś na SO napotkałem na zasadę Alexa Martelliego
>>> dot. organizacji plików/modułów/pakietów w Pythonie:
>>> logical unit of packaging, czyli kto kogo wymaga i używa.
>>>
>>> I mimo, że to Python, staram się to stosować jako zasadę
>>> w organizacji kodu (jakiegokolwiek).
>>> Nawet w C++, modułem może być jeden plik, para .h/.cpp jak lub więcej,
>>>
>>> Pozdrawiam,
>>>
>>
>> cała teoria na dwóch stronach
>> http://en.wikipedia.org/wiki/Cohesion_(computer_scie
nce)
>> http://en.wikipedia.org/wiki/Coupling_(computer_prog
ramming)
>
>
> IMHO, Martelli jakoś zwięźlej to ujał ;)
>

znaczy się mało naukowo.

do góry

On 07/02/2014 15:59, witek wrote:
> Mateusz Łoskot wrote:
>> On 06/02/2014 19:41, witek wrote:
>>> Mateusz Loskot wrote:
>>>> On Tuesday, 4 February 2014 08:07:00 UTC, Adam Wysocki wrote:
>>>>> [...]
>>>>>
>>>>> A jak Wy to robicie? Trzymacie się zasady "jeden plik - jedna klasa",
>>>>> czy
>>>>> raczej "jeden plik - jeden funkcjonalny moduł"?
>>>>
>>>> Jakiś czas temu gdzieś na SO napotkałem na zasadę Alexa Martelliego
>>>> dot. organizacji plików/modułów/pakietów w Pythonie:
>>>> logical unit of packaging, czyli kto kogo wymaga i używa.
>>>>
>>>> I mimo, że to Python, staram się to stosować jako zasadę
>>>> w organizacji kodu (jakiegokolwiek).
>>>> Nawet w C++, modułem może być jeden plik, para .h/.cpp jak lub więcej,
>>>>
>>>> Pozdrawiam,
>>>>
>>>
>>> cała teoria na dwóch stronach
>>> http://en.wikipedia.org/wiki/Cohesion_(computer_scie
nce)
>>> http://en.wikipedia.org/wiki/Coupling_(computer_prog
ramming)
>>
>>
>> IMHO, Martelli jakoś zwięźlej to ujał ;)
>>
>
> znaczy się mało naukowo.

Nie, po prostu w przypadku pytania o pliki duże czy małe,
w/w teksty mają znikomy związek, chyba że się uściśli
o jakim rodzaju i na jakim poziomie rozpatruje się ów
zależności i powiązania wewnętrzne.

Spierałbym się, że zasady cohesion/coupling mogą być pominięte
do organizacji kodu (mogę mieć jeden wielki plik gdzie poszczególne
komponenty są luźno zależne i wew. spójne).

Pozdrawiam,
--
Mateusz Loskot, http://mateusz.loskot.net

do góry

W dniu 2014-02-04 09:07, Adam Wysocki pisze:
> Ja staram się trzymać zasady "jeden plik - jedna klasa". Jak robię jakiś
> większy moduł, to po prostu robię mu podkatalog albo namespace i dzielę
> na pliki. A jak to jest z Wami? Pytam, bo naszła mnie taka refleksja po
> poprawianiu kodu po kimś (dobrym programiście, po prostu taki ma styl).
> Jeden duży plik (tzn. dwa - .h i .cpp), w nich jedna klasa, w tej klasie
> inne klasy (reprezentujące stany), każdy stan ma swoje podstany, które też
> są w tym samym pliku... i to się rozrasta.
>
> Ja implementując coś podobnego wydzieliłbym wszystkie stany do osobnych
> plików. Nie do przesady, bo jak coś jest małe, to można to pogrupować,
> żeby nie mnożyć bytów ponad potrzeby... no ale jednak.
>
> A jak Wy to robicie? Trzymacie się zasady "jeden plik - jedna klasa", czy
> raczej "jeden plik - jeden funkcjonalny moduł"?
>
> Z ekstremalnych ciekawostek - spotkałem się z plikiem .cpp 600kB.
>
> Proszę fira i innych świrów o nie udzielanie się w wątku.
>

Zasada prosta: Cos (system/podsystem/modul) musi byc rozbite na
przynajmniej tyle plikow, ilu programistow jednoczesnie to cos modyfikuje.

--
Michal

do góry

W dniu sobota, 8 lutego 2014 15:12:21 UTC+1 użytkownik Michal Kleczek napisał:
> Zasada prosta: Cos (system/podsystem/modul) musi byc rozbite na
> przynajmniej tyle plikow, ilu programistow jednoczesnie to cos modyfikuje.

Nie wiem, skad wytrzasnalest taki dziwny pomysl. Moze jeszcze
pliki powinny sie nazywac od imion autorow, ktorzy pracuja
nad systemem?

System musi byc rozbity na tyle plikow, ile ma sens z punktu
widzenia logiki systemu, a w czasach rozproszonych systemow
kontroli wersji nic nie stoi na przeszkodzie, zeby wielu
programistow modyfikowalo jednoczesnie jeden plik.

do góry

Dla mnie celem rozbijania projektu na pliki (raczej
odpowiadajace funkcjonalnym modulom) jest usprawnienie
nawigacji po kodzie zrodlowym. Jezeli program jest dobrze
podzielony, to powinno byc latwo wyszukac definicje,
ktora nas interesuje.

Inna rzecz, ze ja sam raczej nie korzystam z jezykow
"zorientowanych obiektowo", ale kiedy zdarza mi sie
pisac programy obiektowe, to jeden plik przechowuje
albo jedna klase (i jej metody), albo "sitwe" niewielkich
"klas zaprzyjaznionych".

Jezeli idzie o liczby, to za "normalny" modul uwazam
taki, ktory sie sklada z 200-400 linii. Zazwyczaj kiedy
modul robi sie bardzo duzy (powyzej 700-800 linii) to
zapala mi sie lampka, zeby podzielic go na mniejsze,
ale nic na sile. Zdarzaja sie wielgachne moduliska,
ktorych rozbijanie rodziloby tylko nowe problemy.

Malenkie moduly mi nie przeszkadzaja, o ile ich istnienie
jest uzasadnione.

do góry

On 2014-02-08 15:12, Michal Kleczek wrote:
> Zasada prosta: Cos (system/podsystem/modul) musi byc rozbite na
> przynajmniej tyle plikow, ilu programistow jednoczesnie to cos modyfikuje.

To chyba najdziwniejsza zasada o jakiej słyszałem :) Przebija nawet
"grupowanie bo przecież mają podobne nazwy i łatwo znaleźć" przyuważonew
pewnej zabawnej firmie w okolicy :)

do góry

On Sat, 8 Feb 2014 06:36:42 -0800 (PST), g...@g...com wrote:
> W dniu sobota, 8 lutego 2014 15:12:21 UTC+1 uytkownik Michal
Kleczek nap=
> isa:
> > Zasada prosta: Cos (system/podsystem/modul) musi byc rozbite na
> > przynajmniej tyle plikow, ilu programistow jednoczesnie to cos
modyfikuje=
> .


> Nie wiem, skad wytrzasnalest taki dziwny pomysl. Moze jeszcze
> pliki powinny sie nazywac od imion autorow, ktorzy pracuja
> nad systemem?

Tego nie napisaem. W ogóle nie napisaem JAK dzieli. To zaley od
paradygmatu, jzyka i narzdzi.

> System musi byc rozbity na tyle plikow, ile ma sens z punktu
> widzenia logiki systemu, a w czasach rozproszonych systemow
> kontroli wersji nic nie stoi na przeszkodzie, zeby wielu
> programistow modyfikowalo jednoczesnie jeden plik.

Stoi. Merge jest procedura bledogenna. Ile to ja razy widziaem bdy
regresyjne spowodowane przez merge.

--
Michal

do góry

On Sat, 08 Feb 2014 20:41:20 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> On 2014-02-08 15:12, Michal Kleczek wrote:
> > Zasada prosta: Cos (system/podsystem/modul) musi byc rozbite na
> > przynajmniej tyle plikow, ilu programistow jednoczesnie to cos
modyfikuje.
> To chyba najdziwniejsza zasada o jakiej słyszałem :) Przebija nawet
> "grupowanie bo przecież mają podobne nazwy i łatwo znaleźć"
przyuważonew
> pewnej zabawnej firmie w okolicy :)

Zasada bierze się z praktycznej obserwacji i z konstatacji PO CO w
ogóle dzielić na oddzielne pliki.

--
Michal

do góry

Jeszcze raz bo cos się znaczki rozkrzaczyly :-)

On Sat, 8 Feb 2014 06:36:42 -0800 (PST), g...@g...com wrote:
> W dniu sobota, 8 lutego 2014 15:12:21 UTC+1 użytkownik Michal
Kleczek nap=
> isał:
> > Zasada prosta: Cos (system/podsystem/modul) musi byc rozbite na
> > przynajmniej tyle plikow, ilu programistow jednoczesnie to cos
modyfikuje=
> .


> Nie wiem, skad wytrzasnalest taki dziwny pomysl. Moze jeszcze
> pliki powinny sie nazywac od imion autorow, ktorzy pracuja
> nad systemem?

Tego nie napisałem. W ogóle nie napisałem JAK dzielić. To zależy od
paradygmatu, języka i narzędzi.

> System musi byc rozbity na tyle plikow, ile ma sens z punktu
> widzenia logiki systemu, a w czasach rozproszonych systemow
> kontroli wersji nic nie stoi na przeszkodzie, zeby wielu
> programistow modyfikowalo jednoczesnie jeden plik.

Stoi. Merge jest procedura bledogenna. Ile to ja widziałem błędów
represyjnych spowodowanych przez merge.

--
Michal

do góry