Month: December 2015

Odpinanie eventów (.NET) w różnych sytuacjach

Posted on Updated on

Eventy trzeba odpinać aby nie było memory leaks (opisywałem np. w Memory leaks meadow). Czyli:

Aby przypiąć nowy event handler do kontrolki możesz

c.Click += mainFormButton_Click;

oraz żeby go usunąć

c.Click -= mainFormButton_Click;

Jeśli jednak jesteśmy wewnątrz klasy zawierającej event możemy go ustawić na null, a właściwie pustego delegata.

private event Action ResetCompoundControlEvent = () => { }; 

void Detach()
{
    // ResetCompoundControlEvent = null;
    ResetCompoundControlEvent = () => { };
}

Zaczerpnięte z http://stackoverflow.com/questions/153573/how-can-i-clear-event-subscriptions-in-c

Pełniejsze tworzenie wyjątków

Posted on Updated on

ArgumentOutOfRangeException

My prefered ctor for this situation is:

public ArgumentOutOfRangeException(string paramName, object actualValue, string message)

So in this example would be (seen also in other parts of code):

throw new ArgumentOutOfRangeException("ButtonType", ButtonType, null);

Agile Taski itp

Posted on Updated on

Różne:

* Taski muszą być:). Można coś zrobić przy okazji (wtedy można dorzucić subtaska do jakiegos aktualnego taska)
* Taski refactoringi też muszą być. Ważne rzeczy które teraz widzimy może nie muszą być robione od razu w aktualnym sprincie, ale niech już będą i są widoczne

Jeśli nie tworzy się od razu taska to czasem robi się wzmiankę w jakichś tam dokumentach. Usłyszałem ostatnio ciekawą nazwę tego procederu “mieć coś na liście mentalnej”. Przyznaję się że tak mam i trzeba z tym walczyć bo to antypattern.

Jak z czasem odpuszczamy jakość

Posted on Updated on

Humor Code Review: code review and care about resources

PS. te polskie resources wcale nie sa akurat potrzebne.

Podrzucać bugi testerom

Posted on Updated on

Rozwinę później

Refactoring wyrzucający części niezmienne poza IFa

Posted on

W IF’ach powinniśmy robić tak mało jak to tylko możliwe, przykład:

if (HasInternalDocuments(AdditionalDocuments))
{
    AdditionalDocumentsGroup = new AdditionalDocumentsGroup(AdditionalDocuments);
}
else
{
    AdditionalDocumentsGroup = new AdditionalDocumentsGroup(new List<Document>());
}

To co mi się nie podoba jest zaznaczone poniżej na niebiesko. Jest to część która jest identyczna zarówno dla sekcji IF jak i ELSE. Dopiero kod podkreślony na czerwono jest różny w IF oraz ELSE i to jest miejsce którym powinniśmy “sterować” właśnie za pomocą instrukcji warunkowych.

Duplication inside IF statement
Duplication inside IF statement

Refactoring który wyrzuca to co jest “wspólne” poza instrukcję warunkową

IEnumerable<Document> internalDocuments;

if (HasInternalDocuments(AdditionalDocuments))
{
    internalDocuments = AdditionalDocuments;
}
else
{
    internalDocuments = new List<Document>();
}

AdditionalDocumentsGroup = new AdditionalDocumentsGroup(internalDocuments)

Jeszcze dalej można to zamienić na coś poniższego. Nie jest to już jednak istota tego refactoringu to syntactic sugar który nam daje .NET:

var internalDocuments = HasInternalDocuments(AdditionalDocuments)
    ? AdditionalDocuments
    : Enumerable.Empty<Document>();

AdditionalDocumentsGroup = new AdditionalDocumentsGroup(internalDocuments);

To jest taki minimalny przykład. Najgorsze są długie switche w których kopiowane są kilku linijkowe wyrażenia gdzie tak naprawdę wartość testowanej w switchu wartości ma tylko wpływ na jedną zmienną.

Refactoring prowadzi do dalszych usprawnień

Ten typ zmieniania kodu jest bardzo niedoceniany. Zazwyczaj nie chodzi tylko o to że zmienimy trochę kodu. BARDZO CZĘSTO prowadzi to do dalszych usprawnień, bo zauważyliśmy że:

  • inne warunki można rozpisać inaczej lub opuścić
  • kolejne duplikacje kodu można uwspólnić
  • w jakieś kawałki kodu nie wejdziemy nigdy

VsVim – niekorzystanie ze strzałek

Posted on

VsVim i jego vimowe podejście doskonale się sprawdza jeśli chodzi o operacje na “kodzie”. Przesuwanie, podmienianie, nawigacja – wszystko to bez użycia strzałek. Jednak jedno z narzekań jakie czasem słyszę to fakt, że ze strzałek trzeba korzystać gdy trzeba coś wybierać z menu kontekstowych lub z Resharperowych okienek. Nie jest to aż takie bolesne gdy zwróci się uwagę na kilka udogodnień.

Z menu kontekstowego można wybierać na pomocą klawiatury

Może to rzeczywiście nie być takie oczywiste ale można 🙂 Każda taka akcje ma przypisaną literkę (to ta PODKREŚLONA) po kliknięciu której odpali się akcja. Kilka przykładów:

Resharper context menu with keyboard shortcuts
“Refactor this” menu from Resharper
Resharper context menu in solution explorer
R# “Refactor this” menu from solution explorer
Context menu after right click after Visual Studio code tab
Menu po kliknięciu PPM na taba z kodem
 

W powyższych przypadkach sobie poradzimy 😀

Gdzie trzeba użyć strzałek

Niestety jest kilka miejsc gdzie się to nie uda:
WIP…