your feedback to my first project please

D'Arcy Cain darcy at druid.net
Sat Jan 7 08:04:02 EST 2012


On 12-01-07 07:10 AM, patrick at bierans.de wrote:
> It's my first script in python and I'd like to know if my way of coding
> so far is right and if YOU have some little tips for me
> or if you can point my nose on some things I've missed so far.

Looks pretty good overall.  I have a little armchair quarterbacking
for you.

The main thing I wonder is why a dict to store values.  You index by
a contiguous range of ints so why not use a list.  __init__ becomes
this.  Note I also lose those superfluous underscores.

   def __init__(self, dim, default=0):
     self.data = [default] * dim
     self.pos = 0
     self.dim = dim

Here is how I would write avg() (not _avg)

   def _avg(self):
     """Calculates the average of all values currently in stock.
        This also includes the default values not yet overwritten."""

     return sum(self.data)/self.dim

You could drop your inout method with this change to avg():

   def _avg(self, value = None):
     """Calculates the average of all values currently in stock.
        This also includes the default values not yet overwritten.
        Optionally adds a new value."""

     if value is not None:
       self.in(value)

     return sum(self.data)/self.dim

I am not sure how you get a float out of this though.  You may
want to set self.dim to float(dim) in __init__.

> I've read a lot of the official documentation - even some of the weired
> but cool stuff. And I also read some PEPs like the PEP 8. And I'd love to
> go for TDD. But feedback would help me on my way.

I don't know why TDD seems to be more popular with Python programmers
than others but I do recommend as much of that as possible.

> - How is my code formatting?

Good.

> I know the TestCases are ugly, I still have no feeling for it. :(

Test cases don't have to be pretty, just extensive.  What I can't tell
is whether you wrote the tests first or not.  The sequence should be;

  1. Write the test
  2. Run the test to prove it fails
  3. Write code until test passes
  4. Stop

Steps 2 and 4 are particularly important.  Step 2 assures that you
have a real test.  A test that can't fail is useless.  Step 4 assures
that you never add code without a test.

However, don't be afraid to add extra tests at any time.

> - What about my coding style in general?
> Is my naming of variables, classes and methods/functions stupid?

I would just ease up on the underscores.

Looks like you are on the right track though.

-- 
D'Arcy J.M. Cain <darcy at druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.
IM: darcy at Vex.Net



More information about the Python-list mailing list