pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-19, Alexander Kapps <alex.kapps at web.de> wrote:
> The general idea is, that modules, classes, methods, and functions 
> should be small so they are better reusable, manageable and 
> understandable.

Makes sense.

> If you have a huge class or function with many 
> attributes or local variables, it's often a sign, that your 
> class/function does to much and you better refactor this into 
> smaller pieces.

That is often practical, but it can involve tradeoffs -- there can be
a great deal of additional complexity from the interactions between the
refactored pieces.

I tend to refactor mostly if the pieces have some kind of value outside
their original context.  In some cases, a process is just, well, sorta long,
but there's no relevance to breaking the components out -- they're not
separately useful anywhere.

> I don't know why "the standard" (what standard?) says what it says, 
> but I guess, it's the result of long time experiences and analysis 
> of existing code. Trust them, unless you are sure to know better.

Well, one of the reasons I'm asking is to find out, from experienced
developers, how trustworthy the pylint people are, and what the target
audience is...  Should I be treating this the way I'd treat a list of
coding style rules handed down by a first year CS teacher, which are great
rules for first year CS students, or the way I'd be treating a corporate
style document which is a mandated part of continued employment?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam at seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.