Code Samples: Inline or Code-Behind?

Posted on October 13, 2005  |  

Posted in Development

10 comments

When you read ASP.NET–related books, do you prefer ASPX pages with inlined server-side scripts, or ASPX and code-behind separate?

For the sake of this discussion, let’s not delve into such technical matters as missing IntelliSense in ASPX pages, compiler inability to catch errors in inlined code, etc. Let’s focus on the format of samples as they are printed in books. Which format is easier to comprehend? How would you go about making samples concise yet complete? Maybe you have a favorite typeface that would work great for code listings.

I will not offer my opinion at this point, otherwise it may set the overall tone of this discussion as a dictum (and I don’t want that.) I’m interested in your ideas.

10 comments

Klaus
on October 13, 2005

Either way is OK, I can follow both. However, what really bugs me is when books mix the metaphors and do both...be consistent. In most situations the value and clarity of code examples is not in how they are presented, rather how complete and clear a job the author does in dissecting the sample and explaining what is happening.

All being said, I do like it when books present code the way that I work :-) and that's using the code behind model. I find this easier to conceptualise and all to often the value is in the scripting not the html markup.

p.s. My personal peeve, off topic sorry, are markup (X)HTML samples in .NET books that still show inline styles or MS bloated presentation markup. Come on, just because MS products create bloated markup doesn't mean we should encourage it.


Milan Negovan
on October 13, 2005

Klaus, thank you for feedback. Actually, your comment is very on topic, so to say. I do feel authors need to clean up their act... and their ASPX samples. Those hideous proprietary notions should go.


David O'Hara
on October 14, 2005

Hands down I prefer the code behind model. While inline does keep things short and sweet, it's not what most of us are used to. As for typeface, please DO NOT use Terminal - it's an awful typeface. I would recommend Monospace or Lucida Console but that's just me. :)


Scott Allen
on October 14, 2005

I'm leaning towards inline code these days - at least for 2.0.


Shane Shepherd
on October 14, 2005

I definitely prefer the code-behind method. However, like Klaus said, consistency is key. When I was first learning .NET, one of my key frustrations was translating the examples I was seeing in a book into something that worked.

It seems that very often there is not an adequate discussion of code-behind and how it works. Also, referencing of namespaces in code-behind (i.e. - "using System.Data.SqlClient;") is often sadly overlooked. I end up wasting time researching the correct namespace for the class and methods I'm trying to use.


Sean Chase
on October 14, 2005

Separate code-behind example boxed and a boxed example of the markup if necessary.


Alex
on October 15, 2005

I fully agree with David O'Hara.


tom
on October 21, 2005

I agree with the folks who want it in the code behind. I've never actually used inline C# in an aspx page.

Can I ask what you meant by "inline styles?" Is that when you use style= in your html? Do I need to be using css classes for everything?

Am I being lazy by still using style=? I mean... do I really need to create a class for something I might use once or twice?


Milan Negovan
on October 24, 2005

Server controls don't make rational use of CSS inline styles. Too often they take control attributes and write out long inline styles.

It's ok to inline if you have a one-off need here and there, but if you style controls in a consistent manner, you need to move these styles into a CSS file.


Brian Swan
on September 26, 2008

I think the code behind would be a great asset in learning. I have been a PHP programmer for over 10 years and I am trying to slide into the .NET arena. I'm seeing a very steep learning curve and the code behind is a big part of it (along with all the wizard tools they throw at you.)


Leave a comment

  •