Roznice w programowaniu

0

Witam, mam pytanie. Otóż napisałem prostą gierkę - zgadywanie liczb. Pierwszą wersję napisałem czysto strukturalnie, a drugą za pomocą funkcji, procedur itd. Jednak mam pytanie : kiedy lepiej programować sposobem pierwszym, a kiedy drugim. Mi się wydaje, że jak się pisze małe programiki to lepiej pierwszym, jednak kiedy chce się już coś większego napisać, to drugim. Ale chciałbym się dowiedzieć jakie jest wasze stanowisko. Bo nigdy nie pisałem większych rzeczy i chciałbym poczytać uwag bardziej doświadczonych programistów na temat jak się powinno pisać różne typy aplikacji. Póki co dla mnie bardziej natrualne jest pisanie sposobem pierwszym :).
Sposób pierwszy - http://pastebin.com/F6WkyMKc
Sposób drugi - http://pastebin.com/UqH7aFWF

0

Jeżeli to kod typu napisać>skompilować>zapomnieć, to ten pierwszy może być.

Lecz jeśli po jakimś czasie będziesz chciał coś zmienić, albo użyć starego kodu, to nie ma to jak funkcje, które przenosisz do swojego nowego programu metodą kopiego-pasta.

0

Przerobiłem tą gierkę by używała procedur i funkcji, bo chciałem owe poćwiczyć w praktyce. Ale właśnie w tym rzecz, skąd mam wiedzieć kiedy powinienem korzystać z procedur/funkcji, a kiedy z nich nie korzystać itd. Jestem całkowicie zielony ;D. Może ktoś z większym doświadczeniem mnie nakieruje jak i kiedy się powinno w określony sposób pisać, jakie to daje korzyści itd.

P.S
A rożnica między procedurą a funkcją, wiem, że funkcja zwraca coś, a procedura nie. Ale np funkcja, która zwraca string, by tylko go przypisać do jakiejś zmiennej i wyświetlić potem w programie, a procedura, która od razu wyswietla ten string to jedno i to samo. Więc także moglibyście mi powiedzieć w jakich sytuacjach lepiej używać procedur a w jakich funkcji.

0
Materion napisał(a)

A rożnica między procedurą a funkcją, wiem, że funkcja zwraca coś, a procedura nie. Ale np funkcja, która zwraca string, by tylko go przypisać do jakiejś zmiennej i wyświetlić potem w programie, a procedura, która od razu wyswietla ten string to jedno i to samo. Więc także moglibyście mi powiedzieć w jakich sytuacjach lepiej używać procedur a w jakich funkcji.

To chyba oczywiste. Funkcji potrzebujesz wtedy, gdy potrzebujesz wyniku jej działania. Chyba, że nie rozumiem problemu...

0

Funkcja, procedura, to trochę archaiczne pojęcia. Procedura to funkcja która nic nie zwraca... Równie dobrze mogłaby coś zwracać, tylko nie byłoby przechwytywane.

Ogólnie funkcji używa się żeby nie powtarzać jednego fragmentu kodu kilka razy. Używa się ich głównie dla wygody i dla estetyki.

W przypadku twojej gry procedura policzProby zamiast ustawiać flagę mogła by być funkcją i zwracać wartość, wtedy zamiast konstrukcji:

while(dzialanie){
  policzProby(a);
}

miałbyś:

while(policzProby(a)){
}

Co do sprawdzania, to też mogłaby to być funkcja zwracająca -1, jeśli podana jest za duża, 1 gdy za duża, 0 gdy równa. Właściwie to jest taka nawet funkcja w module math, czy jak to się tam w pascalu nazywało, signum(a-b) zwraca znak liczby: -1, 0, lub 1.

Poza tym w każdym wypadku porównania liczby wykonujesz: Inc(liczbaProb); Możesz to zrobić przed sprawdzeniem.

0
Razi91 napisał(a)

Funkcja, procedura, to trochę archaiczne pojęcia.

To nie jest prawda.

Razi91 napisał(a)

Procedura to funkcja która nic nie zwraca...

To jest nie do końca prawda.

Razi91 napisał(a)

Równie dobrze mogłaby coś zwracać, tylko nie byłoby przechwytywane.

To nie jest prawda.

Pojęcia funkcji i procedury są nadal obowiązujące i używane.
Funkcje i procedury są podprogramami. Funkcja zawsze zwraca jakąś wartość (nie licząc rzucania wyjątkami), procedura nigdy nie zwraca wartości.
Nawet jeśli zignorujemy wartość zwracaną przez funkcję, to i tak jest ona funkcją, a nie procedurą.

1

Twój przykładowy kod generalnie nadaje się do tylnej części ciała jeśli chodzi o sedno problemu. Jest on na tyle prosty, że po prostu sam sens dzielenia tych 50 linijek kodu na cokolwiek mija się z celem. Zalety możesz ujrzeć przy większym kodzie. Przede wszystkim w procedurę/funkcję pakuje się to, co jest wykonywane kilka razy tylko z różnymi danymi wejściowymi. W Twoim przypadku doskonałym przykładem jest np procedura WriteLn, tyle że ona jest już procedurą. Wyobraź sobie, że zamiast napisać WriteLn('tekst do wyświetlenia') miałbyś za każdym razem naskrobać np. 10 linii dokładnie takiego samego kodu, w którym zmieniało by się tylko 'tekst do wyświetlenia'.
Z drugiej strony na procedury/funkcje wkłada się kod, który stanowi logiczną (i często biznesową) całość - np. procedura wyświetlająca menu, wczytująca dane. Tak podzielony kod jest po prostu czytelniejszy.

