Dieser Artikel ist der 21. Tagesartikel von Lint Advent Calendar 2016.
Als Voraussetzung denke ich, dass es wichtig ist, dasselbe zu tun, unabhängig davon, wer es schreibt, um den Code in hohem Maße wartbar zu machen. Es gab verschiedene Kritikpunkte, wie "Es ist eine Illusion" und "Es ist nicht wichtig", aber Pythonista, das "Zen of Python" schützt, will daran festhalten.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Style Guide
Um "den gleichen Code zu haben, egal wer ihn schreibt", muss sich das Team für einen Style Guide entscheiden. Python verfügt über einen Style Guide PEP8. Wenn Sie also jeden an die entsprechende Situation anpassen Das ist gut.
Sie können auch auf Google Python Style Guide verweisen.
Sobald Sie einen Style Guide haben, können Sie ihn während Ihrer Codeüberprüfung anwenden. In der Codeüberprüfung sollten wir jedoch eine viel wichtigere Diskussion führen, anstatt Zeit mit "Bitte vereinheitlichen Sie die Anführungszeichen" und "Bitte ordnen Sie die Reihenfolge der Importe" zu verbringen.
Naoya hat vor einiger Zeit in seinem Blog darüber gesprochen. Überprüfung des Trivialcodes --naoyas Hatena-Tagebuch
Wenn ein Team, das mit der Codeüberprüfung nicht vertraut ist, ohne nachzudenken mit der Codeüberprüfung beginnt, wird in verschiedenen Größen darauf hingewiesen. Auf den ersten Blick scheint es, dass auf verschiedene Punkte hingewiesen wurde und Diskussionen aktiv geworden sind, aber die meisten Diskussionen sind verwirrt, z. B. "Die Einzugsbreite des Codes ist unterschiedlich" oder "Rückgabe wird weggelassen. Ich habe Rückkehr." In vielen Fällen ist es nur eine so triviale Angelegenheit, wie "Ich bevorzuge es" oder "In diesem Fall sieht es besser aus, die Zeichen zu senken". Es ist eine Straße, die einmal genommen werden muss.
Es macht keinen Sinn, solche Dinge endlos zu diskutieren. Es hat nichts zu bedeuten, aber gelinde gesagt, eine Verbesserung verbessert die tatsächliche Qualität überhaupt nicht, und wenn Sie es wirklich haben möchten, können Sie es mechanisch mit dem Flusenwerkzeug oder etwas anderem überprüfen. Es ist nicht etwas, was Menschen tun.
Was Sie tun müssen, ist "Das Design ist für die Erweiterung nicht geöffnet und sollte geöffnet werden" oder "Dies kann zu einem solchen Problem führen, da der Randfall nicht angenommen wird" oder "Ich habe zu einem späteren Zeitpunkt auf den Test zurückgeschaut." Manchmal ist es für Dritte schwierig, die erforderlichen Spezifikationen zu interpretieren. " Dies sind die Punkte, die nur erreicht werden können, wenn der Code richtig gelesen, die Struktur des Codes erfasst und das gesamte Systemgefühl außer dem dort geschriebenen Code berücksichtigt wird.
Das Wichtigste hier ist
Es ist eine Arbeitsteilung. Menschen haben eine begrenzte Zeit, also lassen Sie uns automatisieren, was wir tun können.
Für die Lint-Tools (flake8 und pylint) in Python wird empfohlen, die folgenden Materialien zu lesen, um Ihr Verständnis zu vertiefen.
Refactoring-Tools usw.
Hier möchte ich vorstellen, was ich normalerweise in meiner Arbeit verwende.
In "Zen of Python"
Lassen Sie uns Lint gut nutzen, um den Geist von Lint in die Praxis umzusetzen.
Recommended Posts