Unifikacja

Jak przysiadamy do książki do chcemy by jej skład i układ tekstu był schludny, czytelny, przejrzysty. Baa nie myślimy nawet o tym więc trudno tego chcieć, my zakładamy, że tak jest. Kiedy coś nie pasuje automatycznie to wychwytujemy, zaczynamy wolniej czytać, słabiej przyswajać wiedzę/treść. Dopiero z czasem się przyzwyczajamy, przestajemy zwracać uwagę na to aż… do kolejnego miejsca które jest inne, niż linijka wyżej i linijka niżej.

Taka sama sytuacja jest z kodem, to jak my go formatujemy czy jakich przedrostów używamy i czy w ogóle używamy jest uzależnione w dużej mierze od tego czy pracujemy sami czy z zespołem. Sami mamy pewny styl, zespół może mieć inny, zaś projekt open source na github zupełnie jeszcze inny.

W takich sytuacjach najlepiej jest dostosować się do tego co jest wymagane. Zespół wymaga by wszystkie zmienne klasowe były pisane małą literką z podkreśleniem przed nazwą i odwoływanie do nich powinno następować po słowie kluczowym this i do tego nie mamy spacji tylko taby, to tak ma być. Można dyskutować nad sensem z resztą zespołu, zgłosić poprawki “ulepszenia” itp. ale nie zależnie co zrobimy to i tak nie powinniśmy ingerować w to w jaki sposób kod jest tworzony, po prostu dostosujmy się do stylu wykorzystywanym w pozostałych miejscach.

 

Niezależnie więc od tego czy piszemy dla siebie czy z zespołem, trzymajmy się jednego stylu. Jak coś nas drażni rozmawiajmy o tym, proponujmy zmiany, dochodźmy do tego dlaczego tak a nie inaczej. Może oni nas przekonają albo my ich, w najgorszym wypadku zróbmy wszystko by dojść do sytuacji win-win. Ten projekt tak, następny inaczej.

To czego nie róbmy to nie mieszajmy styli gdyż to jest to co przykuje uwagę i będzie ciężko się od tego oderwać czytając kod, wręcz… może doprowadzić do tików nerwowych ;) Ostatnio miałem właśnie przyjemność czytać taki kod, który na zmianę nazywał zmienne klasowe z wielkiej, z małej lub z przedrostkiem _. Do tego część zmiennych miała własności a część metody zwracające wartość. Do tego dochodziło losowe wykorzystanie this w kodzie poprzez this. Bardziej urozmaiconego kodu nie widziałem od dłuższego czasu.

Poniżej zamieszam kod (jedna z kilku klas, pozmieniałem tylko nazwy i uciąłem odwołania do innych klas/wyciąłem kod z try/catch), na który natrafiłem w jednym z projektów. Podobno nie było czasu i trzeba było się spieszyć z pisaniem…

public class Test 
{
    // logging etc.

    private string _ala;
    private string Jolka
    private string mariolka;

    public string Ala 
    { 
        get 
        {
            return _ala; 
        } 
        set 
        { 
            this._ala = value 
        } 
    }

    public string jolka() 
    {
        return Jolka;
    }

    public object _some_advanceCode()
    {
        try 
        {
            return this.Tektura();
        }
        catch(Exception ex) 
        {
            _log.Error(ex, "message");
        }
    }

    private object Tektura() 
    {
        try
        {
            return null;
        }
        catch(Exception ex) 
        {
            throw;
        }
    }
}

Tego się nie da czytać, to jest wyjątek na wyjątku. Nic tutaj nie jest zachowane… nic a nic. Do tego to jest jedyny kod który nie jest zgodny ze stylem z całą resztą. To bije w oczy, to powoduje, że czytając nie zastanawiam się nad kodem ale o co mu chodziło nazywając tą zmienną tak a tą tak? Czemu to jest metoda nie własność? On to gdzieś wykorzystuje dalej? No sami powiedzcie, co o tym kodzie sądzicie? Czytelny? Czy da się usnąć pewne zbędne konstrukcje?

Nawet pod presją czasu, utrzymajmy styl, unifikujmy kod, to nas nic nie kosztuje a możemy na tym dużo, bardzo dużo zyskać.