«

"Kevin Spencer" <> wrote in message
news:...
>> I think he slightly misses the point, as you were mentioning, that it is
>> more work on a small project. It is not necessarily that they don't like
>> it, it is just less work. If it is a larger project, it may be better in
>> most cases to write code-behind. But the biggest advantage, that I have
>> been able to gleen from this, is that multiple people can work on the
>> same application at the same time. But if you are the only person, this
>> advantage is lost.
>
> I didn't miss any point. Do you know the average length of time it takes
> to develop a habit? 6 weeks. So, assuming that you've been working with
> ASP.Net for more than 6 weeks, you've already developed some habits. Now,
> let's say you graduate from working on tiny applications to something of
> some size and scope. It will take you another 6 weeks to teach yourself to
> do it right.

You're assuming that code-beside is a bad habit.

Based on your last post, I think you are mixing arguments OOP is not
Code-behind. You called it an extension. I don't agree here. It would
take you a little while, as you correctly state, to learn new methods. OOP
will take a while to learn. But the difference between Code-Behind vs
Code-Beside is minimal, at least as far as I can fathom (and I could be
wrong here). Based on what I have seen, you can take a Code-Beside page -
take out the script section move it to another page - add some attributes to
the Page definition - On the code-behind page add the Namespace and Class as
well as a few imports that the aspx page takes for granted as well as the
defining the objects on the aspx page (I am getting tired just thinking
about it).

Any code you want to reuse you would put in a class (which you could do -
and should do - in either case).

I don't see a bad habit here.

Earlier it was mentioned:

"Not using codebehind is ignoring one of the largest benefits of the dotNET
architecture"

