Dobre i złe praktyki w C# – część I

Na moim blogu co jakiś czas można znaleźć informacje dotyczące pisania dobrego oraz złego kodu w c#. Oprócz tego zacząłem pisać serie artykułów związanych z tą tematyką. Wiele informacji w tych artykułach można było znaleźć już wcześniej na moim blogu ale myślę, że ten cykl stanowi dobre dopełnienie i podsumowanie tego wszystkiego co piszę tutaj. Oczywiście artykuły rozszerzają tematykę, oraz zawierają więcej przykładów więc tym bardziej zachęcam do lektury.

Dziś została opublikowana pierwsza część:

http://msdn.microsoft.com/pl-pl/library/dobre-i-zle-praktyki-w-c-sharp–czesc-1.aspx

7 thoughts on “Dobre i złe praktyki w C# – część I”

  1. Time to też niewłaściwa nazwa dla właściwości. 🙂

    Gdyż sygnalizuje wymiar ale bez wskazania jednostki miary.

    Minutes, Hours, albo w przypadku właściwości reprezentującej czas w danym dniu dla jakiegoś datetime-u TimeOfDay chociażby.

  2. Oczywiście, że jest właściwa, bo zgodna z intuicyjnym (standardowym) pojmowaniem czasu, który podaje się w godzinach, minutach i sekundach. I jest to czas w obrębie konkretnej doby – zazwyczaj bieżącej.

    Szukając innego przykładu, również TimePeriod będzie adekwatną nazwą, bo będzie podawał czas zgodnie z tym, czego oczekuje się od przedziału czasu, będą to lata, miesiące, dni, godziny, minuty, sekundy.

  3. Ta twoja konwencja będzie wynikała z kontekstu który nieraz, nie dwa będzie niejednoznaczny.

    Masz klapki na oczach… to że w SQL time to TimeOfDay nie znaczy wcale, że Time to zawsze wskazanie na aktualną porę dnia.

    Period to okres, przedział to span(interwał też będzie tu bardziej odpowiednim określeniem)… i widzisz dokąd te skróty myślowe prowadzą…

    Od okresu będziesz oczekiwać powtarzalności. Jest to termin często powiązany z innym: “częstotliwością”.

    PS. Nie twierdzę że nie masz racji… że tak jest prościej… czas to czas… 🙂
    Twierdzę jedynie że można więcej informacji i oczywistości o danych przekazać stosując tylko odpowiedniejszą nazwę.

    Bo to trochę tak, jakby metodę pobierającą “ilość minionych milisekund od uruchomienia systemu” nazwać GetTickCount

  4. Try-catch wcale nie powoduje utraty wydajności :). Poza tym dla const powinno się używać capslocka ;-). Poza tym zgadzam się z zaleceniami. Dobre best-practises.

  5. Hey
    @Adam
    Co do stalych to CAPS jest OK gdy stala jest publiczna. Nie ma zdaje sie reguly ktora mowi aby uzywac caps’ow. Pascal jest najpopularniejszy wiec z tym capsem uwazalbym: http://stackoverflow.com/questions/242534/c-sharp-naming-convention-for-constants

    Try-catch moze zauwazalnie spowolnic program jesli jakis wyjatek zostal wyrzucony. Nawet bez wyrzucania wyjatku wydajnosc moze spasc ze wzgledu na brak pewnych optymalizacji ale o tym moze kiedys napisze juz w formie postu. Jesli nie potrzeba zatem lepiej unikac try-catch… Oczywiscie ma to znaczenie w systemach real-time.

Leave a Reply

Your email address will not be published.