Oglądać i przekonywać się do Gita. Wstyd, że tak niewiele osób w MOSowym świecie z niego korzysta.
Dostajemy na talerzu, za darmo w oficjalnym SDK współczesną wersję Gita, który naprawdę działa zupełnie normalnie. Tam jak na wszystkich innych dzisiejszych platformach.
Git uzupełniony o GitDesktop to świetne rozwiązanie dla każdego programisty, który przez ostatnie 30 lat choćby raz wyszedł z jaskini.

A jeżeli chodzi o GitDesktop to od ładnych kilku wersji naprawdę nie potrafię się do niczego już przyczepić. Są jeszcze funkcje dla których trzeba jeszcze otworzyć CLI ale to nie problem, bo to są rzadziej robione operacje. To co jest działa dobrze i stabilnie. Choćby dla samego podglądu historii i zmian warto mieć GitDesktop. A zaręczam, że po jakimś czasie nawet CLI-maniacy coraz częściej zaczną klikać niż klepać. Sam już się na tym łapię każdego dnia.

A jeżeli chodzi o GitDesktop to od ładnych kilku wersji naprawdę nie potrafię się do niczego już przyczepić. Są jeszcze funkcje dla których trzeba jeszcze otworzyć CLI ale to nie problem, bo to są rzadziej robione operacje.

I tak ma być. Git Desktop nie ma za zadanie "przykrywać" wszystkie pod komendy i opcje gita, a tylko bardziej te najczęstsze. Natomiast te bardziej specjalistyczne powinny być wykonywany z CLI.... Zresztą Shell jest już w najnowszej niepublicznej wersji wbudowane w okno aplikacji :)

Git uzupełniony o GitDesktop to świetne rozwiązanie dla każdego programisty, który przez ostatnie 30 lat choćby raz wyszedł z jaskini.

Moim zdaniem to nieprawda. Przy hobbystycznym projekcie, gdzie nad kodem pracuje jedna osoba, git to często podstawienie sobie nogi. Uważam, że to mocno przekombinowane narzędzie. Rozumiem, że wszystkie jego zalety wychodzą przy dużych projektach rozwijanych przez wieloosobowe zespoły, ale... właśnie. Trzymam kody na GitHubie, bo to modne, ale trochę wbrew sobie. Oczywiście to, że na klasyczną Amigę nie ma gita i za pośrednika robi Linux, czyni sprawę jeszcze mniej wygodną. Dla mnie każda chmurowa składnica plików z historią wersji jest wygodniejsza niż git.

Moim zdaniem to nieprawda. Przy hobbystycznym projekcie, gdzie nad kodem pracuje jedna osoba, git to często podstawienie sobie nogi.

Tu się niestety nie zgodzę. Osobiście zrobiłbym setki karygodnych błędów gdyby nie to, że przed scommitowaniem przeglądam zmiany. Pisząc dodaję tony tymczasowych zmian. Po zakończonej implementacji to absolutnie nie nadaje się do archiwizacji bez wyczyszczenia tego wszystkiego. Bez podglądu zmian takie czyszczenie jest niemożliwe.
Nawet robiąc coś sam często mam osobne branche na jakąś funkcjonalność. Do historii wracam niezbyt często ale jednak czasem się przydaje i bywało, że szukałem po jakiej zmianie coś mi się skopało.
Mi wystarczyłby nawet SVN ale po co skoro jest GIT, który działa świetnie, którego znajomość przydaje się poza ami-światem i którego przecież nie muszę wykorzystywać na 100% tylko w takim stopniu w jakim potrzebuję. Bardzo często (nawet 2-3 razy dziennie) przenoszę się między komputerami, ten sam kod buduję na macOS i MorphOS. Przenoszenie się z kodem w inny sposób niż przez takie repozytorium z branchami byłoby straszne.

Jakiś Git dla AmigaOS3 68k podobno się tworzy. Ktoś mnie przekonywał na jakiejś liście facebookowej, że już im prawie działa. Ale nie wiem kto i na jakiej liście, bo nie ogarniam Facebooka i nie potrafię tam do czegokolwiek wrócić.

Ostatnia aktualizacja: 11.07.2024 12:28:41 przez MDW

@Krashan

Na Amigę jest RCS. Polecam sprawdzić. Posiada wszystkie niezbędne funkcjonalności jakie posiada każdy współczesny system kontroli wersji.

Git według mnie nadaje się też do małych projektów.

@MDW

