Re: [Sunuml-developers] First upload to SVN

[Steven G. <laz...@gm...>]

Hey Javier,


I just uploaded an experimental test to the SVN.
> Don't look much at the code because it is really messy, most of it is
> copy and paste from various samples I found.


Ok

I have some comments even if hadn't time to fully check the code.


1) Don't forget to put a license to each file.
See http://sunuml.wiki.sourceforge.net/Copyright+%26+Disclaimer

This source file is part of SunUML
For the latest info, see http://sourceforge.net/projects/sunuml

Copyright (c) 2008 SunUML.

See also the Readme.txt

Permission is granted to copy, distribute and/or modify this document
under the terms
of the GNU Free Documentation License, Version 1.2 or any later
version published
by the Free Software Foundation; with no Invariant Sections, no
Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU Free
Documentation License"
of the "Copyright & Disclaimer" page of the SunUML wiki.

You should have received a copy of the "GNU Free Documentation License"
along with this program; if not, write to the Free Software Foundation, Inc.,
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA, or go to
http://www.gnu.org/copyleft/fdl.html#TOC


2) Why the embedded images?
It makes it slightly more difficult to customise.


3) We should follow the Python recommended coding style more closely
http://www.python.org/dev/peps/pep-0008/
I copied below the most relevant part.

IMO using the *mixedCase *convention would be better


4) As we are trying to do an UML tool we should try to use some...
uml documentations before coding too much ;)

We should use this code experiment to help us define some overall design.

Bye,
Steven


-------------------------------------

    Function Names

      Function names should be *lowercase*, with words separated by underscores
      as necessary to improve readability.

      *mixedCase *is allowed only in contexts where that's already the
      prevailing style (e.g. threading.py), to retain backwards compatibility.

    Function and method arguments

      Always use 'self' for the first argument to instance methods.

      Always use 'cls' for the first argument to class methods.

      If a function argument's name clashes with a reserved keyword, it is
      generally better to append a single trailing underscore rather than use
      an abbreviation or spelling corruption.  Thus "print_" is better than
      "prnt".  (Perhaps better is to avoid such clashes by using a synonym.)

    Method Names and Instance Variables

      Use the function naming rules: *lowercase *with words separated by
      underscores as necessary to improve readability.

      Use one leading underscore only for non-public methods and instance
      variables.

      To avoid name clashes with subclasses, use two leading underscores to
      invoke Python's name mangling rules.

      Python mangles these names with the class name: if class Foo has an
      attribute named __a, it cannot be accessed by Foo.__a.  (An insistent
      user could still gain access by calling Foo._Foo__a.)  Generally, double
      leading underscores should be used only to avoid name conflicts with
      attributes in classes designed to be subclassed.



      Note: there is some controversy about the use of __names (see below).