Strona główna Polish Python Coders Group
   Strona główna   Pomoc Zaloguj się Rejestracja  
Witamy, Gość. Zaloguj się lub zarejestruj.
Czy dotarł do Ciebie email aktywacyjny?

Zaloguj się podając nazwę użytkownika, hasło i długość sesji

Aktualności: PyCode Conference :: https://pycode-conference.org/
Szukaj Szukaj
Strony: [1]   Do dołu
Drukuj
Wątek: Czysty kod Pythona  (Przeczytany 2277 razy)
« : 19:48 15/04/18 »
jundymek Offline
Professional Python User

Zobacz profil
***

Reputacja: 4
Wiadomości: 337


Witam. Czy są jakieś książkowe pozycje w stylu "Czystego kodu" w oparciu o przykłady z Pythona? Chodzi mi o wzorce pisania "ładnego" kodu, ale na konkretnych przykładach. Jednym słowem jak pisać funkcje, klasy itp. w oparciu o wskazane wytyczne. Niby każdy pisze tak jak chce, ale coraz bardziej przekonuję się jak brzydko sklejam te moje wypociny. Moje funkcje są przede wszystkim za długie, ale wychodzi to po prostu z systemu jaki sobie przyjąłem (niekoniecznie właściwego). Jak działa to uznaję, że jest dobrze, ale chyba nie tędy droga. Ostatnio zobaczyłem jak programiści robią to samo w "poprawny" sposób i różni się to zdecydowanie od moich rozwiązać. Możecie wskazać jakieś pozycje na ten temat - książkowe i internetowe - format bez znaczenia. Byleby można było się w wolnej chwili poduczyć poprawnego kodowania Pythona. Wiem, że niby "Czysty kod" to zbiór dobrych praktyk, mających zastosowanie praktycznie w przypadku każdego języka, ale wolałbym sobie czytać konkretnie przykłady z naszego języka.
Zapisane
« Odpowiedz #1 : 21:24 15/04/18 »
Rado Offline
Hello World!

Zobacz profil
*

Reputacja: 4
Wiadomości: 27


https://www.python.org/dev/peps/pep-0008/

Nikt nie pisze jak chce tylko zgodnie ze standardami. Część kodu może CI poprawić do np w  sublime wtyczka anaconda o ile dobrze pamiętam
Zapisane
« Odpowiedz #2 : 22:15 15/04/18 »
jundymek Offline
Professional Python User

Zobacz profil
***

Reputacja: 4
Wiadomości: 337


PEP to bardziej aspekty techniczne, a mi chodzi bardziej o wytyczne w zakresie organizacji samej aplikacji. W sensie jak organizować funkcje, jak umieszczać kod rozbity na osobne pliki w aplikacji, jak poprawnie importować z innych plików. Dla przykładu funkcja może mieć 5 ifów i cała logika może znajdować się w jej wnętrzu - wtedy jedna funkcja/metoda będzie miała np. 50 linii kodu. Można też utworzyć 5 funkcji pomocniczych i odwoływać się do nich... O tego typu rozterki mi chodzi, bo jak już wspomniałeś do spraw technicznych są wtyczki (ST3), albo natywnie zaimplementowane "poprawiacze" (chociażby PyCharm).
Zapisane
« Odpowiedz #3 : 22:42 15/04/18 »
Rado Offline
Hello World!

Zobacz profil
*

Reputacja: 4
Wiadomości: 27


No nie wiem chyba PEP właśnie ten temat wyjaśnia. Do django to możesz sobie przejrzeć two scoops of django.
Zapisane
« Odpowiedz #4 : 22:47 15/04/18 »
DJangoL Offline
Professional Python User

Zobacz profil
***

Reputacja: 27
Wiadomości: 377


PEP8 to zasady poprawnego zapisu kodu, a jundymek pyta o wzorce architektoniczne


https://python-3-patterns-idioms-test.readthedocs.io/en/latest/

http://python-patterns.guide/

http://www.aleax.it/gdd_pydp.pdf

Kursy płatne:

https://www.pluralsight.com/courses/python-design-patterns

https://www.lynda.com/Python-tutorials/Design-Patterns-Python/369187-2.html
Zapisane
« Odpowiedz #5 : 23:06 15/04/18 »
Rado Offline
Hello World!

Zobacz profil
*

Reputacja: 4
Wiadomości: 27


