The issue of coding style and standards has come up with work...
I am curious to hear others' comments on the topic, and article/book
references...
My assumptions:
- Performance is important, but it's not the only consideration (others
would be development time, maintainability, extensibility, etc...).
- Performance often comes at a price (it can take away from readability of
code and adds complexity thereby taking away from maintainability or added
time to development).
What I like to do:
There's are different stages of development.
In general I try to keep the asp logic code up at the top of the page,
with html (as html - i.e. switch context) down below and plug in variables
or function calls where/as appropriate with <%=whatever%>.
I will even switch context in loops.
Why I like to do it this way:
I work with asp and html. I like to see the html as html (color coded and
formatted with indentation).
When I have the html as strings and response.write it or build the html as
strings it often gets too messy to deal with later. This way, I
can "seperate the logic from the presentation" as much as possible and it
helps me keep the page maintainable (i.e. readable).
What about performance?
To begin with, some performance hits are worth taking! We write in asp
code not assembly language, right ;-)
Therefore, even if it did take a toll on performance I would still
consider coding this way.
If the performance hit were "too high", I would still probably write my
code the same way I like to and later on in the development stages, once
the html part was "set in stone" I would start optimizing for performance
and response.write it...
Even so, I've seen numerous "benchmarks" showing that in nt4 context
switching was a hit to performance (although I'm not sure it's always such
a "significant" hit that it takes away the benefits of context switching)
HOWEVER in asp 3.0 on win2k context switching can even perform better and
is not a performance hit.
My questions:
1) what are your thoughts?
2) what do others do and why?
3) any resources to point us to?
Thanks,
Arthur Gaisin
agaisin@c..., agaisi1@g...