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.






5 reakcí

Neřekl bych, že týmové konvence jsou nějak výrazně důležitější. Týmy totiž nemívají pořád stejné složení a když ti vývojáři přichází a odchází, tak je prostě výhodnější mít zavedený PEP8, na který si jednou zvykneš a už nikdy nemusíš nikoho nic učit.

'PEP8 dodržuju až na pár drobností'... pokud tohle rekne v tymu kazdy, pricemz kazdy bude nedodrzovat jinych 'par drobnosti', tak PEP-8 vlastne (pri trose fantasie) vsichni dodrzujete, ale ve vysledku vubec neexistuje.

Myslím, že to co máš v posledním odstavci, s tím jsi měl přijít na začátku celé aféry. To je správné řešení. Veřejný kód, tuplem ten osvětový, musí být v PEP8. Interní věci, firemní věci, hobby projekty, atd., ať si přece píše kdo jak chce a jak se vzájemně domluví. Tady se ale jedná o obecné články, ne interní dokumentaci týmu. Na takovém veřejném poli je tvým týmem ne Seznam, nýbrž "celá Python veřejnost". Domluvou tohoto velkého týmu je PEP8 a ty jsi jej nedodržel. Proto se na tebe kolegové Pythonisti zlobí, úplně stejně, jako by se na tebe zlobili kolegové v práci, kdybys jim to tam najednou začal sázet v podtržítkách.

To nejdůležitější ponaučení tam chybí, tak jestli mohu: "Při psaní pro kohokoli je potřeba respektovat jeho styl uvažování." Někteří programátoři bývají často až "binárně radikální" a vidí leccos jen černě nebo bíle. Občas pak udělají z komára velblouda. Takže: v článcích pro Zdroják dodržovat konvence, vyhýbat se nejednoznačnostem, nadsázku a vtip jasně označit, a hlavně: s nikým se v komentářích nedohadovat! :) nejjistější odpověď je "děkuju za upozornění, v článku to opravím, omlouvám se".

Ať se s psaním daří.

@yedpodtrzitko: Zkus ten článek dočíst, prosím.

@HonzaJavorek: Však já z toho aféru nedělal a zbytek jsem přepsal do PEP8. Ale chtěl jsem se k tomu vyjádřit, protože tam (ehm) pár lidí dělalo, jako by mělo už jenom kvůli myšlence nedodržet PEP8 umřít koťátko.

@adent: Díky. :)





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

en Makefile with Python, November 6, 2017
en Fast JSON Schema for Python, October 1, 2018
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

Další články z kategorie code.
Nenechte si ujít nové články díky Atom/RSS kanálu.



Poslední příspěvky

cs Zápisky z cest: Šumava, November 24, 2024 in travel
cs O klimatizaci, November 10, 2024 in family
cs První slůvka, November 3, 2024 in family
cs Jakou knihu čteš?, October 12, 2024 in family
cs V kolik chodíte spát?, September 29, 2024 in family