Někteří programátoři mají tendenci nechávat v kódu zakomentovaný kód. Ať už jsou jejich důvody jakékoliv, v následujícím příspěvku bych chtěl argumentovat, proč toto nedělat a zakomentovaný kód odstraňovat.
Neberte mě špatně - Python je skvělý jazyk. Je mým oblíbeným jazykem a programuji v něm s přestávkami od roku 2007 (někdy od verze 2.5). Žádný jazyk ale není perfektní a Python není žádnou výjimkou. V dnešním příspěvku bych se s vámi chtěl podělit o skutečnosti, které se mi na Pythonu příliš nelíbí.
Když vám váš program padá, tak je potřeba jej odladit a nalézt příčinu. Při ladění jste se již mohli setkat se situací, kdy program padá v metodě, která byla volaná přes nulový ukazatel. Přišlo vám však divné, že k pádu dojde až v těle metody, nikoliv již při volání metody. Popřípadě volání metody přes nulový ukazatel projde bez pádu. V dnešním příspěvku se dozvíte, proč k této situaci může dojít.
V dalším díle našeho seriálu o chybách v návrhu se podíváme na nešvar, kterého se mnohdy nevědomky dopouštíme: místo doménových typů k reprezentaci složených dat používáme řetězce.
Když chcete v Pythonu vyhodit výjimku, napíšete raise Exception. Od Pythonu 3 existuje méně známé rozšířená příkazu raise obsahující dodatek from AnotherException. Právě o tomto rozšíření pojednává následující příspěvek.
Někdo preferuje mezery, někdo tabelátory. Diskuse o tom, který způsob je lepší, bývají nekonečné, protože každý z nich má své pro a proti a každý programátor to vidí jinak, takže to nemá smysl řešit. V následujícím článku bych však chtěl argumentovat, proč není dobrý nápad v kódu tabelátory a mezery mixovat.
Když programátor napíše blok kódu či složitější podmínku, tak má tendenci k vytvořenému kusu kódu napsat vysvětlující komentář. Z hlediska pochopitelnosti kódu je to samozřejmě lepší, než kdyby se čtenář musel snažit pochopit význam analýzou kódu. V dnešním příspěvku si však ukážeme lepší alternativu: místo bloku kódu s komentářem napíšeme funkci.
