code review

Nazywanie commitów

Posted on Updated on

Przeniesiono na : https://krzysztofmorcinek.wordpress.com/2017/03/10/nazywanie-commitow/

Advertisements

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.

Code Review a spacje i inne pierdoły

Posted on Updated on

Chodzi o taką sprawę:

couple random spaces in Code Review

Te ciemno zielone to kilka dodatkowych spacji, które się pojawiło (a nie było ich wcześniej). (Inne to np, dodatkowo zbędna, podwójna linia, brak pustej linii, brak spacji w parametrach lub zbyt duża ich liczba, itp, itd.)

Przypadkowo podczas pracy nad kodem gdzieś się pojawiło kilka spacji za dużo lub za mało. Czy chcielibyśmy przypieprzać się do takich rzeczy na Code Review? – nie bardzo, są ciekawsze rzeczy do kminienia. Jak unikać takich przeszkadzajek.

  • Formatować kod przed commitem, a najlepiej na bieżąco, skrót Ctrl+k, Ctrl+d.
  • Jeśli powyższego nie możemy zrobić, bo ogólnie cały kod jest syfiasty gdy chodzi o wcięcią/formatowani to możemy formatować tylko kod który dodaliśmy. Zaznaczamy kod i ten sam skrót. To akurat robię rzadko.
  • Jeśli już nie możemy (albo nie chcemy) korzystać z automatycznego formatowania to przed pushowaniem do centralnego repozytorium powinniśmy oczyścić commity z takich przeszkadzajem (git rebase interactive)
  • Już naprawdę w ostateczności gdy nic z powyższych nie podziałało to podczas tworzenia pull requesta (obszerny opis o co w tym biega na przykładzie Git/BitBucketa) zobaczmy wszystkie nasze zmiany. Na tym etapie wyłapiemy te pierdoły, na które będzie tracił czas każdy robiący Code Review (a czasem jest to kilka osób, których czas byśmy zmarnowali).

Innym podejściem jest włączeniem do projektu StyleCopa. Dzięki temu wymusimy pewne standardy formatowania, czyli brudną robotę odwali za nas narzędzie.

CodeReview

Posted on Updated on

Komentarze jakie dostaję gdy odbieram Code Review. Nie wszystkie są ogólne na tyle że pasują wszędzie ale wszystkie warte chwili “zadumy”.

  • Zawsze wasy przy ifach

    jesli jest samo return; to wtedy mozna onliner:

    if(!valid) { return; }
    
  • The verb in method name is missing? This method is names like it was a property.

    int CountByUserId(int userId);
    
  • Id vs identifier

    trzymaj sie jednej koncepcji nazewniczek. Id jest bardziej popularne. Jest też krótsze i nie traci przy tym znaczenia – nie pomyli się z niczym innym.

  • against… use …

    english is important …

  • When you are setting multiple conditions with LINQ it’s better to split them into multiple Where statements (for the sake of easier line breaking at least). Rather than

    jobj.Properties().Any(x => x.Name == "id" && x.Value.Type == JTokenType.Integer)
    

    you could do something like

    jobj.Properties().Where(x => x.Name == "id").Any(x => x.Value.Type == JTokenType.Integer)
    
  • Maybe it’d be better to rename this value to searchQuery or just query?

    Trzeba się upewnić, że wszystkie wystąpienia których Resharper nie wyłapie też są zmienione. Np przejść przez wiele warstw.

  • Use an underscore for irrelevant lambda parameters

    button.Click += (_, __) => HandleClick();
    
  • Use US-English instead of UK-English

  • Add braces around every comparison condition, but don’t add braces around a singular condition. For example if (!string.IsNullOrEmpty(str) && (str != “new”))