.. _too-many-lines:

too-many-lines / C0302
======================

**Message emitted:**

``Too many lines in module (%s/%s)``

**Description:**

*Used when a module has too many lines, reducing its readability.*

**Problematic code:**

.. literalinclude:: /data/messages/t/too-many-lines/bad.py
   :language: python

**Correct code:**

``__init__.py``:

.. literalinclude:: /data/messages/t/too-many-lines/good/__init__.py
    :language: python


``is_palindrome.py``:

.. literalinclude:: /data/messages/t/too-many-lines/good/is_palindrome.py
    :language: python


``main.py``:

.. literalinclude:: /data/messages/t/too-many-lines/good/main.py
    :language: python


**Configuration file:**

.. literalinclude:: /data/messages/t/too-many-lines/pylintrc
    :language: ini

**Additional details:**

When a module has too many lines it can make it difficult to read and understand. There might be
performance issue while editing the file because the IDE must parse more code. You need more expertise
to navigate the file properly (go to a particular line when debugging, or search for a specific code construct, instead of navigating by clicking and scrolling)

This measure is a proxy for higher cyclomatic complexity that you might not be calculating if you're not using ``load-plugins=pylint.extensions.mccabe,``. Cyclomatic complexity is slower to compute, but also a more fine grained measure than raw SLOC. In particular, you can't make the code less readable by making a very complex one liner if you're using cyclomatic complexity.

The example simplify the code, but it's not always possible. Most of the time bursting the file
by creating a package with the same API is the only solution. Anticipating and creating the file
from the get go will permit to have the same end result with a better version control history.



Created by the `format <https://github.com/pylint-dev/pylint/blob/main/pylint/checkers/format.py>`__ checker.