AySz88 wrote:DeadCatX2 - I'm very confused as to what you want...to what degree do you want these things taught in CS? Wouldn't some debugging skills and CVS or SVN be taught for assignments (for code-based courses)? I see that there's very little Software Engineering taught explicitly in Computer Science curricula, but there's at least enough taught by TAs for students to handle the logistics of programming and enable them to actually finish their assignments. ... Perhaps we're looking at two different angles of Computer Science - you seem to be coming from the engineering approach (code), while I'm more familiar with looking at CS as a branch of mathematics (theory).
I think part of the problem stems from the general consensus that Computer Science graduates are computer programmers. I think you're right in that the field
of Computer Science is, specifically, more math oriented than programming oriented. In industry, however, a CS grad is quite often made to do what is more appropriately called Software Engineering.
So long as CS grads are, in practice, generally writing production code, I think that SE should be a significant portion of the curriculum (say, 12-16 credits which are tailored specifically to teach SE fundamentals).
I won't pretend that I know much about software engineering, but I think asking professors about "testing methodologies, automation approaches, compare/contrast various coding styles" (as you suggested in your first post) is getting into details which they shouldn't be expected to know, as those seem to start to vary too much between individual apps and businesses and such. (Or, at least, my professors have mostly dismissed teaching these things as useless by graduation, they say either because approaches become disfavored too quickly or because specific corporate cultures will likely be rammed down the throats of those who go down the SE path anyway....but that could be an excuse for not teaching things they don't know.
While I agree that each business, application, or API will have its own style, that should not negate the usefulness of teaching the fundamentals
. For instance, a competent CS grad should have at least heard
of Hungarian notation, and ideally would understand the purpose, merits, and flaws of such a notation. Otherwise, they eventually link against a Microsoft API and are forced to use Google to figure out what the hell a LPCSTR is (though they would likely still need to Google to understand what it stands for).
After all, there is some basic style which is indoctrinated into all new programmers (use comments, descriptive variables, etc). It certainly couldn't hurt to teach a basic style, or discuss various styles and their pros/cons. Better than letting the poor programmers develop whatever haphazard style that emerges from their untrained mind.
(I don't really understand what you mean by "error handling" now, and you keep bringing that up... I thought that you meant user-friendly handling of corner cases and invalid input, but now I'm not exactly sure. Of course, the fact that I don't know what you're talking about might be proving your point.
I mean things like catching and handling exceptions (most people never pay attention to what exceptions a given function might throw), processing return values to ensure that the function call completed successfully (PARTICULARLY when writing kernel-mode code), terminating gracefully (storing important data in a temp file if the program crashes, and checking when it next opens for signs of abnormal termination)...corner cases and invalid input are also a part of that.
To expand more: Computer scientists would rather have super-fast "quality" code for a proof-of-concept, even if it's buggy on some corner cases or insecure on invalid inputs (as long as those things were irrelevant to the concept being demonstrated). "Correct" code that is much slower is totally irrelevant "quantity" to a CS person, and time invested to produce such code is not worth it. On the flip side, software engineers would rather have slower secure "quality" code, instead, to have something fit for public release, and fast but buggy code is useless "quantity" to them. (Of course, the optimum is to have both...
I concur, the optimal approach is to have both an efficient algorithm and a wholesome, bug-free implementation. Consider, however, that many SEs code their implementations directly from the example given by a CS. Many of these examples fail to mention corner cases or failed return values. I'm not even asking that the CS implement the error checking, only that they mention it ("algorithm does not check X for equality to zero; may throw a DivideByZero Exception if inputs are not checked").
And, again, consider that the typical CS grad often finds themselves doing work more appropriately referred to as SE. It would help if those CS grads were indoctrinated with at least the fundamentals of writing good code.