Generalnie programowanie strukturalne/proceduralne odchodzi w zapomnienie. Na topie są teraz klasy i programowanie obiektowe. W niektórych językach (np. .net) jest wręcz wymuszone programowanie obiektowe - nie można tam zadeklarować zmiennej globalnej czy procedury/funkcji. Klasy mimo iż na początku mogą wydać się trudne do opanowania wcale takie trudne nie są. Chociaż mądre i poprawne rozbijanie problemu na klasy przychodzi z czasem.

Reasumując napisz program, który ma więcej niż 50 linijek to zobaczysz różnicę, szczególnie jak przyjdzie Ci coś poprawić w np. 20 miejscach zamiast jednym bo wolałeś w te 20 miejsc przekopiować taki sam kod zamiast zamknąć go w procedurę/funkcję

0

Moim zdaniem, generalnie w przypadku małych programów strukturalnie a proceduralnie - żadna różnica, no chyba że kod się powtarza, wtedy koniecznie proceduralnie. Ja się staram stosować generalnie proceduralnie (wtedy środowisko pomaga szukać itp. , no i jest też call stack), ale jeżeli kod jest naprawde banalny to można też strukturalnie.
A gdy pisze się coś poważnego, to stosuje się klasy (+ ew. procedury).

P.S. Random(21) daje zakres 0-20, a nie tak jak program wskazuje 1-20.

0

Tak prosty kod można napisać - według mnie - bez procedur i funkcji. Co do tego o czym pisali poprzednicy to procedura również może zwrócić wartość przez jeden ze swoich parametrów, poprzedzony słowem var lub out. Przykładem takiej procedury jest Val, którą tutaj autorowi polecam użyć, bo poza tym że losowanie powinno być na przykład w postaci Random(30) + 1; to program wywali się również jeśeli nawet niezłośliwemu użytkownikowi omsknie się palec i korzystając z nie numerycznej klawiatury (bo tak mu wygodniej lub jej nie posiada) omsknie mu się palec i wciśnie "w" zamiast 2 i tym podobne. Dlatego nie ma co się martwić czy dzielić program na procedury jak nie zadbało się dostatecznie o idiotoodpornośc kodu.

0

Podsumowując. Możesz pisać strukturalnie tak długo jak Tobie jest wygodnie. Z czasem jak będziesz pisać większe programy sam poczujesz potrzebę pisania funkcji ;]. W dalszym etapie nie będziesz mógł żyć bez programowania obiektowego. Wszystko w swoim czasie ;).
Pozdrawiam.

0

Pisać obiektowo potrafię, tworzyć klasy, ustalać pola, metody, dziedziczyć po innych klasach, polimorfizm, rzutowanie tworzyć obiekty, wywoływać itd. Na samym początku nauki programowania zająłem się C# i kupiłem do tego doskonałą książkę. Jednak pisanie w oparciu o obiektwość wymaga raczej wcześniejszego przemyślenia jak to będzie miało działać itd. No i do takich programików w ogóle się nie sprawdza :D. Dziękuję wszystkim za odpowiedzi :).

P.S
Znacie jakieś fajne stronki z kodami źródłowymi object pascala, czytając jakieś fajne kody można wiele się nauczyć jak program wygląda przy czymś większym :).

0

Z całym szacunkiem ale gdybyś naprawdę wiedział, a nie myślał że wiesz nie spytałbyś się o procedury/funkcje bo w sumie obiektowe podejście do problemu wynika właśnie z nich.

Nie chciałem jak coś cię obrazić bo sam przez długi czas myślałem że znam się na wielu rzeczach :)

0

Znacie jakieś fajne stronki z kodami źródłowymi object pascala, czytając jakieś fajne kody można wiele się nauczyć jak program wygląda przy czymś większym .

Jasne, nawet dwie :D
www.google.pl (-.-)
www.sourceforge.org

1

Unikanie powielania kodu to jedna z przyczyn. Druga, równie istotna, to tworzenie warstw abstrakcji. Łatwiej analizować i testować taki kod - zarówno za pomocą debuggera jak i ręczne.
Zamykanie kodu w obrębie jakiejś funkcji to także forma komentowania kodu. Nazwa funkcji powinna odzwierciedlać jej działanie.
Twórz funkcje wszędzie tam, gdzie potrzebny jest jakiś komentarz. Z czasem się wyrobisz i będzie potrzebował mniej komentarzy i mniej funkcji.

0
Materion napisał(a)

Znacie jakieś fajne stronki z kodami źródłowymi object pascala, czytając jakieś fajne kody można wiele się nauczyć jak program wygląda przy czymś większym :).

Poczytaj źródła VCL.
W drugiej kolejności: http://torry.net/

1 użytkowników online, w tym zalogowanych: 0, gości: 1