Czy zdarzyło Ci się pracować długo nad jakimś plikiem i wszystko stracić przez brak zapisania zmian? Czy to aplikacja się zawiesiła, czy może komputer. Dzięki mojej niewielkiej aplikacji autosaver ten problem zniknie.

Pierwsza z 3 części historii dotyczącej zastosowania w projekcie AutoMappera.

New year, new me… Just kidding, no running or yoga plans, but I decided to have a (temporary) break with ‘C# attributes you should know’ series and start with a brand new one – C# facts that somehow surprised me. For the first article, I will show you how (friendly looking, always helpful, good guy...) enum can become an asshole. An asshole who will steal your precious time! One enum value passed to a method, other value received! What’s goin’ on?

Today I (again) focus on the attributes that will make your debugging less painfull :). This time my scribbles should appeal to the programmers who prefer keeping their code clean (and adhere to the principle: the less ‘spare’ code the better). So grab a mug of whatever you like and take a look at DebbugerBrowsable and DebuggerDisplay. The first one may be a good alternative to DebuggerTypeProxyI described in previous post and the second one is just ‘a must’ (really!) that makes life easier.

Today I would like to introduce you to the world of attributes that helps you skip some parts of code while debugging. Most of the C# programmers probably know them well, but I realized that only a few can tell the differences between them. So, ladies and gentlemen, let me introduce you the DebuggerStepThrough and DebuggerHidden.

Recently, I had quite an interesting discussion about var keyword in C#. Basically, my interlocutor tried to convince me that using var we drastically reduce code readability, so we should only use that together with anonymous types. He also mentioned performance and that some operations cannot be done using implicit typing. Well, if you’ve been reading my blog for some time, you’ve probably spotted that I’m a big fan of vars, and I put them every time it’s possible. B...

[DebuggerTypeProxy] is very useful attribute when you have a class that inherits from another class and that one inherits from another one, and some of the classes contain collections of items and hundreds of properties that in fact are not important to you… Strictly speaking, when displaying class’ members while debugging makes you feel like quitting the job. [b]We decide how to display object while debugging[/b] Exactly! You can set a proxy that will inform debugger how you want a type to be displayed...

Wpis o tym, jakie mamy modyfikatory dostępu i jak je olać ciepłym moczem;)

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);

Najbardziej popularnym Value Object jest Money. W tym przykładzie instancje możemy tworzyć tylko poprzez metode Create() (taka fabryka). Konstruktor jest prywatny. Pewnie dla tego przykładu lepiej mieć po prostu publiczny konstruktor z dwoma parametrami, ale mam wiele przykładów innych bardziej skomplikowanych Value Objects, gdzie podejście z prywatnym konstruktorem i kilkoma fabrykami walidującymi różne przypadki ma sens.