Frans,
If you take the idea of using e&c and take it to extreme like developing
in debugger, that does not sound right for me either. However, in cases
where you have an app that takes lots of data from gui, and if this gui
is a web page, getting to a certain point in code requries time. In this
case e&c gives you the option to fix things in shorter time.  Please
remember the shades of grey in this context :) No one seems to be on the
extremes when it comes to debugger use.
regards
Seref

Frans Bouma wrote:
Frans Boumw:


        Well, one idea could be to drop E&C requiring

coding styles.

It's that simple. E&C propagates sloppy coding 'because you

can fix it

during debugging anyway', forgetting that debugging is

costly and time

consuming and should be avoided until the only way to

determine what

causes a bug is to start the debugger, carefully placing

breakpoints

etc.

That's ignoring the discovery and prototyping potential of E&C.


        Heh, sorry, but are you suggesting that writing code in a debugger 
(which I think you meant), is 'OK' ? Because I don't
think it is. But that can be because I'm in the think first, do later camp, 
while there are a lot of software developers who think
that doing and thinking can be combined during hammering in statements.

                FB

===================================
This list is hosted by DevelopMentorĀ®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com



===================================
This list is hosted by DevelopMentorĀ®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to