Re: PyChecker messages

2005-01-17 Thread John Roth
Ben Sizer [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
But you could use a dict of return values, or even just assigning a
different return value in each if clause. The end result is that you
have a single well-defined exit point from the function, which is
generally considered to be preferable.
Preferable, but not any form of an absolute. Single Exit
was one of the recommendations from the early structured
program work back in the 70s, and the industry has long
since sent it to the dustbin of history.
The issue is a simple one of clarity, and woodenly applying
the single exit rule where it doesn't belong frequently
winds up creating nested if-elif-else structures and extranious
flag variables.
If an embedded return isn't clear, the method probably
needs to be refactored with extract method a few
times until it is clear.
John Roth

--
http://mail.python.org/mailman/listinfo/python-list


Re: PyChecker messages

2005-01-11 Thread Roger Binns
 runner.py:878: Function (main) has too many lines (201)

 What does this mean? Cannot functions be large? Or is it simply an advice that
 functions should be small and simple?

It is advice.

 runner.py:200: Function (detectMimeType) has too many returns (11)

 The function is simply a long else-if clause, branching out to different
 return statements. What's wrong? It's simply a probably ugly code advice?

That is also advice.  Generally you use a dict of functions, or some other
structure to lookup what you want to do.

 _must_ take two arguments; is there any way that I can make 'frame' go away?

Yes, you can name it just _  (underscore).  There are a few other names like
that that are ignored.  (Check the doc).

 Also, another newbie question: How does one make a string stretch over several
 lines in the source code? Is this the proper way?

 print asda asda asda asda asda asda  \
 asda asda asda asda asda asda  \
 asda asda asda asda asda asda

Depends what you are trying to achieve.  Look at triple quoting as well.

Roger 


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: PyChecker messages

2005-01-11 Thread Sylvain Thenault
On Tue, 11 Jan 2005 06:54:54 +, Frans Englich wrote:
 
 Hello,

Hi

 I take PyChecker partly as an recommender of good coding practice

You may alos be interested by Pylint [1].

Pylint is less advanced in bug detection than pychecker, but imho its good
coding practice detection is more advanced and configurable (as the pylint
author, i'm a little biased... ;), including naming conventions, code
duplication, bad code smells, presence of docstring, etc...


Side note : I wish that at some point we stop duplicated effort between
pylint and pychecker. In my opinion that would be nice if each one focus
on its strenghs (as i said bugs detection for pychecker and convention
violation / bad code smell for pylint). That would be even better if both
tools could be merged in one, but (at least last time I took a look at
pychecker) the internal architecture is so different that it's not an easy
task today. Any thoughts ?

[1] http://www.logilab.org/projects/pylint

-- 
Sylvain Thénault   LOGILAB, Paris (France).

http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org


-- 
http://mail.python.org/mailman/listinfo/python-list


PyChecker messages

2005-01-10 Thread Frans Englich

Hello,

I take PyChecker partly as an recommender of good coding practice, but I 
cannot make sense of some of the messages. For example:

runner.py:878: Function (main) has too many lines (201)

What does this mean? Cannot functions be large? Or is it simply an advice that 
functions should be small and simple?


runner.py:200: Function (detectMimeType) has too many returns (11)

The function is simply a long else-if clause, branching out to different 
return statements. What's wrong? It's simply a probably ugly code advice?


A common message is these:

runner.py:41: Parameter (frame) not used

But I'm wondering if there's cases where this cannot be avoided. For example, 
this signal handler:

#---
def signalSilencer( signal, frame ):

Dummy signal handler for avoiding ugly
tracebacks when the user presses CTRL+C.

print Received signal, str(signal) + , exiting.
sys.exit(1)
#---

_must_ take two arguments; is there any way that I can make 'frame' go away?


Also, another newbie question: How does one make a string stretch over several 
lines in the source code? Is this the proper way?

print asda asda asda asda asda asda  \
asda asda asda asda asda asda  \
asda asda asda asda asda asda


Thanks in advance,

Frans

PS. Any idea how to convert any common time type to W3C XML Schema datatype 
duration?
-- 
http://mail.python.org/mailman/listinfo/python-list


stretching a string over several lines (Re: PyChecker messages)

2005-01-10 Thread Steven Bethard
Frans Englich wrote:
Also, another newbie question: How does one make a string stretch over several 
lines in the source code? Is this the proper way?
(1)
print asda asda asda asda asda asda  \
asda asda asda asda asda asda  \
asda asda asda asda asda asda
A couple of other options here:
(2)
print asda asda asda asda asda asda
asda asda asda asda asda asda
asda asda asda asda asda asda
(3)
print \
asda asda asda asda asda asda
asda asda asda asda asda asda
asda asda asda asda asda asda
(4)
print (asda asda asda asda asda asda 
   asda asda asda asda asda asda 
   asda asda asda asda asda asda)
Note that backslash continuations (1) are on Guido's list of Python 
Regrets, so it's likely they'll disappear with Python 3.0 (Of course 
this is 3-5 years off.)

I typically use either (3) or (4), but of course the final choice is up 
to you.

Steve
--
http://mail.python.org/mailman/listinfo/python-list