4Developers 2015: Dobre praktyki i konwencje kodowania w języku C# okiem kobiety - Beata Zalewa

Dobre praktyki i konwencje kodowania w języku C# okiem kobiety

BEATA ZALEWA

• Trener technologii Microsoft (MCT, MCTS, MCITP)

• Specjalista baz danych i C#• Własna firma ZALNET• Mąż, córka, pies i kot • Pasje: Nikon D90 i fotografia

Kontakt:[email protected]

Skype: beata.zalewa

@bzalewa

mailto:[email protected]

Gdyby to kobiety tworzyły oprogramowanie ...

Agenda

• Wprowadzenie• Konwencje nazewnicze i standardy• Wcięcia, spacje i komentarze• Obsługa wyjątków i logowanie• Visual Studio IDE Tips and Tricks

Wprowadzenie

• To co zostanie przedstawione w tej prezentacji wynika z mojej wiedzy i doświadczenia.

• Każdy ma prawo do własnego zdania, nie musi się zgadzać z moim. • Każdy może pisać kod, który ‘jakoś działa’. Ale pisanie’wydajnego kodu’

wymaga większego poświęcenia, doświadczenia i wielu lat nauki.

• Cechy dobrego kodu:- Bez problemu możemy nie tylko my, ale też inni go zrozumieć, nawet bez

dużej ilości komentarzy- Łatwy do utrzymania, łatwy do modyfikacji i dostosowywania- Zgodny ze standardami (ogólnie przyjętymi, zespołowymi, firmowymi itd.)

Cechy dobrego programisty

• Dobry programista to taki, który jest zbyt leniwy, aby tworzyć skomplikowane rozwiązania.

• Ekspert to taka osoba, która popełnia bardzo dużo błędów, ale w wąskiej dziedzinie wiedzy.

Idealna aplikacja

Konwencje nazewnicze i standardy

• Dlaczego wypada ich używać?• Używanie „Pascal Case” dla nazw klas, typów, struktur, konstruktorów, stałych i

metod.

Konwencje nazewnicze i standardy – cd.

• Używanie „Camel Case” dla nazw zmiennych lokalnych i parametrów w metodach i konstruktorach.


• Nazwy interfejsów powinny być poprzedzone prefiksem “I”, a następnie notacja „Pascal Case”.


• Nie zaleca się używania notacji węgierskiej do nazw zmiennych, np.– string strNazwaProduktu;– int intIloscProduktow;

• Zamiast tego używamy notacji „Camel Case” do nazywania zmiennych• Używaj opisowych i mająch znaczenie słów do nazywania zmiennych.

– Nie należy używać skrótów jako części nazwy, np. lepiej jest użyć OnButtonClick niż OnBtnClick.

• Nazwy metod tworzymy przy użyciu pary czasownik-obiekt, np. PokazProdukt().


• Nazwy plików i nazwy klas powinny być takie same.• Używamy notacji „Pascal Case” dla nazw plików. Utrzymujemy powiązane nazwy

klas w pojedynczej Bibliotece (Class Library).• Zmienne powinny być deklarowane na górze pliku, z jedną linią wolną oddzielającą je

od właściwości i metod.• Pola powinny być prywatne, właściwości publiczne.


• Elementy UI• Wcześniejsze podejście – użycie odpowiednich prefiksów, aby można łatwo było

identyfikować poszczególne elementy interfejsu użytkownika, np.- Label – lblMojaEtykieta- Button – btnCofnij- TextBox – txtMojePoleTekstowe

- Nowsze podejście – najpierw nazwa czynności jaką będzie wykonywała kontrolka, potem rodzaj kontrolki:

- Label – mojaEtykietaLabel- Button – cofnijButton- TextBox – mojePoleTekstoweTextBox

Wcięcia, spacje i komentarze

• Nawiasy klamrowe powinny być na tym samym poziomie.• Używamy jednej pustej linii do odzielenia poszczególnych

logicznych grup kodu.• Powinna być jedna i tylko jedna pusta linia pomiędzy każdą

metodą wewnątrz klasy.

Wcięcia, spacje i komentarze – cd.