Osobiście zrobiłbym setki karygodnych błędów gdyby nie to, że przed scommitowaniem przeglądam zmiany. Pisząc dodaję tony tymczasowych zmian. Po zakończonej implementacji to absolutnie nie nadaje się do archiwizacji bez wyczyszczenia tego wszystkiego. Bez podglądu zmian takie czyszczenie jest niemożliwe.
Nawet robiąc coś sam często mam osobne branche na jakąś funkcjonalność. Do historii wracam niezbyt często ale jednak czasem się przydaje i bywało, że szukałem po jakiej zmianie coś mi się skopało.

Czy mógłbyś napisać proszę na czym polega owo czyszczenie?

Ja próbuję korzystać efektywnie z systemu kontroli wersji Git czy RCS, ale mam problem z tym, że robi mi się bałagan. Często mój kod ma błędne założenia konstrukcyjne i choćbym nie wiem jak się starał, pojawiają się poważne błędy w działaniu i muszę to poprawiać od podstaw.

Chętnie poznałbym doświadczenia z Gitem innych osób.

Halo? Czy mógłby Pan odpowiedzieć na moje pytanie?

Bardzo mnie interesuje jak inni sobie radzą z systemami kontroli wersji jak Git. A z tego co wiem, rozwija Pan swój silnik i narzędzia w C++ pod kontrolą Gita i wychodzi Panu to świetnie. Czy mógłby Pan uchylić rąbka tajemnicy takiego powodzenia Pana projektów?

U mnie wygląda to teraz zdecydowanie lepiej niż kiedyś. Przede wszystkim coraz lepiej potrafię korzystać z zewnętrznego kodu, np. do obsługi IFF.

Może dzięki poradom od doświadczonych programistów będę w stanie się więcej nauczyć jeśli chodzi o efektywne użycie Gita i RCS.

Ostatnia aktualizacja: 13.07.2024 11:02:51 przez Hexmage960

olej RCS to technologią sprzed ery kamienia jeszcze nie rozłupanego. AmigaOS korzystał z RCSa. Potem był CVS, które jest ok ale nie ma rename, potem wszedł SVN który już ma rename. Natomiast potem pomyśleli jak działać naraz w wielu osób na plikach (np. w CVS były locki żeby zabezpieczyć się przed innymi) i wymyślili GITa. Jeśli twój projekt nie wymaga branchowania (nie robisz eksperymentów na kodzie) i programujesz sam to GIT nie jest ci potrzebny ewentualnie możesz korzystać z GITa tak jak SVN/CVSa. Plusem jest kopia repo na dysku więc bez sieci jesteś się w stanie cofnąć do poprzednich zmian.

Niestety tylko MorphOS ma GITa (dzięki Widelcowi i potem aktualizacjom od piru).

Ostatnia aktualizacja: 13.07.2024 12:11:23 przez michal_zukowski

Ja myślę, że mój problem nie zależy od obranego systemu kontroli wersji. Na Amidze korzystam z RCS, a z Gita - na PC (piszę kod na PC lub przerzucam z Amigi).

RCS nie jest aż tak stary i to nie tu leży przyczyna. RCS posiada takie narzędzia jak historia, logi, tagowanie, branche, łączenie itd., wszystko czego potrzebuję.

Wrzucam mój kod, ale mam spory problem z nazewnictwem (plików i innych), jak i sprzątaniem moich Checkinów i panowaniem nad zmianami w kodzie. Stąd to moje pytanie.

Powinno być to dosyć proste: "Dodany kod joysticka", "Dodany kod rysujący", "Poprawki do kodu czytania plików 8SVX" itd. Jednak co rusz natrafiam na problemy.

Oczywiście teraz wygląda to dużo lepiej niż wcześniej i udaje mi się już powoli acz systematycznie ogarniać temacik.

Wiem, że wynikały one m.in. z braku orientacji, skupienia uwagi, co się poprawiło.

W każdym razie dziękuję za sugestie i pomoc. Bardzo to doceniam. Kontynuuję realizowanie i dokańczanie zaległych rzeczy.

Ostatnia aktualizacja: 13.07.2024 12:43:06 przez Hexmage960

Czy mógłbyś napisać proszę na czym polega owo czyszczenie?

