PEP8 a můj názor na něj

cs v kategorii code • 5 min. čtení
Mind the age! Most likely, its content is outdated. Especially if it’s technical.

Dovolil jsem si napsat krátký seriál o Pythonu, kde jsem v prvním díle nedodržel kompletně PEP8. A to byl přesně důvod pro to, aby se rozjela smršť hádek. Některé komentáře byly trochu až drsné. Nesnažil jsem se s nikým hádat a další díly ještě přepsal, aby ukázky vyhovovaly PEP8. Nechci to však nechat být bez vyjádření.

Pokud PEP8 neznáte, možná bude dobré si ho v rychlosti proletět, aby bylo jasné, o čem je řeč. Je k nalezení na adrese http://www.python.org/dev/peps/pep-0008/.

PEP8 dobrý, ale…

Je velmi dobré se držet nějakého stylu, aby byl kód čitelný. A to není pouze jen tak. Na toto téma je velmi zajímavá přednáška Programming Style & Your Brain by Douglas Crockford, na kterou doporučuju se podívat (odpusťte mi, že odkazuju na přednášku, kde se používá JavaScript, když mluvím o Pythonu). Což je také důvod, proč si myslím, že je dobré, že Python něco takového má.

Jenže. Jenže podle mne to je až příliš konkrétní. Opravdu si myslím, že to je až příliš, protože spousta lidí to teď vidí jako něco, co se musí přesně do pontíku dodržovat. A když se to náhodou nedodrží v nějakém bodě, hned rozhořčeně píší do diskuze, jak je to špatné, když se to nedodržuje. Nebojí se pak ani říct, jak je to nečitelné či bijící do očí.

Aby mě náhodou někdo nepochopil špatně – konvece na názvy private či protected metod, pojmenování args a kwds, nemixování mezer a tabů, nepsat mezery navíc uvnitř příkazů, … vítám a vyžaduju. O tom žádná, to se musí. Bez těchto konvecí by v tom byl pěkný bordel.

Mně jde o něco jiného – o drobnosti. Například jak psát názvy nebo maximální šířka řádku.

Jak dodržuju PEP8

PEP8 se mi líbí a vyhovuje mi, takže PEP8 dodržuju až na pár drobností:

  • U názvů metod a proměnných používám camelCase (první písmeno malé),
  • nebojím se použít (pokud to zlepší čitelnost) i 80. znak na řádce (klidně i pár dalších),
  • a pokračující řádky dělím trochu jinak; místo:

    def long_function_name(
        var_one, var_two, var_three,
        var_four, var_five):
    # ...
    

    používám (pokud zahrnu i změnu v názvech):

    def longFunctionName(
        varOne, varTwo, varThree,
        varFour, varFive,
    ):
        # ...
    

A podle mého názoru to není prohřešek. Něco jiného by bylo, kdybych například mixoval tabulátory a mezery nebo před public metodu psal podtřžítko.

Co jsem se dozvěděl z komentářů

Na mé mírné úpravy jsem se dozvěděl velmi zajímavé názory!

Když jsem u názvů metod použil camelCase, dozvěděl jsem se, že z toho „docela bolí oči, že to není JavaScript“. Jestli používá hodně tříd, tak ho docela lituju.

Nebo jiná perlička: „Za camel case normálně sekám ruce. To proto, že rozlišovat identifikátory pouze na základě velikosti písmen je zaručená cesta do záhuby a zdroj zcela zbytečných chyb.“ Při psaní tříd v Pythonu dle PEP8 pozor na ruce!

Dokonce jsem se dozvěděl, že nedodržovat PEP8 je „základní chyba“. No nevím, za použití camelCase mi ještě interpret ruce neutrhl. Dokonce ani nezobrazil žádné varování. (Ani žádný jiný jazyk.) Asi to nebude tak horké, jak se tvrdí…

Myslím, že tohle málo stačí pro to, abych ukázal, jak směšné takové diskuze jsou.

Týmové konvence jsou důležitější

Mnohem důležitější, než dodržování PEP8, je dodržování domluvených konvencí v týmu. Jelikož pracuju v Seznamu, tak někdo nezapomněl do diskuze přispět s odkazem na Python klienta pro API Skliku (prostě nějaký Python kód ze Seznamu), aby ukázal, jak (ne)dodržujeme PEP8 (pro zasmání ostatním diskutujícím) a že vlastně já to nemám tak strašné. Jiný diskutující se toho chytl a smál se. Samozřejmě, jak jinak. Docela bych rád viděl jak oni dodržují PEP8 v jejich zaměstnáních.

U malých a hlavně neprofesionálních firem se to nedělá, u těch ostatních je však bežné, že se na začátku (ať už projektu nebo firmy) stanoví nějaký coding style a ten se dodržuje, aby byl kód jednotný. A je úplně jedno jaký bude; důležité je, aby s ním souhlasili všichni zúčastnění.

Například (což je i důvod zmíněného posměchu) v Seznamu na konci tříd, metod, cyklů, … používáme komentáře #endclass, #enddef, #endfor, … Já osobně tyto komentáře (u svých věcí) nepoužívám a k čitelnosti mi to nepomáhá (ale ani neubírá). Tento coding style se tu však zavedl a používá se. Jsou tu i vývojáři, kterým to přijde přínosem. Takže v práci tyto komentáře píšu a nemám s tím žádný velký problém.

V komentářích jsem našel také toto: „(…) respektuji konvence jazyka/prostředí, ve kterém dělám. Opačný přístup znamená, že jsem tam vetřelcem.“ Já na to říkám: Dodržováním konvencí jazyka mohu být vetřelcem pro tým, který má zavedený jiný coding style.

Sečteno podtrženo

Jděte se bodnout s tím z čeho vás bolí oči a za co sekáte ruce.

Jelikož to ale stejně neuděláte, budu příště na servrech, jako je Zdroják, dodržovat PEP8, ať máme všichni klid. Ve svých projektech budu ale nadále dodržovat svůj coding style a v práci budu nadále psát #endpost.



Sdílejte:   Facebook   Twitter   Reddit   Tumblr   Pinterest




Může se vám také líbit

en What Makes Good Program?, November 20, 2018
en Old Code, October 31, 2018
en Fast JSON Schema for Python, October 1, 2018
en Open Source Responsibilities, September 6, 2018
en Deployment of Python Apps, August 15, 2018


Populární v kategorii code

en Makefile with Python, November 6, 2017
en Deployment of Python Apps, August 15, 2018
cs Jasně, umím Git…, August 6, 2014
cs Checklist na zabezpečení webových aplikací, March 1, 2016
cs Pokročilé regulární výrazy, August 17, 2014