[Python coding standard] PEP 8 vs Google Style

Introduction

A well-known Python coding standard is the standard library code standard PEP 8, but the [Google Python Style Guide](https: /) /google.github.io/styleguide/). So I've summarized how Google Style differs from PEP 8. From the conclusion, it was almost the same as PEP 8, so I omitted the common rules (especially blank lines and blanks). Although there are differences, there may be some points that cannot be covered, but please forgive me.

note

――Both Japanese translations are available, but they may not be the latest, so I referred to the English version as much as possible. --PEP 8 is in the public domain, Google Style Guide is CC by 3.0

Comparison table

How to write when joining lines with parentheses

#OK with PEP8 or Google
#Align to open brackets
 foo = long_function_name(var_one, var_two,
                          var_three, var_four)
 meal = (spam,
         beans)
#OK with PEP8 or Google
#hanging indent (4 spaces)
foo = long_function_name(
    var_one, var_two, var_three,
    var_four)
meal = (
    spam,
    beans)

#Allowed for PEP8, NG for Google (2 spaces)
foo = long_function_name(
  var_one, var_two,
  var_three, var_four)

#Not mentioned in PEP8, OK in Google
foo = {
    long_dictionary_key: value1 +
                         value2,
    ...
}
foo = {
    long_dictionary_key:
        long_dictionary_value,
        ...
}

#No mention in PEP8, NG in Google
foo = {
    long_dictionary_key:
    long_dictionary_value,
    ...
}

#OK for PEP8, no mention for Google?
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)


#OK in PEP8, no mention in Google, maybe NG
my_list = [
    1, 2, 3,
    4, 5, 6,
    ]
result = some_function_that_takes_arguments(
    'a', 'b', 'c',
    'd', 'e', 'f',
    )

#I think Google likes this style of writing. PEP8 is also OK.
my_list = [
    1, 2, 3,
    4, 5, 6,
]
result = some_function_that_takes_arguments(
    'a', 'b', 'c',
    'd', 'e', 'f')

--Line break before binary operator in PEP8, no mention in Google --PEP8 exemplifies the description when the condition of the if statement becomes long, Google does not mention it --Google stipulates notation when using function annotation, PEP8 does not mention ――Personally, I like hanging indent because it requires less effort and I can make effective use of one line. --But I think it's easier to see the function arguments in open parentheses ...

Other things that are mentioned only in the Google Style Guide

--Leave one line between the class definition statement and the first method --ʻIf name == Use'main' --Consider splitting when the function exceeds 40 lines --Use+to concatenate two strings. Use%, str.format (), f-string, str.join () to join more than that. --Don't combine map ()andfilter () --Nest when thewith statement is exactly two lines, don't use \ --Shebang does not have to be written, it is meaningless to write in a file that is not executed directly --Don't write useless(). Let's write ()to specify the tuple. --Do not use two or moreforstatements or two or more control statements in the comprehension / generator expression. --Don't use@staticmethodin principle, let's make it a module level function --Use@ classmethod` for methods used as named constructors or methods that change the global state of a class --Don't use mutables in the definition of default arguments --Avoid global variables and use constants --How to write type annotation

Impressions

Google, write the same thing as PEP 8 orz, it was hard to read everything. It was good that I decided how to write docstring and type annotation in quite detail.