usf-team team mailing list archive

[Kizzo Kilgore <davidpkilgore@xxxxxxxxx>]

Thinking about code organization at this kind of time (the beginning)
sounds like a good idea.  And yes, bzr is great - I love that tool.

The first thing I noticed about the code was the directory layout.
Right now, everything that's in the "code" directory (README.txt,
CREDITS, etc.) looks like it should be at the top level.  The "source"
directory contains some audio files, and looks like it should instead
be moved to usf_media.  All of the *.cfg looks like they should be
somewhere else too, like a directory called "contrib".

The docstring comments (those with """comment""") have an extra blank
line after the comment, which I see as just taking up vertical space,
and should be removed.  For example, the code looks like:

"""
comment

"""

and I prefer comments to look like

"""comment"""

But that's still just my taste, and code is read more often than it is
written, so people may prefer the first way.

I'm a fan of using camelCase variable names (someVar) as opposed to
under_score variable names (some_var), but something like that is not
too big of a deal for me, but is worth mentioning in case anyone else
cares.

This ends my rant about what I like in code : ).  I honestly don't
really care - I really care about what the code "does" as opposed to
how it's being done.  I look at too many different code bases these
days - I've learned to not care about little things like this, and to
care about what the code "does".  And otherwise, the code looks fine
and readable to me.  Not too much needs to be changed.

On Wed, Jan 20, 2010 at 7:50 PM, Edwin Marshall <aspidites@xxxxxxx> wrote:
> I was re-writing config.py because ConfigParser
> (http://docs.python.org/library/configparser.html) offers the following
> benefits:
>   1. No need to parse text files manually
>   2. Less code
>   3. Cross-Platform and standards-compliant
> In doing so, I've found out that I need to edit numerous files. Tryin to
> replace all instances of the old config system is going to be a bit
> daunting, so I figured I would do some code clean up first. Usually this is
> an easy enough task, but I've been trying to keep conventions as closed to
> the original as possible up until now. However, not really knowing what
> conventions are in place, this as proven to be quite difficult. I've only
> managed to do the following:
>   1. Removed references to menu.py - it is not used anywhere, and even the
> TODO states that it should be rewritten (which has been done via gui.py) :-)
>   2. Consolidated all widget_ modules into a single module named widgets
> (from widgets import SomeWidget versus from some_widget import SomeWidget)
> I am now hesitant to change much else because I am finding it difficult to
> navigate all the source, and didn't want to give the code a complete
> face-lift without consulting with you guys. I then realized the power of bzr
> and similar tools: I could simply do what I want and propose a merge which
> would be accepted or denied based on team approval! Plus, working on my own
> branch is less intrusive than pushing changes to the main branch without any
> kind of conference. After all, this isn't my ship, and I'm not the captain;
> I just work on deck. As such, I will be doing the following:
>   1. Re-organizing the directory structure to bettter resemble other
> projects and play nicely with setuptools
>   2. Re-structure code so that it complies by-and-large with PEP-8
> (http://www.python.org/dev/peps/pep-0008/)
> I truly believe that if ultimate-smash-friends has a more "standard"
> directory structure will make the code base less intimidating to work on and
> easier to package for various distributions (a la setuptools).
> _______________________________________________
> Mailing list: https://launchpad.net/~usf-team
> Post to     : usf-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~usf-team
> More help   : https://help.launchpad.net/ListHelp
>
>



-- 
Kizzo Kilgore
Computer Science Undergraduate
San Jose State University