naming

Problem gdy zawsze musisz mieć namespace nawet przed klasą która jest unikalna

Posted on Updated on

Czasem tak się zdarza i odpowiedź nie jest taka oczywista.

Chodzi o przypadek gdy masz namaspace nazwany tak samo jak klasę. Możliwe że w zupełnie innym miejscu, ale zawsze. Wtedy trzeba się zdecydować czy zmieniamy nazwę klasy, czy nazwę namespace’u. Jest to taka niby pierdoła, ale w kodzie bardzo przeszkadza gdy nagle dla całkiem popularnej i często używanej klasy mamy kilka namespace’ów przed każdym jej użyciem.

Advertisements

Jaki jest dobry Folder dla trzymania Enum’ów?

Posted on

Shared

Chyba, że naturalnie wynika coś lepszego, czyli np mamy folder Orders gdzie są wszyskie encje i tam też jest enum OrderyState. Jeśli jednak nasze klasy (encje, modele, dto, …) siedzą w folderach Models, Dto itp to może Shared dla enumów będzie dobrą opcją.

Git – czasem dopiero po chwili wiesz jak dobrze nazwać

Posted on Updated on

Tak najpierw nazwałem commity:
Install angular
AngularJS TypeScript typings
Update jQuery definitions for TypeScript

A później samo do mnie doszło że lepszymi nazwami będzie:
Install angular with TypeScript typings (z połączenia dwóch pierwszych)
Update jQuery definitions for TypeScript

Dzięki funkcjonalności rebase interactive możemy pozmieniać nazwy (posklejać commity), aby było to bardziej sensowne. Opisuję jak to wyklikać z GUI.

Nazywanie zmiennych w lambdach #2 (x versuss t,p,pi…)

Posted on

Podoba mi się konwencja aby nazyw zmiennych w lambdach nazywać ‘x’, jeśli potrzeba kolejnej ‘y’, a jeśli kolejnej (nie zdażyło mi się, pewnie mało widziałem, młody jestem ;)) to ‘z’. Poniżej na przykładach. Gdy jednak uważasz że trzeba je nazwać bardziej opisowo to odsyłam do Nazywanie zmiennych w lambdach.

Zła nazwa

advisers.Single(t => t.AdviserId == adviserId);

Zła nazwa

advisers.Single(a => a.AdviserId == adviserId);

Dobra nazwa

advisers.Single(x => x.AdviserId == adviserId);

Bardzo zła nazwa (i na pewno trzeba z czymś innym kojarzyć)

interns.Single(i => i.Id == choosenInternId);

Gdy trzeba więcej ‘literek’ użyć

products.Where(x => x.Categories.Any(y => y.Id == categoryId));

Kopiowanie kodu i wędrujace złe nazwy

Ludzie kopiuja kod. Nie jest to złe samo w sobie. Np trzeba wykorzystać zgrabne kilkulinijkowe Linq w innym miejscu, a uwspólnianie kodu nie ma sensu. Przy takim kopiowaniu nie sprawdza się najczęściej czy nazwy lambd są sensowne i contractor nie stał się nagle literką h. Gdy trzymamy się konwencji x,y,z to nie zacznie nam się to rozjeżdżać.

Nazywanie zmiennych w lambdach

Posted on Updated on

Czasem się zastanawiam czy zmienne wewnątrz lambd powinny by pisane pełną nazwą czy raczej skracane. Dla porównania dwa poniższe kody:

Mapper.CreateMap<User, UserModel>()
    .MapProperty(target => target.City, source => source.Address.City)
    .MapProperty(target => target.PostalCode, source => source.Address.CityPostalCode);
Mapper.CreateMap<User, UserModel>()
    .MapProperty(x => x.City, src => src.Address.City)
    .MapProperty(x => x.PostalCode, src => src.Address.CityPostalCode);

Jest powszechnie wiadomo że nazwy zmiennych powinny być opisowe, nieskrótowe i nie powinny pozostawiać wątpliwości co do znaczenia w danym kontekście. To wszystko prawda. Zrobiłbym jednak jeden wyjątek.

W przypadku lambd forma skrócona jest lepsza, ponieważ nie chcemy aż tak skupiać się na zmiennej. Chcemy żeby była krótka (x, src) właśnie dlatego żeby nie zastanawiać się za bardzo co ona robi. Myślę o krótkich (jednolinijkowych) lambdach.

Dodatkowym atutem przemawiającym za stosowaniem niednoliterowych zmiennych jest, że w kilkulinijkowych lambdach możemy od razu rozpoznać, która zmienna jest parametrem metody anonimowej stworzonej przez lambdę, a która zmienną zadeklarowaną wewnątrz lambdy lub spoza lambdy (closure).