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
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.
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.
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
Gdyby była opcja edycji to bym literówki poprawił. ^^
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.
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.