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