One of my role models, Poet Laureate of the United States was recently interviewed on the Bob Edwards show. Its now available on Audible for free. Absolutely worth downloading and giving a listen to.
http://www.audible.com/adbl/store/welcome.jsp?source_code=RSSW0001RF031805&entryRedirect=/store/product.jsp&entryParams=^productID~FR_BOBE_050728
XML demi-god Daniel Cazzulino (kzu, as we know him) has an interesting post on this blog this morning. Interesting in that it reminds us of Bad Practices.
One thing that I want to point out though is that String concatenation should be considered harmful for .NET strings but not always all other object types. The problems with string concatenation in .NET are well known, but for details see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/vbnstrcatn.asp
And yes, there is a lot of HTML and XML being built that way. Sad but true.
However, Kzu's example of output.WriteLine, we really don't know "output" is. It might very well be a stream that doesn't have the multiple instance propagation problem that's know to happen with strings. Consider that in ASP.NET, the Response object's Output member is a text stream, so iteratively calling this method to generate output isn't harmful. But does count as evil in my book since the "better" way to generate output in ASP.NET is by having controls emit the appropriate HTML instead of writing literal values to the output stream. Why? Part of it has to with the User Agent sensitive nature of ASP.NET's controls. As a layer of abstraction, you can depend on them to emit the right HTML for a given User Agent without having to code that for yourself. Another reason is that you can much more easily control if a Control's output is included in the HTML spooled down to the client (just set the Visible property as needed) rather than having to code conditional code yourself. Remember that during page rendering, ASP.NET simply calls each control on the page as tells it to render itself, and it sends the renderings down the pipe using that same Output (well, actually OutputStream) member.
Where I do very much agree with Kzu is then in three use cases:
- Don't generate XML in a .NET application by serial string concatenation. The "duh factor" on this should be pretty high by now.
- Don't generate XML in a .NET application by serially building up DOM (XMLDocument) instances. That's exactly the job that XmlWriter was built for. Its much more efficient at it, too.
- Don't generate XML instances in SQL Server 2005 using XMLDML's Insert verb. Since the XMLDML processor roundtrips XML instances fully on each action, you get processor and memory trash even worse that you get with .NET string concatenation and you're failing into the DOM pattern when you don't need it.
For example, anybody that writes a query like this:
declare @limit int
declare @current int
declare @xdoc xml
set @limit = 1000
set @xdoc = '<list />'
set @current=1
LOOPTOP:
set @xdoc.modify('insert <item>{sql:variable("@current")}</item>
as last into /list[1]')
set @current = @current+1
if @current < @limit goto looptop
select @xdoc
go
Instead of like this:
create table #items(itemID int)
go
declare @limit int
declare @current int
set @limit = 1000
set @current=1
LOOPTOP:
insert into #items values(@current)
set @current = @current+1
if @current < @limit goto looptop
select itemID as 'text()'
from #items
for xml path('item'),root('list'),type
go
Should also lose points on their developer's license.
Why? On my humble system, the first query takes well over six seconds to complete; the second a mere .16 seconds.
But of course, you're free to judge for yourself.