Tak na podstawie dwóch postów Judymka i podania dla przykładu pozycji książkowej pt. "Czysty Kod" z pewnością chodziło mu o wzorce projektowe. PEP8 jest odpowiedzią dla tej książki podanej przez Niego.
two scoops of django natomiast pokazuje jak właśnie zaprojektować strukturę projektu i utrzymać całą resztę żeby syfu nie było, tyle że to tylko dla tego frameworka, ale może dla flaska też można by niektóre rzeczy zastosować. Do pisania projektu w samym  pythonie powinno wystaczyć trzymanie się PEP8.
Zapisane
« Odpowiedz #6 : 00:59 16/04/18 »
zuo Offline
Professional Python User

Zobacz profil
***

Reputacja: 129
Wiadomości: 425


PEP-8 jest o stylu. A pytanie Jundymka sięga głębiej -- do struktury, wyboru abstrakcji etc.

Sądzę, że zasadniczo postulaty z "Czystego kodu" -- niekoniecznie stosowane ortodoksyjnie, tyllko z głową (jak wszystko w programowaniu) -- są OK. Pamiętanie o postulatach DRY i KISS -- jest OK. Czytanie ciekawych materiałów -- jest OK (np. takich, jak podane wyzej przez DjangoLa). Czytanie (a tym bardziej praktyczne "przerabianie") klasycznych książek, które pomagają nakierować nasze myślenie na poziom "meta" -- takich, jak SICP -- jest OK. I uważne czytanie cudzego kodu też jest OK.

A kto wie, czy najbardziej OK nie jest dalsze dopieszczanie własnego kodu i wracanie do niego wtedy, gdy już niby działa i pojawiła się zgubna pokusa pt. "zaczęło jakoś działać, więc zostawmy jak jest".¹



¹ Wbrew pozorom nawet w pracy, gdzie obowiązują twarde terminy, takie "dopieszczanie" jest -- oczywiście z założeniem pewnych ram czasowych -- potrzebne. Tym bardziej konieczne jest przy programowaniu luźno-edukacyjnym.
Zapisane
« Odpowiedz #7 : 01:08 16/04/18 »
zuo Offline
Professional Python User

Zobacz profil
***

Reputacja: 129
Wiadomości: 425


PS. A co do samego stylu, to moim zdaniem najważniejszym fragmentem PEP-8 jest ten:

Cytuj
One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, "Readability counts".

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important.

However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable. When in doubt, use your best judgment. Look at other examples and decide what looks best.

(fragment ten znajduje się w sekcji o wiele mówiącym tytule "A Foolish Consistency is the Hobgoblin of Little Minds").
Zapisane
« Odpowiedz #8 : 09:42 16/04/18 »
lit_indyjski Offline
Hello World!

Zobacz profil
*

Reputacja: 0
Wiadomości: 1


Tak jak sam napisałeś, "Czysty kod" to zbiór dobrych praktyk. Dobre praktyki to lata doświadczenia, czytania i wnikliwego zagłębiania się w szczegóły (nawet o literówki czy podkreślenia w nazwach zmiennych).

Trochę się zejdzie ale spróbuje...


Polecam najpierw przeczytać o tych zasadach:

* KISS (keep it simple & stupid)
* DRY (dont repeat yourself)
* SOLID

Po przeczytaniu zasad powyżej natkniesz się na problem nazewnictwa i pogrupowania swoich bibliotek. Tutaj polecam spis treści głównej dokumentacji pythona:

* https://docs.python.org/3/library/index.html

i popatrzeć jak są pogrupowane moduły, jak nazwane są nagłówki i korzystać z nazw.


Nazewnictwo ze standardowej biblioteki to mało. Polecam szukanie i czytanie projektów gitowych.


Polecam:

* https://github.com/requests/requests
* https://github.com/pallets/flask/tree/master/flask
* https://github.com/kivy/kivy


Nie polecam:

* https://github.com/django/django

Oparta na wzorcu projektowym "Active record". Jednak ze względu na swoją wielkość, własny orm
cięzko się go czyta.

Mały smaczek (migracje przez property):
https://github.com/django/django/blob/stable/1.11.x/django/db/migrations/executor.py#L179


* https://github.com/odoo/odoo

tutaj mam mieszane uczucia. Pracowałem tylko do wersji 7. Z jednej strony polecam ze względu na architekture pluginową.
Dziedziczenie odbywa się przez atrybuty, a wcześniej w manifescie trzeba uwzględnić, że
chcemy korzystać z paczki X. Nadpisany jest tutaj standardowy `import` i `super()` pythonowy.
Z drugiej strony kod od strony deweloperskiej jest tragiczny (brak pep8).

