oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hi Diego,

Thanks for an excellent email on this issue.  It is an important one and
I know I have said before that we should follow PEP8.

However, *my* main goal is to make the code attractive to other
developers into the future.  Being completely honest here.  In the
coming months, years, etc.  You will all likely move on to other
projects. Though it would be wonderful if you all built businesses
around writing and supporting OSHIP based applications. :)

I cannot see a time when I will not be associated  with this project. So
longevity is important to me. 

One other reference I would like to add is the Grok conventions:
http://grok.zope.org/doc/current/naming_conventions.html 

So, my reply is that after taking my input and others.  You are the
development project manager.  It is your call to decide on which one of
these we follow or even one with your own modification.  If you have a
really good reason to do so.

Cheers,
Tim 

On Thu, 2010-10-07 at 18:50 -0300, Diego Manhães Pinheiro wrote:
> "mixedCase"
> 
> PROS
> - It is vastly used on Java,C# and C++ community. Zope community also uses it.
> - It a well known naming style shared by different languages which
> surround the object orientation paradigm.
> - Its easier to type than "lowercase with underscores".  You don't
> have to move your fingers to any corner at the keyboard to type the
> underscore character.
> 
> CONS
> - Put the words together into a large stream of characters can confuse
> at first, because they can represent a unique word.
> 
> 
> "lowercase with underscores"
> 
> PROS
> -It's known by the all python community. If a new member that have a
> little background on the language, it will feel comfortable to use the
> convention.
> -Usually it is used by languages which follows the functional paradigm.
> -It improves readability, because it separates the
> method/variable/function signature on words. So, it forces the
> developer to read each part of the signature carefully, giving a
> chance to the reader understand quickly what the code definition is
> about.
> -The openehr specifications describe methods using this naming style
> on class methods . Using it on a OSHIP code won't create a gap between
> the conventions when different conventions are used on the concept and
> implementation domain.
> -It gives a simplicity sensation.
> 
> CONS
> -It's boring type the same underscore character every word separation. :)
> 
> [1] - http://www.iwombat.com/standards/JavaStyleGuide.html#Method%20Names
> [2] - http://www.python.org/dev/peps/pep-0008/
> [3] - http://wiki.zope.org/zope3/ZopePythonNamingConventions
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~oship-dev
> Post to     : oship-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~oship-dev
> More help   : https://help.launchpad.net/ListHelp

-- 
***************************************************************
Timothy Cook, MSc
Project Lead - Multi-Level Healthcare Information Modeling
http://www.mlhim.org 

LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook
Academic.Edu Profile: http://uff.academia.edu/TimothyCook

You may get my Public GPG key from  popular keyservers or    
from this link http://timothywayne.cook.googlepages.com/home

Attachment: signature.asc
Description: This is a digitally signed message part