Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Stefan Schwarzer <sschwarzer@sschwarzer.net>
Newsgroups: de.comp.lang.python
Subject: =?utf-8?q?=5BPython-de=5D_Re=3A_Code_Style_Review?=
Date: Tue, 29 Nov 2022 18:33:25 +0100
Lines: 74
Message-ID: <f2f9401e-cad5-5313-1898-21dd894e1002@sschwarzer.net>
References: <tm2jhn$1k5h8$1@news1.tnib.de> <480b80d21e58d280c437b4854bfc7cf1@posteo.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666
Content-Language: en-US, de-DE
In-Reply-To: <480b80d21e58d280c437b4854bfc7cf1@posteo.de>
Message-ID-Hash: YVQJWLQMKSSGBPO6A7BJIK56FI366LB2
Precedence: list
Archived-At: <https://mail.python.org/archives/list/python-de@python.org/message/YVQJWLQMKSSGBPO6A7BJIK56FI366LB2/>
Xref: csiph.com de.comp.lang.python:5874

On 2022-11-28 16:37, c.buhtz@posteo.jp wrote:
> Die Frage ist, warum du solche PyLint Ausnahmen ("# pylint:") definiert
> hast. IMHO benötigt man dafür einen wirklich triftigen Grund; eine
> strenge Indikation. Die Hinweise und Meldungen von Lintern haben ihre
> Berechtigung und sollten nicht unterdrück werden.

Ich sehe das nicht ganz so streng. Linter-Ausgaben sind für
mich eher Hinweise/Empfehlungen; letztlich sollte der/die
AutorIn des Codes entscheiden, was davon wie umgesetzt wird.

> Neben den Lintern würde ich dir noch empfehlen, ein paar mehr Leerzeilen
> zu machen. Das erhöht IMHO die Lesbarkeit, gerade bei verschachtelten
> Strukturen. Natürlich ist das Geschmacksache bzw. eine Frage des
> Team-Konsent. Z.B. hier:
> 
> Am 28.11.2022 16:19 schrieb Marc Haber:
> 
>> while True:
>>      time.sleep(30)
>>      if debug > 0:
>>          print('run evaluate() and cleanup_table() from main loop')
>>      cleanup_table()
>>      if debug > 0:
>>          print_table()
>>      evaluate()
> 
> while True:
> 
>       time.sleep(30)
> 
>       if debug > 0:
>           print('run evaluate() and cleanup_table() from main loop')
> 
>       cleanup_table()
> 
>       if debug > 0:
>           print_table()
> 
>       evaluate()

Sinnigerweise sehe ich das umgekehrt, das heißt, ich finde,
was die Verwendung von Leerzeilen angeht, die erste Variante
lesbarer. :-)

Oder spezieller kann man sagen, dass zwar die Lesbarkeit
_lokal_ geringfügig verbessert wird, aber durch vermehrtes
Scrollen im Code die Lesbarkeit _global_ eher schlechter
wird.

Die "großzügige" Einrückung von vier Leerzeichen pro
Einrückungs-Ebene in Python macht es eigentlich relativ
leicht, logische Strukturen zu erkennen, auch ohne die
Leerzeilen.

Zum Thema Leerzeilen innerhalb von Funktionen und Methoden
sollte man sich als Autor ruhig fragen, was man damit
bezweckt. Ich habe schon manches Mal Code in einer Methode
gesehen, der mit Leerzeilen in Blöcke aufgeteilt wurde, -
aber ich hatte keine Ahnung, warum die Blöcke so aufgeteilt
waren wie sie waren und fand das dadurch eher verwirrend.

Noch ein Tipp, den ich selbst zu beherzigen versuche: Immer,
wenn ich Leerzeilen zur Gruppierung innerhalb von Funktionen
einfügen würde, schreibe ich stattdessen einen Code-Kommentar,
der den Code-Block zusammenfasst. Man kann natürlich
trotzdem oberhalb des Zusammenfassungs-Kommentars noch eine
Leerzeile einfügen, aber ich mache es normalerweise nicht.

Zum Thema Kommentare siehe auch
https://sschwarzer.com/download/comments_pycon_de2019.pdf :-)

Viele Grüße
Stefan