Troche wiecej o samych projektach:

* https://www.reddit.com/r/learnpython/comments/7vx69y/what_are_some_examples_of_perfectly_written/

Jak nie będziesz wiedział, jak skategoryzować lub nazwać swoją klasę to szukaj w gicie jak inne projekty
to rozwiązują!

No i została architektura do omówienia.

Architektura domenowa (Domain Driven Design):

* https://github.com/valignatev/ddd-dynamic

* https://www.youtube.com/watch?v=lnTFtsc4Y58

* https://www.youtube.com/watch?v=0h9EvPI_mKA


Architektura MVC:

* https://www.youtube.com/watch?v=lERcXc2TJ7g

* https://djangobook.com/model-view-controller-design-pattern/


Architektura hexagonalna:

* http://www.dossier-andreas.net/software_architecture/ports_and_adapters.html

Architektura CQRS:

* https://github.com/ferstdigital/cqrs-python-demo

* https://bulldogjob.pl/articles/122-cqrs-i-event-sourcing-czyli-latwa-droga-do-skalowalnosci-naszych-systemow_


Architektury można mieszać, łączyć ze sobą i korzystać także jak z wzorca projektowego.
Zapisane
« Odpowiedz #9 : 03:00 17/04/18 »
Guaz Offline
Advanced Python User

Zobacz profil
**

Reputacja: 38
Płeć: Mężczyzna
Wiadomości: 286


Pozwolę sobie zacytować Linus Torvaldsa (Stworzyciela linux'a):
Cytuj
I will, in fact, claim that the difference between a bad
programmer and a good one is whether he considers his
code or his data structures more important. Bad
programmers worry about the code. Good programmers
worry about data structures and their relationships.
Dobre praktyki przyjdą same gdy wielokrotnie będziesz wracał do swojego dawno napisanego kodu, bądź patrzył na kody innych. Zarówno te 'czyste', w których będziesz wiedział co się dzieje, jak i te niechlujne, gdzie nie połapiesz się o co chodzi - a wtedy spróbuj je 'poprawić'.

Zbiorem dobrych praktyk są na pewno standardy o których wspomniano wyżej, ale tu popieram w 100% Pana Torvaldsa. Najważniejsze są struktury i rozwiązania problemów, nawet pomiędzy wierszami śmiem doczytywać się treści odnośnie funkcjonalności, jeśli rozpatrywać strukturę programu na równi ze strukturą danych.

Więc jeśli możesz opisać jednym zdaniem (nawet pojedyńczo złożonym) działanie funkcji, nie rozpisuj jej na trzy, gdy jest to niemożliwe, wtedy pomyśl jak sensowne jest jej działanie. Jeśli będzie wykorzystywana w wielu miejscach, długie funkcje pod konkretny wycinek kodu się nie sprawdzają, nawet nie mówię o sytuacji gdzie wykorzystujesz ją raz. W takich wypadkach pomyśl czy jakieś jej fragmenty, nie są na tyle unikalne aby można było je wykorzystać w wielu miejscach, nawet jeśli w jednym czy dwóch konkretnych wiąże się to z wywołaniem dwóch metod/funkcji.
Nie uważam się za doświadczonego programistę, ale to moja osobista interpretacja powstania takiego pojęcia jak 'ClearCode' w zakresie 'podziału kodu'. Jeśli robię tu błąd, będę wdzięczny za wyprowadzenie mnie z błędu, tak jak już jesteśmy przy tym temacie Uśmiech.

Co do gramatyki, również jak koledzy wyżej polecam standardy. Wymyślone zostały nie bez powodu. I w przeciwieństwie do zasad standardyzacji baz danych (III i później wydane), te dotyczące gramatyki w pythonie mają sens i naprawdę zwiększają czytelność Uśmiech.

Nazewnictwo... Z mojego punktu widzenia, programista będący w temacie, ale nie znający treści kodu, powinien móc choćby zgadnąć co kryje się za zmiennymi gdy dostanie informacje o ich typie. Wg. standaryzacji nazw będących w projekcie.
Zapisane

Python 3.5.2 / Mint
Strony: [1]   Do góry
Drukuj
Skocz do:  

© 2007 - 2018 Polish Python Coders Group
Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines | Theme by PixelSlot