[Python-projects] A first impression of pylint

[Mads Kiilerich]

On 07/21/2009 11:08 AM, Emile Anclin wrote:
> On Monday 20 July 2009 17:29:02 Sylvain Thénault wrote:
>    
>> On 20 juillet 17:17, Alexandre Fayolle wrote:
>>      
>>>> * have a distinction between different kind of warnings :
>>>>    - potential errors
>>>>    - formatting issues (indentation, line length, name convention
>>>> ...) - code cleaning (unused variables ...)
>>>>    ideally, I would like to optionally disable some of them but not
>>>> the other ones, or have the warnings but not the Convention
>>>>    and Refactoring issues, and so on.
>>>>          
>>> Right now, filtering is by checkers. I agree filtering by severity /
>>> message type could be nice. I generally achieve this with grep.
>>>        
>> filtering by category is already there (see
>> --enable-msg-cat/--disable-msg-cat).
>>      
> ok, sorry for not seeing all these nice options.
>    

Please don't be sorry. The fact that you didn't see these options points 
out that there _is_ a problem. Now you know the answer, but the next guy 
as smart as you will have the same problem finding the answer. We should 
see if we could improve something so that you wouldn't have had the 
problem at all.

Pylint is fine software and is developed by experts - no doubt about 
that. But one thing experts are generally very bad at is being 
non-experts. It is hard to figure out how to make "lusers" like me 
understand what is going on and use the software and all its smart 
details correctly. FWIW I agree that "usability" is where pylint is 
least strong.

It is very hard to contribute to improvements in this area. It is hard 
to come up with a usability patch which makes major changes and where 
you can argue for every detail like you can for a technical patch. 
Everything in usability has some aspect of opinions and taste, and more 
important than the individual details is the overall design and 
consistency in the whole user experience. But I hope this constructive 
criticism can be used constructively ;-)

In my opinion one important aspect of usability is "conceptual 
complexity". The names of these filtering options introduce the concept 
"message category". It is not obvious to me what that is, and thus I 
tend to ignore these options when I browse the list of options. And 
intuitively I think that when the option names are long then they must 
be for some advanced and seldom used functionality.

I wanted to check the help text where the user can find this option. The 
help text was so long and structured in a way which wasn't obvious to me 
as user that I gave up finding it with eye-grep. I ended up piping it 
through less, and fortunately I knew what to search for ... I suggest 
that the default help text only contains commonly used and important 
options - and especially not options for tweaking individual "checks".

I suggest that all the enable/disable options are merged to one 
enable/disable option which can control anything. I think it will be 
obvious from the parameter value what should be enabled/disabled.

/Mads