To nic wielkiego. Po prostu robiąc jakiś element na przykład przez tydzień czy dwa wprowadza się dziesiątki tymczasowego kodu, jakichś chwilowych debug-logów, coś się zakomentowuje, dodaje w zewnętrznych plikach jakieś tymczasowe ustawienia. Gdy element działa to dawniej po prostu robiłem dwa archiwa: jedno LhA, drugie 7-Zip, do nazwy pliku dodawałem datę (przy pomocy programu Krashana o nazwie AppednDate) i leciało do katalogu z setkami takich wersji. No ale zanim się to spakuje do archiwum to trzeba powywalać te różne tymczasowe drobiazgi, ustawienia zmienione tylko dla potrzeb testu. Czasem to trwało kilka tygodni, zadanie się rozgałęziało, wymagało powrotu do silnika. Do tego wypadałoby dodać jakieś komentarze, bardziej adekwatne nazwy metod, klas, stałych, zmiennyh. Nie ma szans żebym był w stanie powiedzieć co ja przez te tygodnie tam namotałem. Robiłem więc tak, że rozpakowywałem poprzednie archiwum i robiłem "diffa" przy pomocy programu ADiffView albo MCAmiga (który jest po prostu portem linuxowego Midnight Commander - wygląda strasznie DOSowo ale ma bardzo dużo funkcji). To nie było wygodne (zwłaszcza, że te programy nie mają "merge") i bardzo tego nie lubiłem. Kilka razy prześlizgnął mi się naprawdę istotny błąd, bo nie chciało mi się tego analizować. Raz niechcący dokleił mi się znak na końcu czegoś takiego:

#define USE_MIPMAPPING

i wyszło coś takiegoL

#define USE_MIPMAPPINGa

Błąd skrajnie głupi ale nie powodował błędu kompilacji czy choćby ostrzeżenia. Efekt był taki, że kod skompilował się w wersji z wyłączonym mipmappingiem i jedna wersja dema w pewnym miejscu zauważalnie wolniej działała. Tam akurat tekstury były takie, że nie bardzo było widać "mrówczenie" się tekstur w oddali.
Dzisiaj przy commitowaniu do repozytorium Gita (nawet bez GitDesktop) od razu bym to zauważył. Nie ma szans żebym coś takiego przeoczył.

Później gdy dla MorphOS powstał Git to życie stało się łatwiejsze i takich wpadek już nigdy nie było. Prawie wszystko robi się fajnie z CLI ale przeglądanie zmian/różnic to jednak nie jest przyjemność. Autor MCAmiga na MorphZone podpowiedział, że mogę ten program podczepić do Gita jako jego standardowy difftool. I to już było faktycznie coś. Ten element przestał był koszmarem. Ale przyznam się, że gdy widzę Midnight Commandera, Norton Commandera to moja amigowa dusza krzyczy i cierpię męki straszne.

No i w tym momencie zjawia się Rafael ze swoim GitDesktop. Początkowo jeszcze ze sporymi brakami ale rokowania były obiecujące. Okazało się, że planuje zrobić taką dwukolumnową porównywarkę zmian. Akurat taką najbardziej lubię. Kilka wersji i faktycznie ją zrobił. No a teraz, kilka dużych wersji później, to już zupełnie jest bajka. Jeden klik i od razu widzę co i gdzie zmieniłem. Obiecywałem sobie, że będę używał GitDesktop tylko tyle ile będę musiał żeby nie tracić kontaktu i nie zapomnieć Gita z CLI. Ale w ogniu walki z jakimś zadaniem jednak wygoda wygrywa. Coraz częściej klikam zamiast klepać. Ale nie tracę przez to kontaktu z Gitem, bo cały czas patrzę na output GitDesktop (ma takie fajne pole). Nawet całkiem sporo się dowiedziałem o Git patrząc na to co tam GitDesktop mi pokazuje. I czuję się rozgrzeszony.

Tak więc jak widzisz, żadnych czarów nie robię, jestem raczej podstawowym użytkownikiem. Jeszcze jakieś 6 lat temu bałem się Gita i doskonale rozumiem opory ludzi przed tym narzędziem. Faktycznie można sobie zrobić krzywdę gdy się z niego korzysta... frywolnie. To moje gitowe opóźnienie w rozwoju było spowodowane tym, że dla amigowych systemów nie było Gita, a w pracy jakoś tak bardzo dziwnie trafiałem zawsze do projektów, które miały SVN. To było wręcz śmieszne, że tak mnie ten Git omijał. W końcu trafiłem do czegoś normalnego, usiadłem na tydzień do Gita, trochę go zakumałem i się przekonałem. Wtedy zacząłem na forach płakać, że nie ma Gita dla MorphOSa. Gdzieś tam ktoś coś zaczął robić ale przerwał (wręcz obraził się na MOSa) i wersja była bardzo niedorobiona. No i niedługo później Git pojawił się w oficjalnym MOS SDK. Nawet nie wiedziałem, że to jest tak spora zasługa Widelca (pojawiającego się na PPA).

