Skip to content

Nazwy – ZK #6

Stosowanie nazw opisowych

Nazwa dla zmiennej, metody czy też klasy ma większe znaczenie niż mogłoby się wydawać. Musimy pilnować, aby były to nazwy opisowe! Niezmiernie często stajemy przed koniecznością spojrzenia na kod już napisany, szczególnie w przypadku nieco większych projektów. Życzę powodzenia w rozszyfrowaniu nazw zmiennych jak tmp, temp, x, y, r etc. Powołując się na Czysty Kod wujka Boba to właśnie nazwy wpływają w 90 procentach na czytelność kodu. Przykładowo:

    // Takie coś
    private TrainingMapFragment m;
    private TrainingBottomFragment b;
    private Location loc;
    
    // Powinniśmy zamienić na przykładowo
    private TrainingMapFragment mapFragment;
    private TrainingBottomFragment bottomFragment;
    private Location location;

    // To samo tyczy się poniższej sytuacji
    int x = taxCalculator.calculateTaxValue(price, vat);
    int taxValue = taxCalculator.calculateTaxValue(price, vat);

 Nazwy na odpowiednim poziomie abstrakcji

Powinniśmy starać się wybierać nazwy na tym samym poziomie abstrakcji. Jest to rzecz, z którą mam chyba największy problem (oprócz lenistwa, które często owocuje różnymi niezbyt pięknymi babolami wyglądającymi niczym domek z kart posklejany taśmą klejącą). Podam przykład z aplikacji, nad którą obecnie pracuje:

    public void startTraining() {
        trainingStatus = TrainingStatusType.STARTED;
        mapFragment.startLocating();
        stopwatch.start();
    }

    public void resumeTraining() {
        trainingStatus = TrainingStatusType.STARTED;
        mapFragment.startLocating();
        stopwatch.resume();
    }

    public void pauseTraining() {
        trainingStatus = TrainingStatusType.PAUSED;
        mapFragment.stopLocating();
        stopwatch.pause();
    }

    public void stopTraining() {
        trainingStatus = TrainingStatusType.STOPPED;
        mapFragment.stopLocating();
        stopwatch.stop();
    }

Staram się utrzymywać nazwy na tym samym poziomie abstrakcji poprzez trzymanie się odpowiednich konwencji nazewniczych, które są spójne i dobrze pasują do zamierzonego celu. W ciele metod również widać o czym mówię:

    public void startTraining() {
        trainingStatus = TrainingStatusType.STARTED;
        mapFragment.startLocating();
        stopwatch.start();
    }

    public void resumeTraining() {
        trainingStatus = TrainingStatusType.STARTED;
        mapFragment.startLocating();
        stopwatch.resume();
    }

    public void pauseTraining() {
        trainingStatus = TrainingStatusType.PAUSED;
        mapFragment.stopLocating();
        stopwatch.pause();
    }

    public void stopTraining() {
        trainingStatus = TrainingStatusType.STOPPED;
        mapFragment.stopLocating();
        stopwatch.stop();
    }

Wydaje mi się, że nazwy są klarowne i łatwe w zrozumieniu, zawierając się dalej w odpowiednim poziomie abstrakcji. Pomieszany poziom abstrakcji mógłby wyglądać następująco:

    public void train() {
        trainingStatus = TrainingStatusType.STARTED;
        mapFragment.start();
        stopwatch.count();
    }

    public void resume() {
        trainingStatus = TrainingStatusType.STARTED;
        mapFragment.startLocating();
        stopwatch.resume();
    }

    public void pauseTraining() {
        trainingStatus = TrainingStatusType.PAUSED;
        mapFragment.stopLocating();
        stopwatch.pause();
    }

    public void stop() {
        trainingStatus = TrainingStatusType.STOPPED;
        mapFragment.stopLocating();
        stopwatch.stopCounting();
    }

Jednoznaczne nazwy

Powinniśmy starać się nadawać w tworzonym przez nas kodzie tylko nazwy, które są mocno jednoznaczne. Nie chcemy przecież, żeby zostały przez kogoś źle zinterpretowane lub wprowadzały w błąd. Często stajemy przecież przed sytuacją, w której pewna metoda wydaje się nam robić coś konkretnego, a tak naprawdę wykonuję nieco inną (a w skrajnych przypadkach całkowicie odmienną) czynność. Minuta ciszy dla programistów, którzy stanęli w tej sytuacji. a projekt nie posiadał przynajmniej rzetelnej dokumentacji. Nie powinniśmy także ukrywać efektów ubocznych, które mogą zostać wywołane przez nasze metody. Przykładowo mając metodę, która pobiera pewien zasób, a w przypadku gdy jest on null to tworzy nowy obiekt, nie powinniśmy jej nazywać po prostu  getResource(), a raczej createOrReturnResource().

 

Facebooktwitterredditlinkedinmail
Published inProgramowanie