Product.name != Category.name

[Mark]

This may sound a bit anal...but here it goes.

Why is Product.name have a different meaning than Category.name?
Product.name is a slug, while Category.name is what it sounds like...a
name.

For clarity, would it make sense to change Product.name to
Product.slug, and Product.full_name to Product.name?

[Chris Moffitt]

Hmm.  I'll admit there was probably no rationale behind the approach and I'm ok with the change.  If you could submit a ticket (and even more useful would be a patch).

At some point it's hard to tell when this might become a bike shed type issue but I suspect this change has fairly manageable side-effects.

Thanks,
Chris

[Bruce Kroeze]

Although this particular nit might not be caused by style, I've noticed a few other clashes/inconsistencies in naming due to style. So, I think it might be worth a wiki page to write a quick style guide for patch authors and contributors.

For example, my personal style is to use "CamelCase" for class names, uppercase for module variables & settings, and lowercase underscores for almost everything else.  However, at least one Satchmo contributor is a camelcase fan for functions and variables in functions.  That's cool by me, I can write that way, if that is the way we'd like to go.

Maybe it is overkill, I dunno.  Just a thought.

[Guenter Walser (wanagu)]

Why not simply reference the "PEP8: Style guide for Phyton "
<http://www.python.org/dev/peps/pep-0008> instead of reinventing the wheel.

The Naming Conventions section is pretty much complete, for simplicities
sake it might be an idea to copy the document or parts of it to the wiki
page you mention.

Rgds
G

________________________________

[Brian Johnson]

Bruce Kroeze wrote:
> Although this particular nit might not be caused by style, I've noticed
> a few other clashes/inconsistencies in naming due to style. So, I think
> it might be worth a wiki page to write a quick style guide for patch
> authors and contributors.
>
> For example, my personal style is to use "CamelCase" for class names,
> uppercase for module variables & settings, and lowercase underscores for
> almost everything else. However, at least one Satchmo contributor is a
> camelcase fan for functions and variables in functions. That's cool by
> me, I can write that way, if that is the way we'd like to go.
>
> Maybe it is overkill, I dunno. Just a thought.

I'm probably the guilty party here - I've simply spent too much time
programming in Java. Consistent style does make more sense, and I'll
work on that in the future.

[Chris Moffitt]

I think I'm guilty for a lot of the coding inconsistencies.

I think we should adopt something similar to the Django guidelines here -
http://www.djangoproject.com/documentation/contributing/#coding-style

Many moons ago I asked the Django developers if we could use their style guide and they were ok with that as long as we attributed to them.

Hopefully it's not too big a mess to get cleaned up!

-Chris

[Bruce Kroeze]

I think I do follow the Django/PEP styles already, but I need to refresh my memory.  Python is by design one of the easiest languages to read, and consistency just notches it up one more step.

On 7/20/07, Chris Moffitt <ch...@moffitts.net> wrote:

[Mark]

On Jul 20, 12:17 pm, "Chris Moffitt" <ch...@moffitts.net> wrote:
> Hmm. I'll admit there was probably no rationale behind the approach and I'm
> ok with the change. If you could submit a ticket (and even more useful
> would be a patch).

Just updated to latest (#556) and noticed I was too late in submitting
the patch. I see also that we will be still fixing the full_name -->
name. Thanks Chris!

Mark