Ostatnia aktualizacja: 13.07.2024 12:48:53 przez MDW

Niestety tylko MorphOS ma GITa (dzięki Widelcowi i potem aktualizacjom od piru).

Nawet nie wiedziałem, że ten Git z MOS SDK to robota Widelca.
Widelec - jeżeli to czytasz - stokrotne dzięki. Sprawiłeś, że żyje mi się znacznie lepiej.

Dziękuję Ci serdecznie za obszerną, wyczerpującą odpowiedź. Ja Gita się co prawda nie boję, ale mam głównie problem z nazywaniem rzeczy. I to odnosi się do nazw plików, a nawet struktur, funkcji bądź komunikatów wpisywanych w logu. Cały czas to przemianowuję. Problem drugi to tak jak wspomniałem błędy konstrukcyjne - przykładowo zapominam czegoś uwzględnić. Problem trzeci to protokoły funkcji (lista parametrów). Ale to akurat rozwiązuję ostatnio dodając do listy parametrów wszystkie deklaracje zmiennych lokalnych, po to by funkcja była możliwie uniwersalna.

Ja zawsze czytając cudzy kod zauważyłem, że funkcje robią po prostu to, co mają robić. W moim przypadku nie potrafiłem uzyskać chociaż takiej podstawowej rzeczy.

Jeszcze raz dzięki, drogi kolego, za tę odpowiedź. Oby Twoja porada i opis własnych doświadczeń przełożyły się na większą efektywność w mojej pracy.

Ostatnia aktualizacja: 13.07.2024 13:11:02 przez Hexmage960

mam głównie problem z nazywaniem rzeczy. I to odnosi się do nazw plików, a nawet struktur, funkcji bądź komunikatów wpisywanych w logu

Hehehe. To jest bardzo powszechny problem. Sto razy zmieniam nazwy, a i tak bardzo często nie jestem z nich zadowolony. Coś mnie trafia gdy znów muszę zakończyć nazwę klasy na "Manager", "Controller" albo "Container".
Dosłownie przedwczoraj cały dzień się zastanawiałem jak nazwać jeden z rodzajów obiektów w grze. Głupi, banalny, prostacki problem, a jednak sprawia, że mnie to irytuje. Inna lista obiektów już od roku jest nazwana tymczasowo, bo nie mam pomysłu jak to zgrabnie określić. Jest to mało istotne gdy problem dotyczy tylko nazwy klasy. Niestety tutaj też jest to widoczne dla gracza, więc nazwa powinna być sensowna przyjemniej po polsku i angielsku, oraz dawać nadzieję na sensowne tłumaczenia w innych językach (od razu wszystko robię lokalizowalne).

Nie jestem fanem wspierania się AI, ale w takich przypadkach często warto opisać w jakimś ChatGPT czego potrzebujemy i dostaniemy całkiem sensowne propozycje nazw. Nawet jeżeli z żadnej nie skorzystamy to propozycje mogą bardzo zgrabnie zainspirować.

A z tego co wiem, rozwija Pan swój silnik i narzędzia w C++ pod kontrolą Gita i wychodzi Panu to świetnie.

A tego nie możesz wiedzieć, bo nic nie udostępniam. To wszystko wcale nie musi być fajnie zorganizowane. Po prostu jest tak jak mi pasuje i jak potrafię. Oprócz sześciu dem od lat nic nie upubliczniłem (gry Fortis nie liczę, bo to było aż 14 lat temu) więc też ciężko ocenić co ja tam sobie klepię. Ale taką przyjąłem metodę - pokazuję tylko coś co jest skończone albo koniec jest bardzo bliski i na 100% pewny. W amigowym świecie (bez względu na jego odnogę) obiecanki nie są mile widziane, bo zbyt wiele razy karmiono nas różnymi bajkami.

Może dzięki poradom od doświadczonych programistów będę w stanie się więcej nauczyć jeśli chodzi o efektywne użycie Gita i RCS.