• Używamy regionów (#region i endregion) do grupowania powiązanych części kodu razem.

• Skróty klawiszowe:

- CTRL + M + O - żeby zwinąć region

- CTRL + M + P - żeby rozwinąć region


• Używamy TAB dla spacji i nie używamy klawisza spacji. Definiujemy Tab Size jako 4 (Tools | Options | Text Editor | <language> | Tabs)


• Komentarze powinny być na tym samym poziomie jak kod (nie dajemy wcięcia przed kodem po komentarzu).


• Komentarze XML pozwalają na automatyczne generowanie „dokumentacji projektu”, a także ułatwiają pisanie dalszych części programu, gdyż te komentarze wyświetlane są przez IntelliSense jako podpowiedzi, opisy.

Obsługa wyjątków i logowanie

• Zawsze bądź przygotowany na najgorsze. Nawet jeśli myślisz, że Twój kod nie ma wad, bądź pewny że użytkownik je znajdzie.

• Zawsze przechwytuj wyjątki i je zapisuj. Błędy pojawią się w najbardziej nieoczekiwanym dla Ciebie momencie.

• Nigdy nie umieszczaj w kodzie pustych bloków try…catch.• Jeśli pojawi się błąd, użytkownikowi wyświetl wiadomość,

którą On zrozumie, ale bez wchodzenia w szczegóły. Szczegóły są dla programisty.

• Stosuj bloki try ...catch ... finally.

Obsługa wyjątków i logowanie– cd.

• Zawsze przechwytuj wyjątki w kolejności od bardziej szczegółowych do bardziej ogólnych.

• Kiedy ponownie przechwytujesz wyjątek, użyj instrukcji throw, która będzie zachowywała oryginalny stack trace.

• Zawsze loguj wyjątki, np. z bazy danych.• Nie używaj bardzo dużych bloków try-catch.

Umieszczaj każde zadanie w jednym bloku try—catch. To będzie pomocne w znalezieniu tej części kodu, która generuje wyjątek i zwróceniu użytkownikowi odpowiedniej wiadomości o błędzie.

Visual Studio IDE Tips and Tricks

• Skróty klawiszowe do okien:– Class View (CTRL + W + C)– Class Definition (CTRL + W + D)– Error List (CTRL + W + E)– Object Browser (CTRL + W + J)– Solution Explorer z listą projektów i plikami w bieżącym

solution (CTRL + W + S)– Task List (CTRL + W + T)– Zamknięcie bieżącej zakładki – (CTRL + F4)– Wyświetlenie IDE Navigator z pierwszym dokumentem z

wybranego okna (CTRL + TAB)

Visual Studio IDE Tips and Tricks – cd.

• Refactoring– Wyświetlanie okna dialogowego Encapsulate

Field, które pozwala na tworzenie właściwości z istniejących pól i aktualizacja wszystkich referencji to użycia nowej właściwości (CTRL + R + E)


– Wyświetlenie okna dialogowego Extract Method, które pozwala na tworzenie nowej metody z wybranego kodu (CTRL + R + M)




• Snippety– Class (class | TAB | TAB)– Constructor (ctor | TAB | TAB)– Windows - Message Box (mbox | TAB |TAB)– Console – WriteLine (cw | TAB | TAB)– Property – (prop | TAB | TAB)– Więcej snippetów( CTRL + K + X)

• Build– Build wszystkich projektów w solucji(F6 / CTRL + SHIFT + B)– Build wybranego projektu i powiązanych z nim zależności (SHIFT + F6)


“That about 25% of the hours spent writing an application are spent figuring out ways the end user will do something wrong.” – Brian HumesNow, the 25% number may be less, may be more, depends on the developer and what you are doing. Everytime we build something, we have to sit back and think of how the end-user will end up fucking it up. What they will click on, what they will write, the phrasing of questions, the language used, and how what we write could be interpreted differently. If we wrote the code like how we would use the project, well then there will be so many issues because we know how the program works, and the end user doesn’t.

http://macleodsawyer.com/2015/03/06/nine-truths-computer-programmers-know-that-most-people-dont/

http://www.quora.com/Brian-Humes

http://www.quora.com/Brian-Humes




Zasoby

• http://www.dotnetspider.com• /www.aspdotnet-suresh.com/2010/04/c-coding-standards-and-best-

programming.html• http://www.codeproject.com/Articles/539179/Some-practices-to-write-better-

Csharp-NET-code • http://www.dofactory.com/reference/csharp-coding-standards• MSDN• Szkolenia

QA

Dziękuję za uwagę [email protected]

Software

4Developers 2015: Dobre praktyki i konwencje kodowania w języku C# okiem kobiety - Beata Zalewa