PEP 8- Python Coding Style DANIEL BAEK
Introduction Most people in RPI have taken Computer Science 1 which is now taught using Python. Computer Science may touch upon Python coding style, but doesn’t explain it in full detail. Some RCOS Projects use Python. Many potential projects could be made with Python. PEP 8 is for Python code on Python projects. There is a separate C code style convention for Python projects. (I will not be talking about it though.)
Word of Caution DON’T REINVENT THE WHEEL! If the style causes the code less readable, don’t use it! (You might have an overall, bigger problem.) Be consistent with older code. Older versions that were used before the inception of the document shouldn’t have to follow this. (But, why are you using old Python?)
Indentation Indentation should always be four (4) spaces long. For long lines (>79 characters): ◦ Functional arguments can always be represented by aligning the first letter of subsequent lines with the first character of the original line. ◦ Function calls can use single indents for subsequent lines. ◦ Function definitions should use double indents for subsequent lines.
Parenthesis and Brackets End parenthesis and brackets should be on their own lines. End parenthesis and brackets should either be aligned to the first non-whitespace character of the last line or with the first non-whitespace character of the construct itself.
Tabs or Spaces Python 2.x code should always use spaces. Python 3.x code can use spaces or tabs. ◦ To that end, make sure that you are consistent with your tabs and spaces! General recommendation is to use spaces.
Line Length <79 characters for regular code. <72 character for comments and documentations.
Source File Encoding UTF-8 ASCII for Python 2.x Latin-1 UTF-8 for Python 3.x
Naming Conventions Don’t use I’s, O’s, and l’s as single-character variables: ◦ I’s and l’s are almost indistinguishable. ◦ O’s and 0’s are also confusing. Modules should be all lowercase. Underscores recommended only if it makes the name more readable. Class names should be in PascalCase. Function names and instance variables should be lowercase with underscores as necessary. Constants should be ALL_CAPITAL_WITH_UNDERSCORES.
Recommendations Code should be written in a way that isn’t a disadvantage of other implementations of Python. When dealing with Boolean operations, use: ◦ “if/for/while var1 is not None:” ◦ But not: “if/for/while not var1 is None:” Empty sequences return a false, use this fact! ◦ Rather than “if len(seq)” ◦ Use “if seq” Don’t compare Boolean values using ==. Try to avoid the use of magic numbers.
TL;DR Version Go to this site for information about PEP8: http://legacy.python.org/dev/peps/pep-0008/ Go to this site to check your code: http://pep8online.com/
Thanks to: Sean O'Sullivan Professor Moorthy Professor Goldschmidt RCOS

PEP 8

  • 1.
    PEP 8- Python Coding Style DANIEL BAEK
  • 2.
    Introduction Most peoplein RPI have taken Computer Science 1 which is now taught using Python. Computer Science may touch upon Python coding style, but doesn’t explain it in full detail. Some RCOS Projects use Python. Many potential projects could be made with Python. PEP 8 is for Python code on Python projects. There is a separate C code style convention for Python projects. (I will not be talking about it though.)
  • 3.
    Word of Caution DON’T REINVENT THE WHEEL! If the style causes the code less readable, don’t use it! (You might have an overall, bigger problem.) Be consistent with older code. Older versions that were used before the inception of the document shouldn’t have to follow this. (But, why are you using old Python?)
  • 4.
    Indentation Indentation shouldalways be four (4) spaces long. For long lines (>79 characters): ◦ Functional arguments can always be represented by aligning the first letter of subsequent lines with the first character of the original line. ◦ Function calls can use single indents for subsequent lines. ◦ Function definitions should use double indents for subsequent lines.
  • 5.
    Parenthesis and Brackets End parenthesis and brackets should be on their own lines. End parenthesis and brackets should either be aligned to the first non-whitespace character of the last line or with the first non-whitespace character of the construct itself.
  • 6.
    Tabs or Spaces Python 2.x code should always use spaces. Python 3.x code can use spaces or tabs. ◦ To that end, make sure that you are consistent with your tabs and spaces! General recommendation is to use spaces.
  • 7.
    Line Length <79characters for regular code. <72 character for comments and documentations.
  • 8.
    Source File Encoding UTF-8 ASCII for Python 2.x Latin-1 UTF-8 for Python 3.x
  • 9.
    Naming Conventions Don’tuse I’s, O’s, and l’s as single-character variables: ◦ I’s and l’s are almost indistinguishable. ◦ O’s and 0’s are also confusing. Modules should be all lowercase. Underscores recommended only if it makes the name more readable. Class names should be in PascalCase. Function names and instance variables should be lowercase with underscores as necessary. Constants should be ALL_CAPITAL_WITH_UNDERSCORES.
  • 10.
    Recommendations Code shouldbe written in a way that isn’t a disadvantage of other implementations of Python. When dealing with Boolean operations, use: ◦ “if/for/while var1 is not None:” ◦ But not: “if/for/while not var1 is None:” Empty sequences return a false, use this fact! ◦ Rather than “if len(seq)” ◦ Use “if seq” Don’t compare Boolean values using ==. Try to avoid the use of magic numbers.
  • 11.
    TL;DR Version Goto this site for information about PEP8: http://legacy.python.org/dev/peps/pep-0008/ Go to this site to check your code: http://pep8online.com/
  • 12.
    Thanks to: SeanO'Sullivan Professor Moorthy Professor Goldschmidt RCOS