Inline vs. Code-behind

[drewsblues]

My company is getting ready to migrate to ASP.NET and we're looking to implement inter-team standards for coding and development for consistency's sake. Some of the questions I have pertain to using inline code vs. code-behind:

• Is it better to use code-behind than inline code with ASP.NET?
  
• Is it strictly a matter of preference?
  
• Are there some instances where using one is better than the other?
  

We've traditionally worked in an ASP environment where everything is (without option) inline code. So the developers are most comfortable with that method of development. Unless there's a compelling reason to go with code-behind, we'll probably continue to code in an inline fashion.

 

Still, I notice that Visual Studio.NET defaults to the code-behind method, so I'm wondering if it is intrinsically "better" than the old method of combining code and content.

 

Advice and opinions are appreciated.

[PlausiblyDamp]

Code behind seperates the code from the interface - makes it easier for different teams to work on both parts, easier to work with source code control as well.

Also the IDE supports code-behind much better (auto-complete, tooltips etc.)

 

I personally can't think of many reasons to go with inline code rather than code behind.

[Robby]

I see no valid reason for using in-line code at all.

 

Also when you deploy an aspx file, you're code behind will stay in a compiled DLL.

[bungpeng]

What about the speed? which one is better?

As what I understand, DLL will be faster, is it true?