Feature Request: Naming Convention Enforcement for Boolean Values & Functions

[nh916]

Current problem

In Python, it's a common convention to name boolean variables and functions with prefixes that indicate their boolean nature, such as is, has, or have. Currently, Pylint does not offer a way to enforce this naming convention, which can lead to less readable and less self-documenting code.

Desired solution

I would like Pylint to provide an option to enforce naming conventions for boolean variables and functions. Ideally, Pylint should be able to warn or error when a boolean variable or function (one that returns a boolean value) does not start with the prefixes is, has, or have. This feature would help maintain consistent code quality and improve readability.

Additional context

This feature would be particularly useful for large projects where consistent naming conventions are crucial for maintaining code quality. Enforcing such conventions can aid in understanding code at a glance and prevent potential confusion about the nature of variables and functions.

[jacobtylerwalls]

Sounds like a nice idea for a third-party plugin. The plugin author can decide how to define "boolean function" -- analyze the return statements, the type annotation, what happens if two different things are returned, or there's an implicit None return...? etc.

[Pierre-Sassoulas]

I agree with Jacob, it rather complicated to specify and maintain and more suited to an (opinionated) plugin (or for a linter targeting a strongly typed language). If we add this to pylint we'll have to handle a lot of use case with a myriad of options because we want pylint to be one size fit all after configuration.

[rhyn0]

for anyone who does want something like this, I took a crack at it and built it here https://github.com/rhyn0/pylint-boolean-naming

Comments appreciated

[Pierre-Sassoulas]

The code does not look too complicated, great plugin. You could add it to your fork of pylint as and extension and open a merge request to your main branch to see what's happening in the primers (numpy, pandas, pytest, etc. ). To likely find a bunch of false positives easily. We can add this to pylint-dev if you wish when it's ready.

[DanielNoord]

@Pierre-Sassoulas I think you meant to suggest to add the repository to pylint-dev right? Not in a PR like #9438

[Pierre-Sassoulas]

Yes, the PR to see the primer could be in @rhyn0 's fork. I approve the pipeline in pylint-dev/pylint from time to time if it can help @rhyn0 to see the primer result faster/easier, though it does not mean we're going to add an extension, it should stay a plugin.

[rhyn0]

@Pierre-Sassoulas sorry about that, thanks for explaining your original message. And another thanks for the primer workflow stuff.

I'm unsure what the "merge into pylint-dev" looks like (organization forks my repo and then that becomes the source?) but I'll try to get the primer run to work first

[Pierre-Sassoulas]

No problems :) You can create a branch on your fork (rhyn0/fork-branch) and open a merge request to your own main branch from your fork (rhyn0/main) then the pipeline should work (provided the primer run once on the main branch). Happy to keep approving the pipeline on #9438 if you have issue with your fork setup.