4Developers 2015: Dobre praktyki i konwencje kodowania w ję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:
info@zalnet.pl
Skype: beata.zalewa

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.

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.

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

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

standardy – cd.
• 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().

standardy – cd.
• 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.

standardy – cd.
• 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

Wcięcia, spacje i
komentarze – cd.
• Używamy TAB dla spacji i nie używamy klawisza spacji. Definiujemy Tab Size jako 4
(Tools | Options | Text Editor | <language> | Tabs)

Wcięcia, spacje i
komentarze – cd.
• Komentarze powinny być na tym samym poziomie jak kod (nie dajemy wcięcia przed
kodem po komentarzu).

Wcięcia, spacje i
komentarze – cd.
• 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)

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)

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

Tricks – cd.

Tricks – cd.
• 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)

Tricks – cd.
“That about 25% of the hours spent writing an application are spent figuring out
ways the end user will do something wrong.” – Brian Humes
Now, 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/

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ę 
info@zalnet.pl

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (10)

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