[Dave Flowerday]

Originally Posted by Joe Johnson

Have you ever heard a Civil Engineering guru argue that only the only way to cross a valley is with a suspension bridge - all other methods are beneath consideration? Or a Mechanical Engineer ever insist that the only REAL heat engines are based on the Stirling Cycle? I see this kind of borderline religious zealotry all the time in the electronics & computer engineeing worlds and it drives me nuts.

Couldn't agree more with this. I think an important aspect of being an engineer is being able to evaluate lots of different solutions to a problem and pick the one that best meets all the requirements (including things like cost, time to implement, robustness, how easy it is to understand for future engineers who may need to modify it, etc.). And hopefully you don't feel that all computer engineering people are zealots .

Originally Posted by KenWittlief

One shot timers are the simplist form of asynchronous logic - but if you open the door to these, then you allow asychronous logic into the designers toolbox, and then where do you draw the line?

Shouldn't it be the burden of the engineer designing the solution to know where to draw the line? He/she should understand the risks/rewards of such a solution and should be able to understand where to draw the line given the needs of the project/product (which are not constant from one project to another - as Joe pointed out, sometimes the tradeoffs are acceptable given the project requirements).

Originally Posted by KenWittlief

Looking at SW again, if a subroutine has one entry point, and one exit point, its easy to understand the flow of your code - but if you have goto statements allowing your code to jump all over the place, you quickly end up with spagetti algorithms.

Hard and fast rules such as "absolutely no gotos" can sometimes do as much damage as using gotos all over the place. While rare, there ARE times when the use of a well-placed goto (or break, or continue, or early return, etc.) can greatly simplify code and therefore increase readability and maintainability, or be necessitated for performance reasons in small embedded systems, etc. Enforcing the "no gotos" rule in college might make sense such that the students don't develop a bad habit of using them, but in my opinion it should be explained like this: "Sometimes, using a goto may be necessary or appropriate. This will be your job as an engineer to make that determination. However, the assignments for this class are not sufficiently complex to justify the use of a goto statement. Hence, use of goto is not acceptable in your solutions."