Dzisiaj chciałbym podzielić się zestawem reguł, który w różnych projektach stosuję od lat. Pod to stworzyłem repozytorium https://github.com/kmorcinek/dotnet-tools-settings Korzystam ze StyleCopa od ładnych kilku lat. Jest to niezbędne narzędzie gdy stosuje się Code Review. Po prostu szkoda czasu i ludzkiej cierpliwości, żeby ręcznie wytykać komuś coś, co może wychwycić narzędzie.

Całkiem normalną sytuacją jest, gdy każdy sam sobie instaluje server bazy danych. Wtedy u każdego ta nazwa może być różna. Ktoś zainstalował wersję SQL Express, ktoś inny ma już kilka wersji SQL (2008, 2012, 2014, 2016, …) różnie nazwanych, u kogoś innego w poprzednim projekcie instancja musiała się konkretnie nazywać.

Zawsze przychodzi ten moment gdy trzeba rozwiązać buga na produkcji i jedyne co mamy to logi aplikacji. Okazuje się oczywiście, że nie ma wszystkich informacji w tych logach. Nie ma nawet całkiem podstawowych informacji...

Czy oglądając video z konferencji nie nudzicie się czasem? Może za wolno? Zdecydowanie tak. Kiedykolwiek to pokazuję to każdy się zgadza, że można przyspieszyć. Np. w youtube w prawym dolnym rogu klikamy Settings->Speed i dostaniemy wybór jak po prawej.

Angielski tytuł brzmiałby „It’s not what you read, it’s what you ignore” bo jest on tytułem znakomitego wystąpienia Scotta Hanselmana: Od siebie mogę dodać kilka rzeczy, które robię: Email prywatny w pracy jest w nieużywanej przeglądarce, więc prawdopodobieństwo jego przypadkowego przeglądania jest bardzo niskie. Wyłączenie powiadomień mailowych na komórce (zarówno głosowych jak i wizua...

Chcemy rzucić wyjątkiem, gdy mamy przypadek nieobsłużony poprzez case’y. Na przykład gdy pojawiła się nowa wartość enuma Shape. throw EnumGuard.CreateMissingEnumException(nameof(shape), shape);

Staram się automatyzować wiele rzeczy. Build skrypt przechodzący lokalnie i na serverze po każdym commit’ie to podstawa. Można to w prosty sposób zrobić. Jest jednak część rzeczy, które są zbyt trudne do automatyzacji, albo po prostu nie da się ich zautomatyzować. ...

W pliku AssemblyInfo.cs zawsze widzę dużo śmieci. Przy kilkunastu/kilkudziesięciu projektach tych śmiecie jest liniowo więcej. Może czasem niektóre z nich w Waszym kontekście są potrzebne. Moje doświadczenia są jednak takie, że ten plik mógłby być tylko jeden i wyglądać: [assembly: System.Reflection.AssemblyVersion("1.0.0")]

Tak IMHO powinien wyglądać dobrze napisany enum: public enum DocumentStatus : byte { Draft = 1, Approved = 2, UnderRevision = 3, Released = 4 } Nie enumerujemy od zera Pozbyć się wartości Undefined Dziedziczyć po byte? Czy nadawać wartości liczbowe wszystkim?