PPy3/DobrePraktyki - Historia wersji

RobertJB: /* Sensowne nazwy */

2019-03-11T14:42:41Z

Sensowne nazwy

RobertJB: /* Sensowne nazwy */

2019-03-11T14:42:16Z

Sensowne nazwy

RobertJB: pierwsza wersja

2019-03-07T14:06:30Z

pierwsza wersja

Nowa strona

= Zasady ,,Dobrej praktyki" =

Pod tym hasłem rozumiem zasady, które nie są regułami języka programowania, a program je naruszający może działać poprawnie a nawet całkiem nieźle. Nie są one też podatne na w pełni precyzyjne sformułowanie — a więc są to może bardziej wytyczne niż zasady. Nie należy ich też traktować jako obowiązujących w każdej sytuacji bez wyjątku; proponowałbym raczej przyjąć, że domyślnie się trzymamy tych zasad, a odstępujemy od nich raczej wyjątkowo i to wtedy, gdy takie odstępstwo ma wyraźne uzasadnienie.

Powodów dla przyjęcia takich zasad jest parę:

* pisząc program należy liczyć się z tym, że powinien on nie tylko poprawnie być wykonywany przez komputer (tj. interpreter), ale powinien również nadawać się do czytania przez ludzi — którzy mogą potrzebować go poprawić, rozszerzyć, przystosować do własnych celów, lub wręcz będą chcieli się czegoś z niego nauczyć;
* programowanie jest prawie zawsze częścią pracy zespołu, w którym uczestniczą zarówno osoby programujące, jak i wypełniające inne zadania. Dobrze jest przestrzegać zasad, które ułatwiają współpracę w ramach zespołu;
* nawet jeżeli tworzymy program samodzielnie i wyłącznie na własny (i może nam się wydawać, że jednorazowy) użytek, to nieraz się zdarzy że będziemy chcieli go użyć ponownie w przyszłości, i być może jakoś poprawić lub zmodyfikować. Można to uważać za szczególny przypadek pracy zespołowej ;) Ja, piszący pewien kod dzisiaj, i ja po dwóch miesiącach, to w zasadzie różne osoby, i łatwo dochodzi do sytuacji, w której ta druga kompletnie nie rozumie co ta pierwsza miała na myśli pisząc dany kod...

== Zgodność ze specyfikacją ==

Piszemy program, który wykonuje to zadanie, które zostało postawione — a nie jakieś zbliżone, choćby nam się wydawało, że tak będzie lepiej. Jeżeli sformułowanie zadania zawiera konkretne nazwy funkcji, modułów itp., konkretne sygnatury — tzn. że funkcja przyjmuje takie a nie inne argumenty, i zwraca taką a nie inną wartość — to tego się trzymamy. Jeśli uważamy, że specyfikacja nie jest dobra i należałoby ją poprawić, to dyskutujemy to ze współpracownikami. Oczywiście nie dotyczy to kontekstu kolokwium czy sprawdzianu ;) Wówczas jeśli mamy jakiekolwiek wątpliwości co do postawionego zadania, to '''pytamy i to od razu''' o wyjaśnienie czy też ujednoznacznienie.

Szczególny przypadek: gdy program ma ustalać sposób swojego działania na podstawie opcji i/lub argumentów z linii poleceń, to nie zastępujemy tego zapytaniem interaktywnym (odwołaniem do <tt>input()</tt>)! I ''vice versa''. W 90% przypadków (liczba z sufitu) to pierwsze rozwiązanie jest właściwsze, ale najważniejsze jest to, na co się umówiliśmy z zespołem.

== Sensowne nazwy ==

