Python을 작성하고 PEP8이 무엇인지 모른다면 가서 확인하십시오 now.

PEP8은 Python 코드에 대한 스타일 가이드이며 꽤 좋은 방법이라고 생각합니다. 사람들이 CI/CD 시스템에서 스모크 테스트로 테스트를 실행하기 전에 첫 번째 단계로 linter + 정적 분석기를 배치하고 상황을 깔끔하게 유지하도록 권장합니다. 마이크로 레벨, 여기서 아키텍처에 대해 말하는 것이 아닙니다).

그러나 이 가이드 라인은 깨지기 쉽고 개선될 수 있는 스타일을 홍보하는 곳에서 부족합니다.

깨지기 쉬운 들여쓰기

이것은 PEP8에서 허용되는 스타일이지만 깨지기 쉽습니다.

# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four=4)

무언가가 쉽게 깨지면 깨지기 쉬우며 foo 또는 long_function_name의 이름을 변경하여 이 들여쓰기를 쉽게 끊을 수 있으며 즉시 두 번째 줄의 매개변수가 잘못 정렬됩니다.

# Aligned with opening delimiter.
foo = refactoring(var_one, var_two,
                         var_three, var_four=4)

이를 자동으로 수정하는 편집자가 있지만 모든 사람이 그런 것은 아닙니다. 또한 가끔 화재나 무언가로 건물을 탈출해야 하는 누군가에게서 이와 같은 버려진 코드를 찾습니다.

그리고 긴 함수 호출이 함께 다음과 같이 보일 때 그리 유쾌하지 않습니다.

# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four=4)
barf = another_long_function_name(var_one, var_two,
                                  var_three, var_four=4)

의미상 두 줄이 같은 수준에 있어도 공백의 양이 불규칙한 경우. 시각적으로 오해의 소지가 있습니다.

함수의 매개변수를 한 줄에 하나씩 후행 쉼표로 나열한 경우:

# Aligned with opening delimiter.
foo = long_function_name(
    var_one, 
    var_two,
    var_three, 
    var_four=4,
)

이 경우 함수 이름을 변경하거나 매개변수를 제거 또는 추가하거나 매개변수 이름을 변경할 때 나머지 들여쓰기가 깨지지 않습니다. 새 매개변수를 추가하거나 제거하면 코드 검토를 위한 diff는 수정된 매개변수당 한 줄 변경으로 표시됩니다.

 # Aligned with opening delimiter.
 foo = long_function_name(
     var_one, 
     var_two,
-    var_three, 
     var_four=4,
+    another_var=5,
 )

나란히 비교할 때 변경 사항을 식별하기가 매우 좋고 쉽습니다.

줄 연속 및 끊기

Python에서 줄이 너무 길면 \를 사용하여 다음 줄에서 계속할 수 있습니다. 내 개인적인 취향에 이것은 추악해 보이며 예를 들어 다음과 같은 수입품의 모든 중단을 항상 염두에 두어야 합니다.

from django.db.models.expressions import Case, Exists, Expression, \
    ExpressionList, ExpressionWrapper, F, Func, OuterRef, RowRange, Subquery, \
    Value, ValueRange, When, Window, WindowFrame

거기에서 항목을 삭제하거나 이름을 변경해야 하는 경우 줄의 들여쓰기 길이가 이상해 보일 수 있으며 전체 텍스트를 줄 바꿈하고 모든 백슬래시를 다시 정렬해야 할 수도 있습니다.

따라서 수학에서와 같이 괄호를 그룹화 메커니즘으로 사용하지 않는 이유는 다음과 같습니다.

from django.db.models.expressions import (
    Case, Exists, Expression, ExpressionList, ExpressionWrapper, F, Func,
    OuterRef, RowRange, Subquery, Value, ValueRange, When, Window, WindowFrame,
)

또는 또한:

from django.db.models.expressions import (
    Case, 
    Exists, 
    Expression, 
    ExpressionList, 
    ExpressionWrapper,  
    F, 
    Func,
    OuterRef, 
    RowRange, 
    Subquery, 
    Value, 
    ValueRange, 
    When, 
    Window, 
    WindowFrame,
)

이 마지막 스타일은 너무 길고 일반적으로 가져오기가 자주 변경되지 않기 때문에 마음에 들지 않습니다. 하지만 이 마지막 스타일도 허용되며 위에서 보여준 예제 1의 모든 장점이 있으며 리팩토링 증거입니다.

너무 긴 것을 부를 때

posts = (
   Posts.objects
   .exclude(author=user)
   .filter(title__startswith='hellow')
   .first()
)

긴 경우if:

if (not previous_is_grouped
        and not prev.has_two_images
        and nextone
        and not nextone.has_two_images):
    do_evil_stuff()

여기서는 if의 첫 번째 줄과 나머지 줄 사이의 연속 중단이 마음에 들지 않지만 괜찮습니다.

또한 긴 목록 이해를 할 때:

double_of_evens = [
    x * 2
    for x in range(100)
    if x % 2 == 0
] 

라인은 매핑, 반복 및 필터링을 위한 것입니다.

폐쇄

언어와 전체 커뮤니티에 대한 일반적인 스타일 지침은 훌륭하고 저는 그것을 좋아합니다. 그러나 장님이 되지 마십시오. 일을 조금 더 잘해야 할 진짜 이유가 있다고 생각한다면 그 조치를 취하십시오.

화염에 휩싸인 건물을 탈출해야 했던 버려진 사람들의 코드를 생각해 보십시오. ㅋㅋㅋㅋ