Re: Code Behind vs not

From: Kevin Spencer (kevin_at_DIESPAMMERSDIEtakempis.com)
Date: 02/22/05 

Date: Tue, 22 Feb 2005 09:12:34 -0500

Very good points all, Xepol. I was particularly impressed with the
discussion of compromise in programming, which is a rather advanced but
important idea to embrace. Once you have a good grasp of the tools, it is
important to remember that code efficiency is not the only goal to shoot
for. A few cycles here and there don't make a lot of difference with
computing power at its present level, but code readability and
maintainability are certainly high priority, as programmer man/hours are
expensive. 

-- 
Kudos,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"Xepol" <Xepol@discussions.microsoft.com> wrote in message 
news:679A4772-0253-48C1-9188-5697508C1E2A@microsoft.com...
>
>
> "tshad" wrote:
>> If I have a choice between the most efficient and the most readable and
>> maintainable - the best way is not necessarily going to be the same.
>
> The best code is both readable and maintainable and balances efficency.
> Why?  Because truly efficent code in NEVER readable, and NEVER 
> maintainable.
>
> True efficiency comes from breaking rules, and the code is ALWAYS ugly and
> you can only maintain the code only if you truely understand it.  True
> understanding is a result of readability.  If you had to read the code to
> understand it, and understand the code to read it, you've got a catch22 
> that
> most people will never get past.
>
> Besides which, you are writing code for a stack based machine without
> registers which will ultimately be compiled to SOME hardware SOMEWHERE 
> with
> or without registers, using SOME sort of optomization.  It is impossible 
> to
> reach the true ideal of "efficent" code with that many levels of 
> abstraction
> in the way.
>
> Shoot for reasonable efficency and make your code both readable and
> maintainable, because you ALWAYS end up having to work on code again 3 
> years
> after you though you'd never see it again (or worse, someone else).  And
> frankly, spending copious amounts of time trying to read code to figure 
> out
> what it does and how to modify it without breaking everything is decidedly
> inefficent.
>
> That said, inline code is good for single page projects where very simple
> operations are being performed (I even have 1 page designed like that, it
> contains about 3 lines of code, hardly worth code behind!). However, 
> inline
> code is horribly inefficient when dealing with a project that contains 
> more
> than 3 pages which interact (and even if you don't think you are making
> objects, think again, each page is an object).
>
> I think, however,  we need to discuss your use of tools.  I believe you
> mentioned you were using Dreamweaver.  I suspect that you will find that
> OTHER tools, such as Visual Studio are significantly more efficent when it
> comes to working with ASP.NET pages (you will also find tools from other
> vendors such as borland, so you are not restricted just to MS, but even as 
> a
> long time delphi programmer, I prefer VS to borland in this arena).
>
> If you would like to see how a larger scale project works with code 
> behind,
> check out dotnetnuke (www.dotnetnuke.com), and just imagine how 
> unbelievably
> hard it would be to manage the project with inline code (esp. since 
> they've
> abstracted commonly used code into objects with no associated pages).
>
> Hope that helps.

Relevant Pages

  • Re: Code Behind vs not
    ... > maintainability are certainly high priority, ... >> The best code is both readable and maintainable and balances efficency. ... >> understanding is a result of readability. ... >> long time delphi programmer, I prefer VS to borland in this arena). ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: C# Command to Wait a Specified Period of Time
    ... I'm sure that once one gains experience with these newer language constructs that they do enhance "readability" - for the people who know and use them. ... But the fact of the matter is that, at least in my experience, the vast majority of people making a living as a "programmer" still struggle with objects and events, let alone delegates, anonymous methods, and the like. ... But don't go around saying that a code block consisting of delegates and anonymous methods is "more readable" than a simple "for loop". ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)
    ... Python get's my vote for most readable in this case. ... > That's actually my biggest problem with Perl. ... to improve code readability, ... > programmer, who wasn't completely confused by their ...
    (comp.lang.ada)
  • Re: should i write keywords uppercase?
    ... programmer seems to develop his own style. ... and plenty of good commenting is quite desirable. ... I imagine you'll also get advice on other readability issues, ... > How do professional fortran-coder write? ...
    (comp.lang.fortran)
  • Re: FizzBuzz
    ... the ultimate of maintainability, something like this is likely to be ... makesub fizz? ... array, ... And if you want readability, ...
    (comp.lang.forth)