Niektórzy twierdzą, że nadawanie nazw obiektom występującym w kodzie programu jest najtrudniejszym zadaniem programisty. Być może to przesada, ale złe nazewnictwo może być dużym utrudnieniem w zrozumieniu kodu programu (przez człowieka, nie przez maszynę). Przez złe nazewnictwo mam na myśli nazwy nic nie znaczące, lub wręcz wprowadzające w błąd. To, jakie są zasady właściwego nazewnictwa jest i pewnie zawsze będzie sporne; natomiast łatwo poznać, kiedy nazewnictwo jest ewidentnie złe.

== Właściwy podział zadań ==

Typowy program (taki malutki; jest wiele bardziej złożonych) ma do wykonania zazwyczaj trzy zadania:

* pozyskać dane wejściowe
* dokonać ich przetworzenia, lub wyliczyć na ich podstawie jakiś wynik
* przekazać ten wynik dalej, np. poinformować o nim użytkownika, lub zapisać do pliku.

Z wyjątkiem zupełnie trywialnych programów, mieszczących się w nie więcej niż kilku linijkach kodu, zadania te nie powinny być wykonywane łącznie w jednym bloku. Zadanie środkowe, jeżeli jest w nim cokolwiek nietrywialnego, powinno być wyodrębnione np. w funkcję (lub kilka),
której zupełnie nie obchodzi skąd się biorą dane wejściowe (jej argumenty), ani co się stanie z wynikiem (wartością zwracaną). Jej zadaniem powinno być tylko i wyłącznie zrealizowanie algorytmu przetwarzania danych czy obliczenia wyniku. Sprzyja to czytelności kodu, ułatwia jego testowanie i ewentualne wielokrotne wykorzystanie. W szczególności, blok instrukcji zajmujący się pozyskaniem danych wejściowych i ,,zagospodarowaniem" wyniki powinien być opakowany w instrukcję warunkową <tt>if __name__ == '__main__':</tt>, gdyż instrukcje tam zawarte są niestosowne w przypadku, gdy chcielibyśmy funkcjonalność ,,algorytmiczną" kodu tego programu importować do wykorzystania w innym programie. Inaczej mówiąc, piszmy programy tak, aby dało się je wykorzystać bądź jako bezpośrednio wykonywalne, bądź jako moduły.

Ewidentnym gwałtem na tej zasadzie jest np.:

* gdy w kodzie funkcji przetwarzającej dane jest ,,zaszyta" nazwa pliku, z którego będą pobrane dane wejściowe
* gdy funkcja realizująca algorytm wypisuje jego wynik wywołując <tt>print()</tt>, zamiast go zwrócić instrukcją <tt>return</tt>
* gdy funkcja realizująca algorytm zawiera odwołania do <tt>input()</tt>.

Właściwie w ,,algorytmicznej" części kodu nie powinno być w ogóle odwołań do <tt>input()</tt> ani do <tt>print()</tt>, ewentualnie te drugie mogą się pojawić na etapie testowania lub dla wyświetlania wskaźników postępu jeśli wykonanie programu może trwać długo.

== CDN ==

----

[[PPy3/TematyDodatkowe|poprzednie]] | [["Programowanie z Pythonem3"|strona główna]] | [[PPy3/Wprowadzenie|od początku ;)]]
----

--[[Użytkownik:RobertJB|RobertJB]] ([[Dyskusja użytkownika:RobertJB|dyskusja]]) 15:06, 7 mar 2019 (CET)

@@ Linia 19: / Linia 19: @@
 Niektórzy twierdzą, że nadawanie nazw obiektom występującym w kodzie programu jest najtrudniejszym zadaniem programisty. Być może to przesada, ale złe nazewnictwo może być dużym utrudnieniem w zrozumieniu kodu programu (przez człowieka, nie przez maszynę). Przez złe nazewnictwo mam na myśli nazwy nic nie znaczące, lub wręcz wprowadzające w błąd. To, jakie są zasady właściwego nazewnictwa jest i pewnie zawsze będzie sporne; natomiast łatwo poznać, kiedy nazewnictwo jest ewidentnie złe.