Bez przesady z tym doświadczeniem. Na przykład w AmigaOS API mógłbyś mnie wdeptać w asfalt nie zakładając nawet butów. Ja ledwo liznąłem podstawy żeby sobie stworzyć otoczenie do tego co się dzieje w oknie czy na ekranie bez użycia "obcych ciał" typu SDL. Kilka lat temu uznałem, że warto mieć taki własny kod, bo nad wszystkim się panuje. A brak panowania nad własnym tworem i uzależnianie się od cudzych rozwiązań to jest coś czego wręcz nienawidzę. Prędzej czy później to się zemści. To jest oczywiście bardzo niedzisiejsze podejście do programowania ale dzisiejszą informatykę mam dokładnie tam gdzie one mnie. To nie jest praca i na tym polega siła własnych, niekomercyjnych projektów - ja nic nie muszę, a wszystko mogę.

Ostatnia aktualizacja: 13.07.2024 14:55:40 przez MDW

... ale mam głównie problem z nazywaniem rzeczy. I to odnosi się do nazw plików, a nawet struktur, funkcji bądź komunikatów wpisywanych w logu. Cały czas to przemianowuję. Problem drugi to tak jak wspomniałem błędy konstrukcyjne - przykładowo zapominam czegoś uwzględnić. Problem trzeci to protokoły funkcji (lista parametrów). Ale to akurat rozwiązuję ostatnio dodając do listy parametrów wszystkie deklaracje zmiennych lokalnych, po to by funkcja była możliwie uniwersalna.

A ja w przeciwieństwie do MDW jestem bardzo dużym zwolennikiem w wspomaganiu się AI przy programowaniu i zdecydowanie polecam Ci używać darmowego Chat GPT czy Gemini. Zarówno do pytań o nazewnictwo, jak i o dobre praktyki programistyczne. Wklejanie swojego kodu z prośbą o propozycję o refaktor, przerobienie jest bardzo pomocne.

Przykładowo na twój trzeci problem Chat GPT coś takiego odpisał:

Takie podejście w programowaniu w języku Ansi C ma swoje wady i zalety, które warto rozważyć.
Zalety:

- Uniwersalność funkcji: Dodając wszystkie deklaracje zmiennych lokalnych do listy parametrów, funkcja może stać się bardziej uniwersalna i elastyczna, co pozwala na jej ponowne wykorzystanie w różnych kontekstach.
- Lepsza czytelność w niektórych przypadkach: Wszystkie zmienne, które są używane przez funkcję, są jawnie zadeklarowane w jej sygnaturze. Może to poprawić czytelność, ponieważ od razu widać, jakie dane są przekazywane do funkcji.
- Unikanie globalnych zmiennych: Takie podejście może pomóc w ograniczeniu używania globalnych zmiennych, co z kolei zmniejsza ryzyko błędów związanych z ich niewłaściwym użyciem.

Wady:

- Przerost sygnatury funkcji: Gdy lista parametrów jest bardzo długa, sygnatura funkcji staje się trudna do zarządzania i może być myląca. Długie listy parametrów mogą też prowadzić do błędów przy wywołaniach funkcji.
- Słaba modularność: Zamiast enkapsulować logikę i zmienne w funkcji, wyciąganie zmiennych na zewnątrz może prowadzić do mniej modularnego kodu. W efekcie funkcje mogą stawać się mniej czytelne i trudniejsze do utrzymania.
- Trudności z utrzymaniem: Kiedy zmienia się liczba lub typ zmiennych lokalnych używanych przez funkcję, trzeba również zmieniać wszystkie miejsca, w których funkcja jest wywoływana, co może prowadzić do błędów i zwiększa nakład pracy.
- Potencjalne problemy z wydajnością: Przekazywanie dużej liczby parametrów przez wartość może obniżyć wydajność programu, szczególnie jeśli są to struktury danych o dużej wielkości.

Alternatywne podejścia:

- Struktury danych: Zamiast przekazywać dużą liczbę parametrów, można zgrupować je w struktury danych. To zmniejsza liczbę parametrów i poprawia czytelność.
- Globalne zmienne z ograniczonym zakresem: Jeśli nie można uniknąć używania globalnych zmiennych, warto ograniczyć ich zakres do minimum, na przykład poprzez stosowanie static do zmiennych w plikach źródłowych.
- Podział funkcji na mniejsze: Rozbicie dużych funkcji na mniejsze, bardziej wyspecjalizowane może pomóc w zachowaniu przejrzystości i modularności.

Podsumowując, choć dodawanie wszystkich deklaracji zmiennych lokalnych do listy parametrów może w niektórych przypadkach zwiększyć uniwersalność funkcji, ma to również swoje wady. Warto zastanowić się nad alternatywnymi podejściami, które mogą lepiej spełniać potrzeby projektu i poprawiać jakość kodu.

