semi-concatenated strings

[Steve Holden]

"Peter Hansen" <peter at engcorp.com> wrote in message
news:3CF6F202.7274E43E at engcorp.com...
> "Delaney, Timothy" wrote:
> >
> > > From: Peter Hansen [mailto:peter at engcorp.com]
> > >
> > > And which has both embedded "\n" newlines and many more leading
> > > spaces before each line...
> >
> > That's why I would bind it to a name first - that allows me to
preprocess
> > the query before passing it in.
>
> > I would much rather write it so it is readable, then process it for the
> > database, than the other way around.
> >
> > sql = """
> >     select cities.city, state, country
> >     from   cities, venues, events, addresses
> >     where  cities.city like %s
> >            and events.active = 1
> >            and venues.address = addresses.id
> >            and addresses.city = cities.id
> >            and events.venue = venues.id
> > """
> >
# The next three lines are bogus
> > sql = string.split(sql)
> > sql = string.join(sql, ' ')
> > sql = string.strip(sql)
> >
> > rows = self.executesql(sql, (city,))
>
> What a lot of extra work to make something "readable"!
> I don't think that this is more readable than the simple, straightforward
> approach Skip presented.  It uses many more lines and a bunch of
> superfluous operations (without even a comment explaining why
> you are splitting and joining things this way instead of just using
> simple string concatenation).
>
Not only that, but for any reasonable database the whole schemozzle is
completely unnecessary. SQL is a free-format language, and newlines and
spaces embedded in statements make absolutely no difference.

> If I saw code like this in my team I'd ask that a comment be
> added to explain it, and if the comment said "# doing this so the
> code is more readable" I'd ask that it be refactored so it didn't
> need the comment at all, after I got back up off the floor.
> I expect the refactoring would take the form of the original
> example which needs no extra operations or commenting.
>
Or simply remove the three bogus lines and leave the SQL as it's generated.

> > Skip also asked why I would bind the statement to a name. For a query of
> > this size, I find it easier to read - the sql query is separate and (to
my
> > eye) cleaner than having the literal as a function parameter. Plus it
uses
> > much less horizontal white space.

I hadn't realised there was a shortage :-) [Seriously, I like the embedded
newline style, as I underline below...]
>
> Nothing wrong with separating things out like that if you think it
> looks more readable, but this is one case where I agree with Skip's
> approach even though it looks a lot like "hardcoded strings" which
> is generally a Code Smell.  Simpler is much better here.
>
> (I might agree with you more if I thought that maintaining the
> string-concatenated version would actually be harder.  Given the
> likely nature of the maintenance -- adding fields to the line with
> "from cities, ..." for example, or adding a new line to the
> "where" intersection -- I don't believe it would be *any* harder.)

As I said earlierrr, in another post: '''would personally much prefer to see
this written as

    ("""select cities.city, state, country
     from cities, venues, events, addresses
     where cities.city like %s
         and events.active = 1
         and venues.address = addresses.id
         and addresses.city = cities.id
         and events.venue = venues.id""",
    (city,))
'''

but it's largely a matter opf taate. What clealy *should* be avoided is
unnecessary programmed transformation of SQL statements.

regards
 Steve
--
-----------------------------------------------------------------------
Steve Holden                                 http://www.holdenweb.com/
Python Web Programming                http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------