Doporučené postupy v programování - Základní stavební prvky

# Doporučené postupy v programování ## Základní stavební prvky ### Proměnné a konstanty · Názvy · Základní datové typy #### Lubomír Bulej ##### KDSS MFF UK

# Proměnné a konstanty ## Deklarace · Inicializace · Oblast platnosti · Použití

# Deklarace proměnných

## Explicitní deklarace

- důraz na statickou kontrolu při překladu
        - byrokracie – při rychlém prototypování překáží
        - typicky statické jazyky (C/C++, Java, C#)

## Implicitní deklarace

- důraz na jednoduchost psaní běžného kódu
        - dvousečná zbraň – nedokumentuje úmysl, skrývá nekonzistentní názvy
        - typicky dynamické jazyky (Ruby, Python, PHP)

Note:

Explicitní deklarace zachycuje záměr a vytváří místo, ke kterému
        je možné vztáhnout dokumentaci. Zároveň umožňuje odhalit chyby způsobené
        nekonzistentním pojmenováváním proměnných (např. `acctNo` a `acctNum`) už při překladu.

Implicitní deklarace zjednodušuje psaní a omezuje byrokracii
        zvláště při psaní běžného kódu, ale také může způsobit řadu problémů,
        právě proto, že nedokumentuje záměr a rozsah platnosti proměnné
        nejsou na první pohled zřejmé.

Problém s explicitní deklaraci nesouvisí tolik s nutností
        proměnnou deklarovat, ale spíše s nutností (často duplicitně) specifikovat typ
        proměnné v situacích, kdy potřebujeme "pojmenovat" hodnotu jejíž
        typ může překladač snadno odvodit.

# Deklarace proměnných

## Typová informace

* statická – typ svázán s proměnnou
            - explicitní deklarace vs. typová inference
        * dynamická – typ svázán s hodnotou
            - typ proměnné určen hodnotou, netřeba deklarovat

## Ideální kombinace?

* typová inference v rámci kompilační jednotky
        * explicitní deklarace na rozhraní kompilační jednotky

Note:

V případě statického typování je typ svázán s proměnnou a při
        přiřazování hodnot je kontrolována typová kompatibilita.
        Znalost typů během překladu navíc umožňuje překladači generovat efektivnější kód.

V případě dynamického typování je typ svázán s hodnotou a proměnná
        je jenom pojmenované místo, které může hodnotu obsahovat.

Dynamické typování slouží často jako berlička v situacích, kterým
        by mnohem více slušela typová inference. Při použití typové inference
        by překladač odvodil typy proměnných od typů atributů nebo návratových
        hodnot funkcí vystupujících ve výrazech, takže by nebylo nutné typ
        deklarovat explicitně, to vše při zachování typové kontroly.

# Příklad: typová inference v C#

## Použití `var` typu pro lokální proměnné

- pozor, neoznačuje dynamický typ "variant"
        - lokální proměnné
           
          ```csharp good-code
          var count = 5;
          var message = "Hello";
          var array = new [] { 0, 1, 2 };
          var list = new List <int> ();
          ```
        - inicializace proměnné ve `for` a `foreach` cyklech
           
          ```csharp good-code
          for (var i = 1; i < 10; i++) { ... }
          foreach (var item in list) {... }
          ```
        - v příkazu `using`
           
          ```csharp good-code
          using (var file = new StreamReader ("C:\\myfile.txt")) { ... }
          ```

Note:

Více detailů viz
        - [Implicitly Typed Local Variables (C# Programming Guide)](http://msdn.microsoft.com/en-us/library/bb384061.aspx)
        - [Implicitly Typed Arrays (C# Programming Guide)](http://msdn.microsoft.com/en-us/library/bb384090.aspx)

# Inicializace proměnných

Nesprávně inicializovaná data představují jednu z nejčastějších příčin chyb.

</div>

## Nesprávná inicializace

- proměnné nebyla nikdy přiřazena žádná hodnota,
        - hodnota proměnné je zastaralá a
        - proměnná byla inicializována pouze z části.

## Chyby způsobené nesprávnou inicializací se špatně hledají

- chyba se projevuje způsobem, který s příčinou na první pohled nesouvisí
        - způsob, jakým se chyba projevuje, se může při každém spuštění lišit
        - u vícevláknových programů se snadno zamění za race condition

</div>

Note:

Chyby vzniklé v důsledku špatné inicializace mají tendenci
        projevovat se nejrůznějšími způsoby, což činí jejich hledání obtížné.
        Navíc se mohou objevit po změně v kódu, která s místem chyby vůbec nesouvisí.

Zvláštní lahůdkou jsou ukazatele – neinicializovaný ukazatel se dá
        typicky snadno odhalit u statických proměnných (tam bude automaticky
        inicializován na 0, tedy NULL), ale u proměnných alokovaných na zásobníku
        nebo heapu tento luxus není.

# Příklad: inicializace proměnných

## Oddělená deklarace, inicializace a použití

```java bad-code stretch
        // declare all variables
        int accountIndex;
        double total;
        boolean done;

// initialize all variables
        accountIndex = 0;
        total = 0.0;
        done = false;
        ...

// code using accountIndex
        ...

// code using total
        ...

// code using done
        while (!done) {
           ...
        ```

</div><div class="fragment">

## Deklarace a inicializace blízko místa použití

```java good-code stretch
        int accountIndex = 0;
        // code using accountIndex
        ...

double total = 0.0;
        // code using total
        ...

boolean done = false;
        // code using done
        while (!done) {
          ...
        ```

</div></div>

Note:

Inicializace proměnných na jednom místě vytváří dojem, že se všemi
        proměnnými se pracuje po celou dobu. Přitom např. proměnná `done` se
        používá až na konci. Než se začne vykonávat kód, který proměnnou `done`
        používá, mohla být proměnná (chybně) změněna. Navíc při změně programu
        (už jen kvůli ladění) může dojít k přidání cyklů okolo kódu, který proměnnou
        `done` používá a ta pak bude správně inicializována pouze jednou.

# Příklad: doba života proměnných

## Příliš dlouhé doby života

```java bad-code stretch
         1    // initialize all variables
         2    recordIndex = 0;
         3    total = 0;
         4    done = false;
              ...
        26    while (recordIndex < recordCount) {
        27      ...
        28      recordIndex = recordIndex + 1;
              ...

64    while (!done) {
                ...
        69      if (total > projectedTotal) {
        70        done = true;
        ```

</div><div class="fragment">

## Doba života:

- recordIndex ... 27
        - total ... 67
        - done ... 67

## Průměrná: **54**

</div></div>

Note:

Existuje nějaké číslo, které striktně oddělí špatný kód od dobrého?
        Pevná čísla nejsou známa, ale je dobře se snažit je minimalizovat.
        Mimochodem, zkuste aplikovat uvedený postup na globální proměnné.

# Jak minimalizovat VS a VLT?

## Dejte proměnným minimální viditelnost na úrovni jazyka

- nejen překladač, ale i čtenář kódu pozná, co může pustit z hlavy

## Seskupte příkazy pracující se stejnými proměnnými

- snižuje intelektuální náročnost orientace v kódu
        - zviditelňuje operace jako celky vhodné pro abstrakci

## Proměnné používané v cyklu inicializujte těsně před jeho začátkem

- usnadňuje modifikaci cyklu, jeho přesun nebo vnoření do jiného cyklu

## Hodnoty do proměnných přiřazujte těsně před použitím

- není třeba zjišťovat, kde proměnná přišla ke své hodnotě

Note:

Tato doporučení jsou důsledkem minimalizace průměrných hodnot veličin
        *variable span* a *variable live time*.

Při seskupování souvisejících příkazů je často lepší je abstrahovat
        do procedury/funkce.

Postup při stanovení nutného rozsahu platnosti proměnné se postupuje
        podobně jako při konfiguraci zabezpečení – začne se s maximálně
        restriktivním nastavením a toto se uvolňuje po nejmenších možných krocích.

# Obecná doporučení k používání proměnných

## Používejte proměnnou pouze k jednomu účelu

- znepřehledňuje kód a znesnadňuje jeho modifikaci
        - "předčasná optimalizace je kořen všeho zla"

## Vyhněte se skrytým významům hodnot proměnných

- např. timeout v ms, ale `-1` = nekonečno
        - i když je to jasné vám, nemusí to být jasné někomu jinému
        - někdy vynucené výkonem nebo omezením prostředí
            - omezený počet registrových parametrů při systémovém volání
            - zrychlení výpočtů s běžnými čísly v interpretovaných jazycích

## Systematicky odstraňujte nepoužité proměnné

- nepoužívané proměnné korelují s větší chybovostí

Note:

Časté je využívání dolních bitů ukazatelů, protože ty dnes bývají
        zarovnané na 4 bajty. Hodí se to například u interpretů jazyků, kde jsou
        potřeba rychlé operace s celými čísly. Podle dolních bitů se rozhodne,
        zda se v horní části daných 4 bajtů nachází číslo, nebo ukazatel na
        nějaký složitější objekt.

Přetěžování účelu nebo významu proměnné je špatné proto, že název
        proměnné je buď příliš obecný a nic neříkající, nebo se hodí pouze
        pro jeden typ použití a jeden význam.

# Příklad: přetížení účelu

## Použití jedné víceúčelové proměnné

```java bad-code stretch
        // compute roots of a quadratic equation
        temp = sqrt(b^2 - 4 * a * c);
        root[0] = (-b + temp) / (2 * a);
        root[1] = (-b - temp) / (2 * a);

// swap the roots
        temp = root[0];
        root[0] = root[1];
        root[1] = temp;
        ```

## Použití více jednoúčelových proměnných

```java good-code stretch
        // compute roots of a quadratic equation
        discriminant = sqrt(b^2 - 4 * a * c);
        root[0] = (-b + discriminant) / (2 * a);
        root[1] = (-b - discriminant) / (2 * a);

// swap the roots
        oldRoot = root[0];
        root[0] = root[1];
        root[1] = oldRoot;
        ```

</div>

Note:

Příklad s víceúčelovou pomocnou proměnnou obsahuje vazbu mezi
        blokem kódu pro výpočet a blokem kódu pro prohození kořenů. Při
        abstrakci těchto bloků do funkcí je nutné ještě znovu deklarovat
        pomocnou proměnnou. Navíc při modifikaci kódu může dojít ke změně
        typu pomocné proměnné, přičemž nový datový typ už se pro oba účely
        hodit nemusí.

Použití samostatné proměnné pro každý účel tyto problémy eliminuje.
        Navíc je možné tyto proměnné deklarovat a inicializovat blíže místu
        použití, což zvyšuje čitelnost a pochopitelnost kódu.

# Symbolické konstanty

## Co je konstanta?

- **Konstanta** = proměnná/hodnota již nelze za běhu programu měnit

## Umožňuje nahrazení literálů v kódu

- obecně literály libovolného typu
        - typicky především čísla a řetězce

## Proč používat konstanty?

- <abbr lang="en" title="Don't Repeat Yourself">DRY</abbr> – Don't Repeat Yourself
        - výrazně zvyšují čitelnost a srozumitelnost kódu
        - možnost parametrizace kódu v době překladu/interpretace
            - často se nezdá jako nutnost jen aby se jí vzápětí stala

</div>

Note:

David Majda: Zažil jsem programátora, kterého při programování
        systému pro správu elektronického obchodu nenapadlo definovat
        konstantu pro DPH. Několik měsíců nato se sazba DPH změnila z 22% na
        19%. Co bylo horší, toho člověka ani nenapadlo použít alespoň pro
        převrácenou hodnotu výraz `1 / 1.22` a pro jistotu všude
        psal `0.819672`.

# Názvy proměnných a konstant ## Volba názvu · Vlastnosti dobrého názvu · Doporučení

# Názvy proměnných

Název proměnné by měl přesně a úplně popisovat, co proměnná reprezentuje.

</div>

## Nejprve úplný a přesný popis...

- <span class='okay-code'>`numberOfPeopleOnTheUsOlympicTeam`</span>
        - <span class='okay-code'>`numberOfSeatsInTheStadium`</span>
        - <span class='okay-code'>`maximumNumberOfPointsInModernOlympics`</span>

</div><div class="fragment">

## ... teprve potom pohodlí

* zkrácení musí zachovat úplnost a přesnost
        * pozor na příliš obecné názvy
            - <span class='bad-code'>`x`</span>, <span class='bad-code'>`temp`</span>,
              nebo <span class='bad-code'>`i`</span> jsou málo informativní a většinou špatné

</div>

Note:

Rozumná výchozí technika pro vytváření názvů proměnných je
        prostě slovy říct, co konkrétní proměnná představuje. Někdy je to
        to nejlepší jméno, protože se dobře čte a neobsahuje zkratky a
        mnohoznačnosti. Težko se s něčím splete a dá se dobře zapamatovat,
        protože jméno je podobné konceptu, který označuje.

# Příklad: optimální délka názvu

## Přesné ale dlouhé

- <span class='okay-code'>`numberOfPeopleOnTheUsOlympicTeam`</span>
        - <span class='okay-code'>`numberOfSeatsInTheStadium`</span>

## Příliš krátké

- <span class='bad-code'>`n`</span>, <span class='bad-code'>`np`</span>, <span class='bad-code'>`ntm`</span>
        - <span class='bad-code'>`n`</span>, <span class='bad-code'>`ns`</span>, <span class='bad-code'>`nsisd`</span>

## Tak akorát

- <span class='good-code'>`numTeamMembers`</span>, <span class='good-code'>`teamMemberCount`</span>
        - <span class='good-code'>`numSeatsInStadium`</span>, <span class='good-code'>`seatCount`</span>

Note:

Najít optimální délku názvu proměnné je jako v té pohádce o chytré
        horákyni. Název nemůže být příliš dlouhý, protože se hůře píše a
        zakrývá vizuální strukturu kódu. Nemůže být ani příliš krátký,
        protože pak nedává velký smysl.

Jména jsou často tvořena podstatnými jmény, někdy s prefixem ve
        formě přídavných jmen. Jméno je pak možné krátit vypouštěním méně
        důležitých modifikátorů.

# Čemu se v názvech vyhnout

## Různým názvům s podobným významem

* Lze prohodit názvy dvou proměnných aniž by to příliš vadilo?
            - <span class="bad-code">`input`</span> a <span class="bad-code">`inputValue`</span>,
              <span class="bad-code">`fileNumber`</span> a <span class="bad-code">`fileIndex`</span>

## Názvům obsahujícím čísla

* Pokud je pole nevhodné, číslování proměnných je ještě horší.
            - <span class="bad-code">`file1`</span>,
              <span class="bad-code">`file2`</span> vs. <span class="good-code">`srcFile`</span>,
              <span class="good-code">`destFile`</span>
        * Existují (sporné) výjimky – např. souřadnice
            - v tomto případě je ale nutné obhájit tuto úroveň abstrakce

## Podobným názvům s různými významy

- názvy lišící se jedním nebo dvěma znaky nebo jen velikostí písmen
        - názvy které se podobně vyslovují

Note:

K názvům s podobným významem: analogie z algebry – maximální vs. největší prvek.

# Základní datové typy ## Logické proměnné · Výčtové typy · Ukazatele