Ciekawe, ciekawe. Jeśli chodzi o wady mojego rozwiązania trzeciego problemu (lista parametrów), to uważam że tylko pierwsza jest prawdziwa, czyli przerost "sygnatury" funkcji (ja preferuję nazwę "protokół").

Pozostałe wady nie są według mnie prawdziwe. Kiedy funkcja ma sporo istotnych parametrów, to jak najbardziej jest modularna, tzn. stanowi część którą można łączyć z dowolnymi innymi.

To rozwiązanie właśnie niweluje potrzebę modyfikacji i dodawania parametrów funkcji, ponieważ zamieszczone są tam już wszystkie potrzebne parametry (jeśli zamieści się wszystkie zmienne lokalne). Oczywiście można o czymś zapomnieć i wtedy trzeba dodać, ale to ryzyko jest zminimalizowane.

Co do wydajności to fakt, aczkolwiek tych parametrów nie jest aż tak wiele, nawet jak doda się wszystkie zmienne lokalne, więc wpływ na wydajność jest znikoma, a wygoda stosowania oraz wszechstronność funkcji wysoka.

Ogólnie jak się doda istotne parametry (można dodawać też wskaźniki do stosowanych funkcji) to funkcja jako jednostka jest w pełni konfigurowalna, przez co nie potrzeba już nic więcej.

Struktury jak najbardziej pomagają w grupowaniu większych paczek parametrów, ale często zmieniane parametry lepiej dać jako odrębne.

Chodzi o to, że na przykład funkcja printf() jest tak wygodna i elastyczna, bo pobiera parametry właśnie "luzem".

Przyznam, że nie mam konta na OpenAI i nie korzystałem z Chat GPT do tej pory. Jestem nieco sceptyczny do tego typu metod dostawania odpowiedzi na nurtujące pytania.

Dzięki za zacytowanie tej odpowiedzi Chat GPT na to zagadnienie umieszczania zmiennych lokalnych w protokole funkcji.

Ostatnia aktualizacja: 14.07.2024 10:37:51 przez Hexmage960

Pozostałe wady nie są według mnie prawdziwe. Kiedy funkcja ma sporo istotnych parametrów, to jak najbardziej jest modularna, tzn. stanowi część którą można łączyć z dowolnymi innymi.

Jak masz wątpliwości to właśnie dlatego podyskutuj z AI ona Ci wyjaśni dlaczego tak uważa. I najlepiej wkleić mu kod, ponieważ ciężko bez niego poprawnie odnieść się bo nie wiadomo co to są za parametry funkcji i do czego służą.

Ja osobiście uważam że jak coś jest do wszystkiego to jest .. do niczego.
Tutaj może mieć zastosowanie tzw zasada Single Responsibility Principle (SRP) - Zasada Pojedynczej Odpowiedzialności

Każda klasa lub moduł powinien mieć tylko jedną odpowiedzialność. W kontekście funkcji, oznacza to, że każda funkcja powinna mieć jasno określony cel i powinna wykonywać tylko jedno zadanie.
Zastosowanie: Unikaj tworzenia funkcji, które mają zbyt wiele parametrów i odpowiedzialności. Zamiast tego, podziel funkcje na mniejsze, bardziej specjalizowane jednostki, które można łatwiej testować i utrzymywać.

Ja osobiście używam max 5 parametrów dla funkcji/metod.

Ostatnia aktualizacja: 14.07.2024 11:06:37 przez Rafael/ARMO

Ja osobiście uważam że jak coś jest do wszystkiego to jest .. do niczego.
Tutaj może mieć zastosowanie tzw zasada Single Responsibility Principle (SRP) - Zasada Pojedynczej Odpowiedzialności

W pełni się z Tobą zgadzam. Funkcja nie ma robić wszystkich rzeczy, tylko jedną, najlepiej ściśle określoną i opisaną w dokumentacji. Chodzi tylko o parametry - często jest tak, że w funkcji do zmiany stanu jakiegoś elementu chciałbym móc wywołać funkcję, która rysuje ten element.

Problem polegał na tym, że zapominałem przekazać np. wskaźnik do RastPort do tej funkcji. Teraz buduję tak funkcję, by miała to co potrzebuje. Dodanie parametru to według mnie jedna z najskuteczniejszych metod, i lepiej zrobić to wcześnie, przy pisaniu funkcji.

Zatem chodzi nie o to by funkcja robiła wiele rzeczy. Chodzi o to, by można było w pełni określić środowisko jej działania.

Ostatnia aktualizacja: 14.07.2024 11:45:48 przez Hexmage960