-Pokrewnym zagadnieniem jest właściwe stosowanie tzw. stałych symbolicznych. Np. jeżeli w rachunkach potrzebna jest wartość liczby π, to nie piszemy w jej miejscu 1.14159... (czy ile cyfr znaczących jest nam potrzebnych), tylko korzystamy z <tt>math.pi</tt> lub <tt>numpy.pi</tt>. Ale dotyczy to nie tylko liczb o szczególnym znaczeniu; jeżeli pewien plik z jakichś powodów ma mieć szczególną nazwę (a nie &mdash; nazwę przekazywaną jako argument uruchomienia), lub nazwę domyślną, to wprowadzamy na samym początku kodu symbol oznaczający tę nazwę, i więcej jej w kodzie nie powtarzamy, tylko odwołujemy się do tego symbolu. I analogicznie w podobnych sytuacjach.
+Pokrewnym zagadnieniem jest właściwe stosowanie tzw. stałych symbolicznych. Np. jeżeli w rachunkach potrzebna jest wartość liczby π, to nie piszemy w jej miejscu 3.14159... (czy ile cyfr znaczących jest nam potrzebnych), tylko korzystamy z <tt>math.pi</tt> lub <tt>numpy.pi</tt>. Ale dotyczy to nie tylko liczb o szczególnym znaczeniu; jeżeli pewien plik z jakichś powodów ma mieć szczególną nazwę (a nie &mdash; nazwę przekazywaną jako argument uruchomienia), lub nazwę domyślną, to wprowadzamy na samym początku kodu symbol oznaczający tę nazwę, i więcej jej w kodzie nie powtarzamy, tylko odwołujemy się do tego symbolu. I analogicznie w podobnych sytuacjach.
 == Właściwy podział zadań ==

← poprzednia wersja		Wersja z 14:42, 11 mar 2019
Linia 18:		Linia 18:

	Niektórzy twierdzą, że nadawanie nazw obiektom występującym w kodzie programu jest najtrudniejszym zadaniem programisty. Być może to przesada, ale złe nazewnictwo może być dużym utrudnieniem w zrozumieniu kodu programu (przez człowieka, nie przez maszynę). Przez złe nazewnictwo mam na myśli nazwy nic nie znaczące, lub wręcz wprowadzające w błąd. To, jakie są zasady właściwego nazewnictwa jest i pewnie zawsze będzie sporne; natomiast łatwo poznać, kiedy nazewnictwo jest ewidentnie złe.		Niektórzy twierdzą, że nadawanie nazw obiektom występującym w kodzie programu jest najtrudniejszym zadaniem programisty. Być może to przesada, ale złe nazewnictwo może być dużym utrudnieniem w zrozumieniu kodu programu (przez człowieka, nie przez maszynę). Przez złe nazewnictwo mam na myśli nazwy nic nie znaczące, lub wręcz wprowadzające w błąd. To, jakie są zasady właściwego nazewnictwa jest i pewnie zawsze będzie sporne; natomiast łatwo poznać, kiedy nazewnictwo jest ewidentnie złe.
		+
		+	Pokrewnym zagadnieniem jest właściwe stosowanie tzw. stałych symbolicznych. Np. jeżeli w rachunkach potrzebna jest wartość liczby π, to nie piszemy w jej miejscu 1.14159... (czy ile cyfr znaczących jest nam potrzebnych), tylko korzystamy z <tt>math.pi</tt> lub <tt>numpy.pi</tt>. Ale dotyczy to nie tylko liczb o szczególnym znaczeniu; jeżeli pewien plik z jakichś powodów ma mieć szczególną nazwę (a nie — nazwę przekazywaną jako argument uruchomienia), lub nazwę domyślną, to wprowadzamy na samym początku kodu symbol oznaczający tę nazwę, i więcej jej w kodzie nie powtarzamy, tylko odwołujemy się do tego symbolu. I analogicznie w podobnych sytuacjach.

	== Właściwy podział zadań ==		== Właściwy podział zadań ==