<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Displaying Source Code in a WordPress Post</title>
	<atom:link href="http://kenkopczyk.com/2009/02/01/displaying-source-code-in-a-wordpress-post/feed/" rel="self" type="application/rss+xml" />
	<link>http://kenkopczyk.com/2009/02/01/displaying-source-code-in-a-wordpress-post/</link>
	<description>Hurdles in .NET WinForms Development</description>
	<lastBuildDate>Mon, 25 Jan 2010 20:50:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Ken</title>
		<link>http://kenkopczyk.com/2009/02/01/displaying-source-code-in-a-wordpress-post/#comment-6</link>
		<dc:creator>Ken</dc:creator>
		<pubDate>Wed, 04 Mar 2009 00:39:39 +0000</pubDate>
		<guid isPermaLink="false">http://kkopczyk.wordpress.com/?p=70#comment-6</guid>
		<description>I agree with you and I have adopted the first style of displaying source code.  It&#039;s very easy to implement (you just wrap the code in a couple javascript tags) and it has the useful bells at the top.  It is also preferable because, like you noticed, it avoids the word wrapping problem by adding a horizontal scroll bar.  The second solution does not do this.  It will wrap the code and make it hard to read.

As far as line length for general coding, I personally am not tied to an 80 character limit, although doing so may make it easier if you are required to look at the same code using different text editors or different PC environments that don&#039;t have your preferred monitor resolution available.  However, I think a line becoming to long is a sign of trouble, possibly a codesmell.  When you need to start using a horizontal scroll to view your code, it becomes less readable.  If it is hard to read, it will be harder to maintain.  

If such a situation arises, I&#039;d recommend refactoring the offending code to a variable (or as a return value of a method) with a self-documenting name.  By doing so, you should have no problem getting the line to a manageable length.  Do this multiple times, if necessary.  The better you are able to break it down, the easier the code will read.  However, one unfortunate situation where this may occur in VS is while using the DataSet designer to create table adapters.  If you have a table with a large number of columns, the generated insert method will have as many parameters as there are columns.  This is just the way it is, unfortunately.  I believe the CodeComplete book recommends limiting your parameter list to about 6 or 7 parameters in general.  If you have more than that, try to group the related parameters into a struct or class.</description>
		<content:encoded><![CDATA[<p>I agree with you and I have adopted the first style of displaying source code.  It&#8217;s very easy to implement (you just wrap the code in a couple javascript tags) and it has the useful bells at the top.  It is also preferable because, like you noticed, it avoids the word wrapping problem by adding a horizontal scroll bar.  The second solution does not do this.  It will wrap the code and make it hard to read.</p>
<p>As far as line length for general coding, I personally am not tied to an 80 character limit, although doing so may make it easier if you are required to look at the same code using different text editors or different PC environments that don&#8217;t have your preferred monitor resolution available.  However, I think a line becoming to long is a sign of trouble, possibly a codesmell.  When you need to start using a horizontal scroll to view your code, it becomes less readable.  If it is hard to read, it will be harder to maintain.  </p>
<p>If such a situation arises, I&#8217;d recommend refactoring the offending code to a variable (or as a return value of a method) with a self-documenting name.  By doing so, you should have no problem getting the line to a manageable length.  Do this multiple times, if necessary.  The better you are able to break it down, the easier the code will read.  However, one unfortunate situation where this may occur in VS is while using the DataSet designer to create table adapters.  If you have a table with a large number of columns, the generated insert method will have as many parameters as there are columns.  This is just the way it is, unfortunately.  I believe the CodeComplete book recommends limiting your parameter list to about 6 or 7 parameters in general.  If you have more than that, try to group the related parameters into a struct or class.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://kenkopczyk.com/2009/02/01/displaying-source-code-in-a-wordpress-post/#comment-4</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Tue, 03 Mar 2009 14:58:47 +0000</pubDate>
		<guid isPermaLink="false">http://kkopczyk.wordpress.com/?p=70#comment-4</guid>
		<description>I think I like the first bit of code better.  You&#039;re right, the second code chunk looks exactly like the default font and syntax highlighting however the highlighting in the first block works just as well.  In general I never use line numbers but I could totally see how they could be practical in a blog should you need to make reference to a specific line.  Also it comes with the extra links at the top.
Another issue that occurred to me looking at this post was line wrapping.

This might belong in a post of its own but what is the standard these days?  I’ve heard both sides of the issue argued.  Some say it’s antiquated and dead.  Wide screen monitors and modern &lt;acronym title=&quot;Integrated Development Environment&quot;&gt;IDE&lt;/acronym&gt;s with nicer fonts make the old 80 character limit a thing of the past.  Others argue that limiting yourself to a certain width keeps your code pretty and easy to read.  I’ll have to agree that when a browser or editor decides on its own when to wrap a line of code it’s generally not aesthetically pleasing.

Maybe for websites the best thing would be to put code in a textbox with horizontal and vertical scroll bars.  This prevents line wrapping and also makes it easier to set the code apart from the content of the page.</description>
		<content:encoded><![CDATA[<p>I think I like the first bit of code better.  You&#8217;re right, the second code chunk looks exactly like the default font and syntax highlighting however the highlighting in the first block works just as well.  In general I never use line numbers but I could totally see how they could be practical in a blog should you need to make reference to a specific line.  Also it comes with the extra links at the top.<br />
Another issue that occurred to me looking at this post was line wrapping.</p>
<p>This might belong in a post of its own but what is the standard these days?  I’ve heard both sides of the issue argued.  Some say it’s antiquated and dead.  Wide screen monitors and modern <acronym title="Integrated Development Environment">IDE</acronym>s with nicer fonts make the old 80 character limit a thing of the past.  Others argue that limiting yourself to a certain width keeps your code pretty and easy to read.  I’ll have to agree that when a browser or editor decides on its own when to wrap a line of code it’s generally not aesthetically pleasing.</p>
<p>Maybe for websites the best thing would be to put code in a textbox with horizontal and vertical scroll bars.  This prevents line wrapping and also makes it easier to set the code apart from the content of the page.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
