[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