Programowanie obiektowe (I) - Laboratorium
Podstawowe informacje - organizacja
- Środowisko kompilacyjne i uruchomieniowe (Unix, Windows, Mac OS) nie jest narzucone.
- Jeżeli ktoś w terminie oddania projektu jest nieobecny to może wysłać kod projektu e-mailem. Otrzymanie kodu e-mailem w odpowiednim terminie nie powoduje naliczenia kary pomimo że projekt nie zostanie oceniony dopóki Student nie odda go osobiście w terminie laboratorium, w sali 09.
- Projekty oddane po terminie otrzymują karę 20% punktów mniej za każdy rozpoczęty tydzień opóźnienia.
- Ocenianie projektu odbywa się w obecności autora, na komputerze dostępnym w sali laboratoryjnej (nie na własnym laptopie).
- Podczas oceniania projektu prowadzący prosi o wyjaśnienie fragmentów kodu. Jest to część również poddawana ocenie.
- W razie wątpliwości, uwag, niejasności proszę pytać prowadzącego.
- Zamiast wprowadzać dodatkowe funkcjonalności lepiej zadbać o jakość podstawowej.
- W dokumentacji wstępnej należy wykazać, że rozumie się temat projektu. Należy również podać szkic rozwiązania. Dokumentacja wstępna służy m.in. do tego aby upewnić się czy tak samo rozumiemy celowo ogólnie sformułowany temat. Jeżeli okaże się, że rozumiemy go inaczej to wyjaśnię jak należy go rozumieć. Brak dokumentacji wstępnej oznacza brak uzgodnienia tematu i może skutkować oceną 0, jeżeli student zrozumiał temat inaczej niż należało.
- W dokumentacji końcowej trzeciego projektu powinny znaleźć się: rozwinięcie tematu projektu (jak w dokumentacji wstępnej); odniesienie do dokumentacji wstępnej - co zrobiono inaczej niż planowano i dlaczego; lista stworzonych klas, opis nietrywialnych klas i pól; opis nietrywialnych algorytmów; bibliografia.
- W dokumentacjach proszę o podanie informacji organizacyjnych (autor, adres mail, temat projektu, semestr, itp.).
- W dokumentacji mile widziana jest konstruktywna krytyka. Co było ciekawe albo trudne. Co zrobilibyście inaczej następnym razem.
- Nie należy drukować kodu klas czy całego programu.
- Zalecam systematyczną pracę.
- W terminach oddawania projektu nie ma możliwości dłuższej dyskusji. Prawie całe zajęcia wtedy służą ocenie projektów.
- Tytuły adresów mailowych proszę zaczynać od '[PROI]'.
- Treść konkretnego zadania może znosić niekóre z opisanych tu punktów.
Podstawowe informacje - implementacja
- Program powinien być napisany w języku C++, nie C.
- Tworzymy kod przenośny.
- Kod powinien być uporządkowany, czytelny, sformatowany.
- Kod powinien posiadać komentarze do kluczowych i/lub skompilkowanych fragmentów.
- Program powinien być sensownie podzielony na pliki.
- Program powinien być napisany w sposób modułowy.
- Program nie powinien korzystać ze zmiennych globalnych.
- Preprocesora używamy tylko do: warunkowej kompilacji oraz dołączania plików nagłówkowych.
- Kod powinen być możliwie nieskomplikowany.
- Konieczne jest przygotowanie zestawu testów prezentujących działanie programu.
- Powinna zostać zaimplementowana przynajmniej podstawowa kontrola błędów.
- Należy korzystać ze standardowych bibliotek, a nie implementować własne rozwiązania.
- Program kompilujący się nie oznacza, że dobrze działa.
- Program działający dla jednego przypadku nie oznacza, że działa dla każdego.
- Program działający dla wielu przypadków nie oznacza, że działa dla każdego.
- Dobrze jest najpierw myśleć, później pisać.
- Bardzo pomocna jest większość 'Golden rules of programming' czy też 'Zen of programming'.
- Bardzo lubimy kwalifikator const. Czyli wszędzie tam, gdzie jest potrzebny i możliwy.
- Preferujemy preinkrementację.
- Unikamy dynamicznej alokacji pamięci.
- Jeżeli w danym zastosowaniu istnieje przyjęty zwyczaj, to używamy powszechnie przyjętych nazw, np. jeżeli tworzymy własną implementację kontenera, to powinno się go używać tak, jak kontenera standardowego, np. powinna istnieć metoda 'push_back', a nie metoda 'dodajNaKoniec'.
- Większość kodu, który Państwo piszą to kod usługowy, który powinien wykonywać pewne zadania, zwracając wynik. Komunikacja z użytkownikiem powinna odbywać się w jednym, dobrze wyodrębnionym miejscu, np. w ciele funkcji 'main()'. Przykład: implementujemy kontener, a w nim metodę 'find'. Nie powinna ona wypisywać czy znalazła i co, tylko powinna zwrócić 'coś', dzięki czemu dowiemy się czy wyszukiwanie powiodło się.
- Państwa programy powinny być interaktywne, tj. wyposażone w proste tekstowe menu pozwalające uruchamiać wskazane funkcjonalności, np. dodawać i usuwać dane.
- W kodzie programu nie używamy 'magicznych' stałych.
Ostatnia aktualizacja: 2016-03-03 17:38