[Tutor] don't repeat yourself; question about code optimization

tpc247 at gmail.com tpc247 at gmail.com
Sun Jul 29 11:29:22 CEST 2007


On 7/23/07, Alan Gauld <alan.gauld at btinternet.com> wrote:

>
> The prime directive of coding is make it readable!
> The DRY principle is just that a principle. If repeating makes for
> more maintainable or readable code then repeat yourself.
>
> Remember 80% of the cost of software is in maintenance not initial
> development. DRY is one way to improve maintainablility
> PS The most serious problem with your code from my perpspective
> is that your variable names are way too long. That affects maintenance
> and readability more that the repetition (and in the case of email it
> causes line wrapping that makes it even worse!)
>
> Finally the class is not a good class in an OOP sense since it is
> nearly a verb.
> It is better done as a simple function in my view, just pass in the
> parameters to
> the create method. Like this:
>
> def create_table(num_items, row_size):
>     start = 0
>     table = []
>     num_rows = num_items/row_size
>     for n in range(num_rows):
>         row = [num for num in range(start,start+row_size)]
>         table.append(tuple(row))
>         start += row_size
>     return table
>
> Or better still build a table class that knows how to create
> itself, but also knows how to maniplulate itself too - doing whatever
> it is you intend doing to the table you just created! This reflects
> another
> programming "rule" - the law of demeter" - one of the fundamentals of
> OOP.



Alan, I spent today going over what you took the time to patiently
illustrate to me, and I believe I learned the following things:
- code readability and ease of maintenance are the primary goals of a
computer programmer
- classes that are very nearly verbs should be converted to functions,
unless you can write a class that knows how to create and manipulate itself,
following the law of demeter

About the last bit of code, where you propose to create the table using list
comprehension, I did want to capture partial rows, so I put the finishing
touches to your work so it could.  When I subjected the code to a battery of
tests, it failed in the following way:

def create_table(num_items, row_size):
    start = 0
    table = []
    num_rows = (num_items/row_size) + (num_items%row_size)
    for n in range(num_rows):
        row = [num for num in range(num_items)[start:start+row_size]]
        table.append(tuple(row))
        start += row_size
    return table

def test_harness():
    assert create_table(3, 1) == [(0,), (1,), (2,)]
    assert create_table(4, 1) == [(0,), (1,), (2,), (3,)]
    assert create_table(1, 2) == [(0,)]
    assert create_table(2, 2) == [(0, 1)]
    assert create_table(4, 2) == [(0, 1), (2, 3)]
    assert create_table(5, 2) == [(0, 1), (2, 3), (4, )]
    assert create_table(5, 3) == [(0, 1, 2), (3, 4)]
    assert create_table(7, 4) == [(0, 1, 2, 3), (4, 5, 6)]

assert create_table(5, 3) == [(0, 1, 2), (3, 4)]
AssertionError

I know that my method of calculating the number of rows is faulty, but I'm
not sure how to correct it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tutor/attachments/20070729/ff5a2e42/attachment.html 


More information about the Tutor mailing list