[melbourne-pug] Thursday's Meeting

[Anthony Briggs]

Dave Cole wrote:
> Anthony Briggs wrote:
> 
>>Mike Dewhirst wrote:
>>>
>>>I think the ...
>>>
>>>	http://www.python.org/peps/pep-0008.html
>>>
>>>... style guide seems to be a reasonable way forward and I would be more 
>>>interested in learning where you think it may be improved on rather than 
>>>covering what is already there.
>>
>>Sure. It's a good starting point, particularly as there are a number of
>>things in there that I don't agree with, such as writing "if not
>>someList:..." rather than "if someList == []:". I also tend to prefer a
>>style with more whitespace, etc.
> 
> I am not sure if you are arguing for or against "if someList == []:".

In general, I'd argue for it, since it's more explicit.

> I suggest that the above code is not good style.  It is very fragile if
> you are testing the value of an argument because it will not detect when
> someList is ().

But it'll also 'fire' when someList is None, "", 0, etc.

> When a care about the distinction between empty list and None I almost
> always do either "if len(some_list) == 0:" or "if some_list is None:".
> When using "if not some_list:" you trap both cases, which is not always
> what you want.

Yep. In the case where you don't know what you're testing, you might be
able to save some logic by just testing the variable. In a list mangling
function though, I'd use the explict test - you'll catch broken programs
much more quickly.

Just a bit of background: I've had a few nasty debugging sessions over
the past little where the culprit has turned out to be a function
dropping out of the bottom and returning None (not my code, btw) instead
of an integer or a list. With an implicit test, it's suprising how far
you can get from that initial error before everything crashes :)
Explicit testing catches those sorts of errors far faster.

>>From a PEP-8 perspective, the variable name is even questionable.  The
> mixedCase style is only condoned when you are maintaining existing code
> that already uses that convention.  If you are writing new code you
> should be using some_list rather then someList.

Yeah, here we get into personal style issues, and risk starting a flame
war :) Personally, I prefer someList to some_list. It's shorter,
particularly when you start adding function arguments into the mix, but
the main reason is that I find:

someMethodName = aParticularFunction(
                     longishArgument = ...,
                     longerArgument = ...,
                     longestArgumentOfAll = ... )

more readable than

some_method_name = a_particular_function(
                     longish_argument = ...,
                     longer_argument = ...,
                     longest_argument_of_all = ... )

perhaps because the caps jump up and make it more legible, whereas the
underscores blend in a bit. It also depends on what you're used to -
someone who reads code with underscores all day is going to find the
latter more readable.

Of course, camelCase has it's downsides - I've had quite a few errors
where I've mistyped a capital and regretted it, but readability counts
more than typability. IMHO the solution is to make naming case
insensitive, but that's just me :)

This is partly why I picked this particular topic, (other than that it's
good for getting a discussion going :) ) -- I actually disagree with a
lot of what PEP-8 has to say. It's not suprising I suppose, considering
that it's essentially distilled from Guido's personal style, but I'm
interested to explore some of the rationale behind it.

>>A lot of the style guides also tend to say 'what', rather than 'why',
>>and in fairly rigid fashion too, which means that it's harder to know
>>when to break the rules when you need to.
> 
> Reading a book like Code Complete might a be good start for people who
> want to know why you should do something rather than just be told to do
> it.  While it does not discuss Python coding style, it does explore the
> reasons behind various code style conventions.

I'll have another look at it and see what it's got to say about camel
case :) From memory though, it's largely geared towards the more static
languages (C/C++ and Java), so there are some aspects (eg. being passed
"", None or a list) that wouldn't necessarily come up as often.

Anthony

-- 
------------------------------------------------------
 HyPerACtIVe?! HEY, Who ArE yoU cAllInG HYPERaCTive?!
 abriggs at westnet.com.au
------------------------------------------------------