I don't agree here, either. I think the largest benefits of the dotNET
architecture is the *separation* of code from design elements (which you
didn't have in asp). A code-beside page does have the separation
(completely) from the design. It just happens to be on the same page.
>
> I've been programming for about 10 years now. This is not theory; it is my
> experience. In my experience, more work in the short run always leads to
> less work in the long run. Today is gone tomorrow. But tomorrow is always
> just around the bend.

I have been doing it for many more years than that (so I probably do have
some bad habits). More work in the short run does NOT always lead to less
work in the long run.

>
> My philosphy: If, when you are beginning, you develop and practice best
> practices, you will not be beginning for long.
>
> Programmers are a dime a dozen. Good programmers are rare. If you want to
> make money, you have to distinguish yourself. Start early, and you'll
> never be without a good-paying job.

Whether you use Code-behind vs Code-beside doesn't make a good programmer.
A good programmer, I guarentee you, can go from Code-beside to Code-behind
in no time at all. That doesn't mean he should.

Tom

> You're assuming that code-beside is a bad habit.

Not at all. I'm arguing that poor code organization is a bad habit. An
assumption is made without evidence. An argument, on the other hand,
provides evidence.

Also, note that I never made a specific argument about "Code-Behind." To
quote my earlier post:

> It's really the wrong question. It's not a matter of "Code-Behind" versus
> "Code-Beside." It's a matter of code organization in general.

You're presuming, however that that is the issue I was discussing, and had
made assumptions about. The concept of organizing code is much broader, but
does apply to specific issues. I side-stepped the specific issue, as it is
merely a symptom of the bigger (deeper) issue. Whenever I encounter a
specific issue, I tend to step back and have a look at the forest, to see if
there is a broad principle that needs to be applied overall. Once the broad
issue of code organization is identified and understood, it can be applied
specifically to all areas of development.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"tshad" <> wrote in message
news:e$...
> "Kevin Spencer" <> wrote in message
> news:...
>>> I think he slightly misses the point, as you were mentioning, that it is
>>> more work on a small project. It is not necessarily that they don't
>>> like it, it is just less work. If it is a larger project, it may be
>>> better in most cases to write code-behind. But the biggest advantage,
>>> that I have been able to gleen from this, is that multiple people can
>>> work on the same application at the same time. But if you are the only
>>> person, this advantage is lost.
>>
>> I didn't miss any point. Do you know the average length of time it takes
>> to develop a habit? 6 weeks. So, assuming that you've been working with
>> ASP.Net for more than 6 weeks, you've already developed some habits. Now,
>> let's say you graduate from working on tiny applications to something of
>> some size and scope. It will take you another 6 weeks to teach yourself
>> to do it right.
>
> You're assuming that code-beside is a bad habit.
>
> Based on your last post, I think you are mixing arguments OOP is not
> Code-behind. You called it an extension. I don't agree here. It would
> take you a little while, as you correctly state, to learn new methods.
> OOP will take a while to learn. But the difference between Code-Behind vs
> Code-Beside is minimal, at least as far as I can fathom (and I could be
> wrong here). Based on what I have seen, you can take a Code-Beside page -
> take out the script section move it to another page - add some attributes
> to the Page definition - On the code-behind page add the Namespace and
> Class as well as a few imports that the aspx page takes for granted as
> well as the defining the objects on the aspx page (I am getting tired just
> thinking about it).
>
> Any code you want to reuse you would put in a class (which you could do -
> and should do - in either case).
>
> I don't see a bad habit here.
>
> Earlier it was mentioned:
>
> "Not using codebehind is ignoring one of the largest benefits of the
> dotNET
> architecture"
>
> I don't agree here, either. I think the largest benefits of the dotNET
> architecture is the *separation* of code from design elements (which you
> didn't have in asp). A code-beside page does have the separation
> (completely) from the design. It just happens to be on the same page.
>>
>> I've been programming for about 10 years now. This is not theory; it is
>> my experience. In my experience, more work in the short run always leads
>> to less work in the long run. Today is gone tomorrow. But tomorrow is
>> always just around the bend.
>
> I have been doing it for many more years than that (so I probably do have
> some bad habits). More work in the short run does NOT always lead to less
> work in the long run.
>
>>
>> My philosphy: If, when you are beginning, you develop and practice best
>> practices, you will not be beginning for long.
>>
>> Programmers are a dime a dozen. Good programmers are rare. If you want to
>> make money, you have to distinguish yourself. Start early, and you'll
>> never be without a good-paying job.
>
> Whether you use Code-behind vs Code-beside doesn't make a good programmer.
> A good programmer, I guarentee you, can go from Code-beside to
> Code-behind in no time at all. That doesn't mean he should.
>
> Tom
>

>> Alan Silver
>> (anything added below this line is nothing to do with me)
>
>This has nothing to do with Alan Silver. Oh darn. It has his name it
>it.
>
>

You would be amazed what I get the blame for!! Even things without my
name on. If my name is on, then I'm *really8 in trouble!!

--
Alan Silver
(anything added below this line is nothing to do with me)

>> I think he slightly misses the point, as you were mentioning, that it is
>> more work on a small project. It is not necessarily that they don't like
>> it, it is just less work. If it is a larger project, it may be better in
>> most cases to write code-behind. But the biggest advantage, that I have
>> been able to gleen from this, is that multiple people can work on the same
>> application at the same time. But if you are the only person, this
>> advantage is lost.
>
>I didn't miss any point. Do you know the average length of time it takes to
>develop a habit? 6 weeks. So, assuming that you've been working with ASP.Net
>for more than 6 weeks, you've already developed some habits. Now, let's say
>you graduate from working on tiny applications to something of some size and
>scope. It will take you another 6 weeks to teach yourself to do it right.

Well, each of us is different, so I guess we can happily agree to have
different ideas on this, but I have more than one behaviour pattern and
can change from one to the other depending on the situation.

This doesn't just apply to programming, it applies to being a father,
running a voluntary organisation, almost anything in life. I have
behaviour patterns suited to different situations. In the case of web
programming, I have ASP behaviour patterns that I apply for small sites,
and ones I apply for larger sites. I use whichever is appropriate. I
rarely get it wrong nowadays, and rarely (almost never) waste any time
with short-term conveniences that lead to long-term problems.

>I've been programming for about 10 years now. This is not theory; it is my
>experience. In my experience, more work in the short run always leads to
>less work in the long run. Today is gone tomorrow. But tomorrow is always
>just around the bend.

You are of course entitled to your experience and your opinion, as long
as you accept them for the subjective points that they are. I have been
programming for over 20 years (yup, I'm that old!!), and have learnt how
to distinguish between a small job and one that may grow. I can't
remember the last time I got that wrong. I apply the behaviour pattern
that suits best.

>My philosphy: If, when you are beginning, you develop and practice best
>practices, you will not be beginning for long.

Correct. But developing best practices does *not* mean applying one
mindset to every situation, it means being flexible enough to know what
to do in any situation.

>Programmers are a dime a dozen. Good programmers are rare. If you want to
>make money, you have to distinguish yourself. Start early, and you'll never
>be without a good-paying job.

Well, I think the current IT slump might prove you wrong, there are
plenty of good programmers who can't get jobs, not because they aren't
good, but because there aren't always enough jobs, and managers are
being convinced that anyone can program. They are shown slick
presentations where someone creates an apparently complex application
from scratch in about ten minutes using the latest Visual Studio RAD
tools. They go away believing that a student fresh out of college can do
the same job as a highly trained and experienced professional with 20
years' experience. That's bad for everyone.

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

"Kevin Spencer" <> wrote in message
news:%...
>> You're assuming that code-beside is a bad habit.
>
> Not at all. I'm arguing that poor code organization is a bad habit. An
> assumption is made without evidence. An argument, on the other hand,
> provides evidence.

I agree.

But the fact that you use Code-beside, doesn't mean your code is poorly
organized. Alan made this point very well.

This is not to say that I disagree with using Code-Behind, because I don't.
>
> Also, note that I never made a specific argument about "Code-Behind." To
> quote my earlier post:
>
>> It's really the wrong question. It's not a matter of "Code-Behind" versus
>> "Code-Beside." It's a matter of code organization in general.

But this was the whole discussion. The benefits of one over the other.
Putting the code in a separate file (physically separated) or in the same
file (where it is logically separated) does not make it more organized.
Reuse of code would not necessarily be in your Code-Behind, anyway, but
could be in a different class.

> You're presuming, however that that is the issue I was discussing, and had
> made assumptions about. The concept of organizing code is much broader,
> but does apply to specific issues.

I agree here.

>I side-stepped the specific issue, as it is merely a symptom of the bigger
>(deeper) issue. Whenever I encounter a specific issue, I tend to step back
>and have a look at the forest, to see if there is a broad principle that
>needs to be applied overall. Once the broad issue of code organization is
>identified and understood, it can be applied specifically to all areas of
>development.

But then you miss the point of the question when you do this. If I want the
parameters of a particular call, I don't want to know bigger issue.

I never disagreed with your points, only that it was the only way or the
best way in *all* situations.

Tom

"Alan Silver" <alan-> wrote in message
news:...
>>> I think he slightly misses the point, as you were mentioning, that it is
>>> more work on a small project. It is not necessarily that they don't
>>> like
>>> it, it is just less work. If it is a larger project, it may be better
>>> in
>>> most cases to write code-behind. But the biggest advantage, that I have
>>> been able to gleen from this, is that multiple people can work on the
>>> same
>>> application at the same time. But if you are the only person, this
>>> advantage is lost.
>>
>>I didn't miss any point. Do you know the average length of time it takes
>>to
>>develop a habit? 6 weeks. So, assuming that you've been working with
>>ASP.Net
>>for more than 6 weeks, you've already developed some habits. Now, let's
>>say
>>you graduate from working on tiny applications to something of some size
>>and
>>scope. It will take you another 6 weeks to teach yourself to do it right.
>
> Well, each of us is different, so I guess we can happily agree to have
> different ideas on this, but I have more than one behaviour pattern and
> can change from one to the other depending on the situation.
>
> This doesn't just apply to programming, it applies to being a father,
> running a voluntary organisation, almost anything in life. I have
> behaviour patterns suited to different situations. In the case of web
> programming, I have ASP behaviour patterns that I apply for small sites,
> and ones I apply for larger sites. I use whichever is appropriate. I
> rarely get it wrong nowadays, and rarely (almost never) waste any time
> with short-term conveniences that lead to long-term problems.
>
>>I've been programming for about 10 years now. This is not theory; it is my
>>experience. In my experience, more work in the short run always leads to
>>less work in the long run. Today is gone tomorrow. But tomorrow is always
>>just around the bend.
>
> You are of course entitled to your experience and your opinion, as long as
> you accept them for the subjective points that they are. I have been
> programming for over 20 years (yup, I'm that old!!), and have learnt how
> to distinguish between a small job and one that may grow. I can't remember
> the last time I got that wrong. I apply the behaviour pattern that suits
> best.
>

Me too. Hard to believe, sometimes.

>>My philosphy: If, when you are beginning, you develop and practice best
>>practices, you will not be beginning for long.
>
> Correct. But developing best practices does *not* mean applying one
> mindset to every situation, it means being flexible enough to know what to
> do in any situation.
>
>>Programmers are a dime a dozen. Good programmers are rare. If you want to
>>make money, you have to distinguish yourself. Start early, and you'll
>>never
>>be without a good-paying job.
>
> Well, I think the current IT slump might prove you wrong, there are plenty
> of good programmers who can't get jobs, not because they aren't good, but
> because there aren't always enough jobs, and managers are being convinced
> that anyone can program. They are shown slick presentations where someone
> creates an apparently complex application from scratch in about ten
> minutes using the latest Visual Studio RAD tools. They go away believing
> that a student fresh out of college can do the same job as a highly
> trained and experienced professional with 20 years' experience. That's bad
> for everyone.
>

I can tell you from experience that this is the case.

Tom

> Ta ra
>
> --
> Alan Silver
> (anything added below this line is nothing to do with me)

Understood, Alan. I wasn't specifically trying to tell you what to do. I was
posting for the benefit of everyone who reads the thread. Of course, each of
us must make their own decisions regarding what is best.

> Well, I think the current IT slump might prove you wrong, there are plenty
> of good programmers who can't get jobs, not because they aren't good, but
> because there aren't always enough jobs, and managers are being convinced
> that anyone can program. They are shown slick presentations where someone
> creates an apparently complex application from scratch in about ten
> minutes using the latest Visual Studio RAD tools. They go away believing
> that a student fresh out of college can do the same job as a highly
> trained and experienced professional with 20 years' experience. That's bad
> for everyone.

I do have to disagree with this point. Managers, like programmers, are a
dime a dozen. Good managers are rare. But the good managers know how to find
and hire the good programmers! I, for one, have never had trouble
finding work. I did have to give up my independent consulting business when
the DotCom crash broke out, but I've had several good jobs since then, and
more offers than I care to have to deal with.

As my old Drill Sergeant taught me many years ago: The maximum effective
range of an excuse is 0 meters.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"Alan Silver" <alan-> wrote in message
news:...
>>> I think he slightly misses the point, as you were mentioning, that it is
>>> more work on a small project. It is not necessarily that they don't
>>> like
>>> it, it is just less work. If it is a larger project, it may be better
>>> in
>>> most cases to write code-behind. But the biggest advantage, that I have
>>> been able to gleen from this, is that multiple people can work on the
>>> same
>>> application at the same time. But if you are the only person, this
>>> advantage is lost.
>>
>>I didn't miss any point. Do you know the average length of time it takes
>>to
>>develop a habit? 6 weeks. So, assuming that you've been working with
>>ASP.Net
>>for more than 6 weeks, you've already developed some habits. Now, let's
>>say
>>you graduate from working on tiny applications to something of some size
>>and
>>scope. It will take you another 6 weeks to teach yourself to do it right.
>
> Well, each of us is different, so I guess we can happily agree to have
> different ideas on this, but I have more than one behaviour pattern and
> can change from one to the other depending on the situation.
>
> This doesn't just apply to programming, it applies to being a father,
> running a voluntary organisation, almost anything in life. I have
> behaviour patterns suited to different situations. In the case of web
> programming, I have ASP behaviour patterns that I apply for small sites,
> and ones I apply for larger sites. I use whichever is appropriate. I
> rarely get it wrong nowadays, and rarely (almost never) waste any time
> with short-term conveniences that lead to long-term problems.
>
>>I've been programming for about 10 years now. This is not theory; it is my
>>experience. In my experience, more work in the short run always leads to
>>less work in the long run. Today is gone tomorrow. But tomorrow is always
>>just around the bend.
>
> You are of course entitled to your experience and your opinion, as long as
> you accept them for the subjective points that they are. I have been
> programming for over 20 years (yup, I'm that old!!), and have learnt how
> to distinguish between a small job and one that may grow. I can't remember
> the last time I got that wrong. I apply the behaviour pattern that suits
> best.
>
>>My philosphy: If, when you are beginning, you develop and practice best
>>practices, you will not be beginning for long.
>
> Correct. But developing best practices does *not* mean applying one
> mindset to every situation, it means being flexible enough to know what to
> do in any situation.
>
>>Programmers are a dime a dozen. Good programmers are rare. If you want to
>>make money, you have to distinguish yourself. Start early, and you'll
>>never
>>be without a good-paying job.
>
> Well, I think the current IT slump might prove you wrong, there are plenty
> of good programmers who can't get jobs, not because they aren't good, but
> because there aren't always enough jobs, and managers are being convinced
> that anyone can program. They are shown slick presentations where someone
> creates an apparently complex application from scratch in about ten
> minutes using the latest Visual Studio RAD tools. They go away believing
> that a student fresh out of college can do the same job as a highly
> trained and experienced professional with 20 years' experience. That's bad
> for everyone.
>
> Ta ra
>
> --
> Alan Silver
> (anything added below this line is nothing to do with me)

>Good managers are rare. But the good managers know how to find and hire
>the good programmers!

You've just disproved your own argument. Good managers are rare,
therefore the number of managers hiring good programmers are rare. So
the good programmers don't necessarily get the jobs.

--
Alan Silver
(anything added below this line is nothing to do with me)

> You've just disproved your own argument. Good managers are rare, therefore
> the number of managers hiring good programmers are rare. So the good
> programmers don't necessarily get the jobs.

You didn't read carefully. I said that the good managers know how to find
and hire the good programmers. Since both good programmers and good managers
are rare, the number of each is such that neither good managers go wanting
for good programmers, nor do good programmers have a hard time finding jobs.
And I backed it up with my own experience.

A programmer is a problem-solver. Lack of employment is a problem. Good
programmers, who are by nature good problem-solvers, approach the issue as a
problem and solve it. Average programmers look at what everyone else is
doing, and try that.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"Alan Silver" <alan-> wrote in message
news:...
> >Good managers are rare. But the good managers know how to find and hire
> >the good programmers!
>
> You've just disproved your own argument. Good managers are rare, therefore
> the number of managers hiring good programmers are rare. So the good
> programmers don't necessarily get the jobs.
>
> --
> Alan Silver
> (anything added below this line is nothing to do with me)

My recommendation is that if your application isn't very complicated, to
simply put all your code behind into a single file. Multiple classes can
exist within the same codebehind file and it makes for one central location
where you can go to modify all logic for your entire application.

I've developed many small apps in dreamweaver using this method and find it
quite streamlined. Less files to edit, less files to upload, etc.

"tshad" wrote:

> I am just trying to decide whether to split my code and uses code behind. I
> did it with one of my pages and found it was quite a bit of trouble.
>
> I know that most people (and books and articles) like it because you can
> split the code from the design. That is logical. But if you are the only
> one working on the code, it seem a little overkill.
>
> I use Dreamweaver to do my design and find it a bit of a hassle to have
> multiple files open for each of my pages as I am working on them. I
> typically have 3 or 4 pages open at one time that I am working on which
> translates into 6-8 files open.
>
> If I add an object to my design page I need to go the codebehind page to
> define it there. If I was working with multiple people on a page, I would
> need to run over to the person working on the codebehind and tell him to add
> the new object to his page.
>
> Things that are assumed on the .aspx page are not assumed on the codebehind
> and have to be explicitly defined.
>
> None of this is really talked about when codebehind is mentioned. Normally,
> you are told that it is better. Is this the case in all situations?
>
> Just trying to get other opinions on this, as I have already have about 30
> pages designed and am trying to decide if I should split the files or not.
>
> Thanks,
>
> Tom
>
>
>