Prawdopodobnie dostanę od pracodawcy program do napisania (C#, .NET). Czego użyć i jak, by pracodawca był zadowolony z mojego stylu. Na pewno w grę wchodzą standardy, co jeszcze?
0
0
Jaki to pracodawca i czego sie po nim spodziewasz? Generalnie pytanie - czego pracodawca wymaga. Jak samego programu wykonywalnego, to nic mu do Twojego kodu (chyba, ze za to placi). Jesli kod zrodlowy to pytanie czy ma jakies wymagania, czy ktos bedzie po Tobie poprawial, czy Ty bedziesz to za rok poprawial, itp.
Na pewno w grę wchodzą standardy
Standardy czego?
Inna sprawa jest miec dobre nawyki, by w razie poprawek moc szybko i sprawnie program aktualizowac. Problemy ze stylem programowania wychodza glownie wlasnie w momencie, kiedy trzeba cos w aplikacji zmienic.
0
W dziedzinie tworzenia kodu (czyt. pisania) nie ma standardów. Mówimy raczej o "Best Practices", czyli o zbiorze ogólnych zasad, metod i koncepcji związanych z wytwarzaniem kodu.
Niewątpliwie do podstawowych należą:
- komentowanie kodu, im dokładniej tym lepiej
- implementacja w oparciu o interfejsy
- a jak interfejsy to i testy jednostkowe, enkapsulacja, itp
- logiczne rozplanowanie pakietów, namespace'ów itp. Model w jednym miejscu, kontrolery gdzie indziej
- MVC w domu i zagrodzie, czyli użycie wzorców
- dokumentacja kodu poza komentarzami. Warto dołączyć schematy UML najważniejszych miejsc związanych z logiką biznesową.
Wadą takiego podejścia jest ogromna czasochłonność dla elementów dodatkowych takich jak np. dokumentacja.
0
Dzięki z odpowiedzi. Co do standarów, chodziło mi np. o właściwe nazywanie zmiennych etc.
Aha, zapomniałem dodać, że to program na rozmowę kwalifikacyjną ;)
0
Jeśli chodzi o Javę to http://java.sun.com/docs/codeconv/CodeConventions.pdf
a C# np. http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx
0
Co do nazywania zmiennych to ci pracodawcy, u ktorych pracowalem zwykle mieli swoje. Jesli nie wiesz jakie preferuje pracodawca to wazne, zeby Twoje nazewnictwo bylo przejrzyste, jasne i zeby szlo sie szybko polapac czego dotyczy zmienna. Konwencje nazewnictwa roznia sie szczegolami (styl wielbladzi, z malej, z duzej, itp), ale kazda chyba trzyma sie podstawowych zasad:
- lepsze nazwy dluzsze niz za krotkie, np. nazwy typu z1, z2, mw5 odpadaja
- nazwy powinny sugerowac cel, w jakim zostala stworzona zmienna, funkcja, metoda, np. getElementAt(), ItemsContainer, ItemsList
- mile widziane standardowe przedrostki typu get, set, do, dispose, run, itp.
A jak uzyjesz tych zalecen, ktore podal hurikhan to raczej nikt o zdrowych zmyslach nie przyczepi sie, ze on woli metody z malej, a nie duzej litery.
0
Jeszcze odnośnie komentarzy - w interfejsach komentarze wystarczająco szczegółowe, aby były dokumantacją używania tego interfejsu (do wygenerowania dobrego np. JavaDocu). Muszą dokumentować też przypadki brzegowe, np. co się stanie, gdy jakiś parametr ustawisz na null.
W implementacji, jeśli musisz wszystko komentować, to najprawdopodobniej coś jest z nią nie tak.
Generalnie komentarze w implementacji powinny ograniczać się głównie do wyjaśnienia DLACZEGO ten kod tak wygląda, a w mniejszym stopniu CO ROBI. Kod powinien dać się zrozumieć bez komentarzy.
No i jeszcze jedną ważną rzeczą jest konsekwencja. Dotyczy to nie tylko konsekwentnego nazewnictwa, ale np. takich drobiazgów jak kolejność argumentów w metodach. Ostatnio parę godzin trwało rozwiązanie problemu spowodowanego 2 metodami pewnego interfejsu:
List findProducts(List types, List categories)
List findProductsEx(List categories, List types).
Miałem ochotę posiekać tego, kto to napisał. Dobrze, że gość jest z innej firmy.
Odnośnie dokumentacji - dobrze jest jakąś mieć, ale musi być krótka i zwięzła. Dokumentacja produkowana w niektórych dużych projektach klasy "E" ;) (tysiące stron) ma na ogół wartość makulatury. Im dłuższa dokumentacja tym więcej w niej błędów i tym trudniej je zauważyć.
0
Z dokumentacja nie ma problemow, jezeli uzywa sie takich rzeczy jak Doxygen - troche wiecej uwagi przy komentowaniu kodu, ale to lepsze niz pisac dokumentacje recznie.
0
Doxygen czy Javadoc nie rozwiązują wszystkich problemów. Parę razy miałem do czynienia z projektami na kilkaset tys. linii, gdzie jedyna dokumentacja była w kodzie i naprawdę trudno było się w czymś takim połapać. Powinna być jakaś ogólna dokumentacja wprowadzająca kogoś w architekturę projektu. Szczegóły mogą być w kodzie.
0
@Krolik, a ile osób czyta dokumentację? JavaDoc nie jest najlepszym miejscem na tłumaczenie architektury, ale czasami jedynym do którego sięgają użytkownicy.
Tak sobie myślę, że całkiem niezłym i szybkim narzędziem jest UML. Rysunki można zrobić na zasadzie byle było i odesłać do dokumentacji API. Zazwyczaj średnio rozgarnięty "ork da programizta" (czyt. PM) będzie wstanie zrozumieć o co chodzi w całej zabawie.
0
Jeśli chodzi o dokumentowanie a'la doxygen, to osobiście lubię DoxyS. Zasada działania identyczna, a da się zaszaleć trochę bardziej. Jak się komuś chce, to w plikach cpp, katalogach i oddzielnych stronach da się ładnie całą architekturę wyjaśnić bez ogromnych nakładów.
0
U mnie w firmie z reguly powstawaly wpierw dokumenty opisujace architekture, w nich mniejwiecej napisane po co to i jak ma dzialac. Do tego pare diagramow machnietych, by daly ogolny zarazys i bylo ok.
Zauwazylem natomiast dwie rzeczy. Piszac dokumentacje przed stworzeniem projektu i umieszczajac w niej cala architekture najczesniej konczy sie, ze przy koncu projektu jest ona nieaktualna, bo sie w trakcie pare rzeczy pozmienialo.
Natomiast tworzac dokumentacje po skonczeniu projektu... no tutaj tez jest ciezko, bo wtedy sie nie chce, a jak sie jeszcze czas projektu przedluzyl, to po prostu nie ma na to czasu.
Ogolnie to komentuje kazda metode / procedruke paroma zdaniami co ona ma robic i to sie naprawde swietnie sprawdza, zwlaszcza w C# z xml'owym komentarzami.