Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a configuration file in documentation example for message #7143

Closed
Pierre-Sassoulas opened this issue Jul 7, 2022 · 5 comments · Fixed by #8287
Closed

Add a configuration file in documentation example for message #7143

Pierre-Sassoulas opened this issue Jul 7, 2022 · 5 comments · Fixed by #8287
Labels
Documentation 📗 Enhancement ✨ Improvement to a component

Comments

@Pierre-Sassoulas
Copy link
Member

Current problem

Right now we do not show the configuration used for example. We could and it would:

  • show readers what need to be done to activate the check if it's an extension, or a standard but optional check (soon ™️)
  • permits to create simpler examples by lowering the values to something sane (i.e. max line length = 15 instead of having 120+ character in the example, max-return-values = 2 instead of 11...)
  • demonstrate some options that can affect the message (!)

Desired solution

Show the configuration used in bad/good and use it as an example of configuration related to a message. There's some issue with this:

  • How to identify related options?

It's not easy to determine that without reading the code, we struggle as much as user here.

  • How to show the difference between the default value and the value being used in a test?

If the default value is 120 we need a way to show what it is if we change it to 15.

  • How to handle duplication of the load-plugins warning

We already have a message for extensions right now.

Additional context

Initially discussed in #7142 (review)

@Pierre-Sassoulas Pierre-Sassoulas added Enhancement ✨ Improvement to a component Documentation 📗 Needs specification 🔐 Accepted as a potential improvement, and needs to specify edge cases, message names, etc. labels Jul 7, 2022
@Pierre-Sassoulas
Copy link
Member Author

We should do #7144 (comment), right after this is implemented.

@stdedos
Copy link
Contributor

stdedos commented Jul 11, 2022

As a side issue, is there some explicit reason that "Correct code" appears before "Problematic code"? 😕

For the example of https://pylint.pycqa.org/en/latest/user_guide/messages/warning/while-used.html, I am expecting to see what my problem is (so as to make sure it matches my situation), not what the solution is (to a problem that hasn't been defined yet).

@Pierre-Sassoulas
Copy link
Member Author

@DanielNoord I also think that having the bad code first would be more intuitive, because you come to see what the issue is about then for the solution, what do you think ?

@DanielNoord
Copy link
Collaborator

Fine with me!

@stdedos Is this something you would like to contribute to the project?

https://github.com/PyCQA/pylint/blob/a359796034afdc137b7c4c19f4f783451765dabc/doc/exts/pylint_messages.py#L275-L276

Switching these two lines around should do the trick 😄

stdedos added a commit to stdedos/pylint that referenced this issue Jul 11, 2022
It makes more sense to _first define the problem_, then solve it.

Mentions issue pylint-dev#7143

Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
@stdedos
Copy link
Contributor

stdedos commented Jul 11, 2022

Well, since you are so kind to pinpoint me exactly where to make the fix ... 😄

stdedos added a commit to stdedos/pylint that referenced this issue Jul 11, 2022
It makes more sense to _first define the problem_, then solve it.

Mentions issue pylint-dev#7143

Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
Pierre-Sassoulas added a commit that referenced this issue Jul 11, 2022
It makes more sense to _first define the problem_, then solve it.

Mentions issue #7143

Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
Co-authored-by: Pierre Sassoulas <pierre.sassoulas@gmail.com>
@Pierre-Sassoulas Pierre-Sassoulas removed the Needs specification 🔐 Accepted as a potential improvement, and needs to specify edge cases, message names, etc. label Feb 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation 📗 Enhancement ✨ Improvement to a component
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants