Is inline code in your aspx pages a good practice?

Question

If I use the following code I lose the ability to right click on variables in the code behind and refactor (rename in this case) them

<a href='<%# "/Admin/Content/EditResource.aspx?ResourceId=" + Eval("Id").ToString() %>'>Edit</a>

I see this practice everywhere but it seems weird to me as I no longer am able to get compile time errors if I change the property name. My preferred approach is to do something like this

<a runat="server" id="MyLink">Edit</a>

and then in the code behind

MyLink.Href= "/Admin/Content/EditResource.aspx?ResourceId=" + myObject.Id;

I'm really interested to hear if people think the above approach is better since that's what I always see on popular coding sites and blogs (e.g. Scott Guthrie) and it's smaller code, but I tend to use ASP.NET because it is compiled and prefer to know if something is broken at compile time, not run time.

Answer 1

I wouldnt call it bad practice (some would disagree, but why did they give us that option in the first place?), but I would say that you'll improve overall readability and maintainability if you do not submit to this practice. You already conveyed out a good point, and that is IDE feature limitation (i.e., design time inspection, compile time warning, etc.).

I could go on and on about how many principles it violates (code reuse, separation of concerns, etc.), but I can think of many applications out there that break nearly every principle, but still work after several years. I for one, prefer to make my code as modular and maintainable as possible.

Answer 2

It's known as spaghetti code and many programmers find it objectionable... then again, if you and the other developers at your company find it readable and maintainable, who am I to tell you what to do.

For sure though, use includes to reduce redundancy (DRY - don't repeat yourself)

Answer 3

It's up to you. Sometimes "spagehetti" code is easier to maintain than building/using a full on templating system for something simple, but once you get fairly complicated pages, or more specifically, once you start including a lot of logic into the page itself, it can get dirty really quickly.

Answer 4

I think it is interesting that more asp.net is requiring code in the aspx pages. The listview in 3.5, and even the ASP.NET MVC. The MVC has basically no code behind, but code in the pages to render information.

Answer 5

I use it only occasionally, and generally for some particular reason. I will always be a happier developer with my code separated entirely from my HTML markup. It's somewhat a personal preference, but I would say this is a better practice.

Answer 6

If you think of it in terms of template development, then it is wise to keep it in the view, and not in the code behind. What if if needs to change from a anchor to a list item with unobtrusive JS to handle a click? Yes, this is not the best example, rather just that, and example.

I always try to think in terms of if I had a designer (HTML, CSS, anything), what would I have him doing and what would I be doing in the code behind, and how do we not step on each other's toes.

Answer 7

Its only a bad practice, if you cannot encapsulate it well.

Like everything else, you can create nasty, unreadable spaghetti code, except now you have tags to content with, which by design aren't the most readable things in the world.

I try and keep tons of if's out of hte template, but excessive encapsulation, leads to having to look in 13 diferent places to see why div x isn't firing to the client, so its a trade off.

Answer 8

It's not, but sometimes it's a necessary evil.

Take your case for an example, although code behind seems to have a better separation of concern, but the problem with it is that it may not separate out the concerns as clearly as you wish. Usually when we do the code behind stuff we are not building the apps in MVC framework. The code behind code is also not easy to maintain and test anyway, at least when compare to MVC.

If you are building ASP.NET MVC apps then I think you are surely stuck with inline code. But building in MVC pattern is the best way to go about in terms of maintainability and testability.

To sum: inline code is not a good practice, but it's a necessary evil.

My 2cents.

Answer 9

Normally I use like this way.

<a href='<%# DataBinder.Eval(Container.DataItem,"Id",""/Admin/Content/EditResource.aspx?ResourceId={0}") %'>