PyCQA / PyCQA/pycodestyle

E303: too many blank lines (2)

Open
#775 0 comments 6 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
5.2k
Forks
754
PR merge metrics
No merged PRs in 30d

Description

quoting PEP 8 :
"Surround top-level function and class definitions with two blank lines.

Method definitions inside a class are surrounded by a single blank line.

Extra blank lines may be used (sparingly) to separate groups of related functions. Blank lines may be omitted between a bunch of related one-liners (e.g. a set of dummy implementations)."

Which may be usefull, for example, if you are used to split your function in really small unit accordingly to the SRP (and Clean Code book of Robert C. Martin).

For example if you have a snippet like this one, with a lot more of subfunction :

class foo():
    def usefull_function(self):
        _sub_function_a()
        _sub_function_b()    

    def _sub_function_a(self):
        #do_stuff
  
    def _sub_function_b(self):
        #do_stuff


    def other_function_with_subfunction(self):   # Two blank lines before this might be cleaner.
        _sub_function_c()
        _sub_function_d()

    def _sub_function_c(self):
        #do_stuff
  
    def _sub_function_d(self):
        #do_stuff

This snippet is here to give an example of why this can be used, but anyway, the PEP states it's ok.

Question :

  • Should pycodestyle allow more blank lines that the recommandation (and not restriction)?

Options that could be implemented

  • Selecting the number of exception to the recommandation that can be applied to a class (enhance the "sparingly" in the PEP8 quotation)
  • Selecting the max number of extra blank line before class, top-level function and method.

Pros :

  • Real check of the PEP8.
  • Let you more option for clean code.

Cons :

  • In the main use case, you want only one blank line before a def, and it will allow some wrong blank space to sneak in the code.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the E303 check and reviewing how its current blank-line limit is tested. Compare the proposed exception-count and configurable-limit options with the PEP 8 wording, then clarify the intended policy with maintainers before implementing anything. Done means a decided behavior and tests covering the accepted cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.