Student WTFs
-
I'm sure I'm not the only one around here that has students, and not the only one that is currently spending a lot of time looking at student work.
-
[...and here's the rest of the post that got eaten.]
I'm sure I'm not the only one around here that has students, and not
the only one that is currently spending a lot of time looking at
student code.
I'm also pretty sure I'm not the only one who has thought "WTF" while
doing it. "Hmmm... that's a funny thing to hard-code." "Wow, that's
about 15 times longer than it needs to be." "Well, there's a security
hole you could drive a truck through."
That is all. I could submit some of their code, but that would be
wrong--they're still learning and shouldn't be mocked for it.
Hopefully I can correct the worst of it and keep them off TDWTF in the
future.
-
@gregbaker said:
Hopefully I can correct the worst of it and keep them off TDWTF in the future.
Kudos for even thinking about helping them become better programmers! IMO, many CS programs have been doing their students a disservice by just making sure they can produce the intended output and get the darn thing to compile. They seem to ignore the veritable wrats nest that is underneath.
-
@gregbaker said:
I could submit some of their code, but that would be wrong--they're still learning and shouldn't be mocked for it.
That's quite true, and thank you for acknowledging(sp?) that. In every way that matters, all developers are still learning. Much of the mockery here (not all, but some) is directed at pretentious developers who really should know better.
-
@gregbaker said:
I could submit some of their code, but that would be
wrong
Okay, I had to share this one--just because it's a good example of what happens when you stay in the lab too late:
$color = $darkyellow; /* light red */
-
@gregbaker said:
@gregbaker said:
I could submit some of their code, but that would be
wrong
Okay, I had to share this one--just because it's a good example of what happens when you stay in the lab too late:
$color = $darkyellow; /* light red */
That's what happens when you can't tell the doc that your shit is red and you have to describe it in shades of yellow or brown or their equivalents.
-
-
@gregbaker said:
@gregbaker said:
I could submit some of their code, but that would be wrong
Okay, I had to share this one--just because it's a good example of what happens when you stay in the lab too late:
$color = $darkyellow; /* light red */That's a good one. The interesting thing is that it's funny for the careful reader, but potentially misleading for the time-crunched developer who has to debug or upgrade the code after it's written. I've been guilty of this sin myself. As another reader noted, CS profs tend to lower the bar when grading code, probably more out of a lack of time than carelessness, but having seen the kind of code that passes muster in an undergrad program, it's no surprise that a lot of the stuff here on wtf exists.
Thanks for sharing and going the extra mile for your students. They'll appreciate feedback from their first real code-reviewer, though this site could suffer from your efforts to reduce the amount of material out there. People say America has lost its innovation edge, but I for one will redouble my efforts to innovate in the field of wtf, hopefully giving our children hope that they, too, can be innovators even in a competitive global marketplace.
-
where do you teach... i want to go there, if i'm paying all that money i want to actually be taught that i'm being stupid (too many times it's just output, and tabbed right i get an "A")
-
Coming from a student, this website is one of the best sites I have ever found. By showing what not to do, I know what to do.
-
@Oscar L said:
Thanks for sharing and going the extra mile for your students.
I'm not doing anything heroic... just smacking their hands for the worst offences.
-
As a current CS student, the code my peers and I write makes just as much sense as the project specifications - IE, none at all.
Here's an example timeline of a project we get.
Day 1 - Assigned
Day 3 - List of corrections
Day 5 - Yet more corrections
Day 7 - Another list of corrections
Day 8 - First tests created and posted
Day 10 - Hidden tests uploaded
Day 11 - Due date
And the specifications are just as bad. I mean, for this project, we are using a binary operator tree to parse expressions. All the structures are defined, and to access the value at a node, you literally write:
node->data.value.number.int_value
My code for this project is pretty much a WTF itself. Every single function converts the tree into prefix (polish) notation and parses it that way, then converts back into a tree. Waste of memory, yes, but it works.
-
@gregbaker said:
I could submit some of their code, but that would be wrong--they're still learning and shouldn't be mocked for it.
I agree with this -- I follow a policy to not post from messageboards or students. I strive to have the work of professionals (as in, those paid good money to do this) showcased.
@bullseye said:
IMO, many CS programs have been doing their students a disservice by just making sure they can produce the intended output and get the darn thing to compile. They seem to ignore the veritable wrats nest that is underneath.
This is not the purpose of a CS education or degree. "Good code" is the output of designing for maintainability, which is an underlying goal of Software Engineering.
I agree that recent grads are practically useless; I don't blame the science, more the educational system that doesn't stress SE more.
-
@akrotkov said:
As a current CS student, the code my peers and I write makes just as much sense as the project specifications - IE, none at all.
Here's an example timeline of a project we get.
Day 1 - Assigned
Day 3 - List of corrections
Day 5 - Yet more corrections
Day 7 - Another list of corrections
Day 8 - First tests created and posted
Day 10 - Hidden tests uploaded
Day 11 - Due date
And the specifications are just as bad. I mean, for this project, we are using a binary operator tree to parse expressions. All the structures are defined, and to access the value at a node, you literally write:
node->data.value.number.int_value
My code for this project is pretty much a WTF itself. Every single function converts the tree into prefix (polish) notation and parses it that way, then converts back into a tree. Waste of memory, yes, but it works.
You should attend a better school. I never ran into such problems.
sincerely,
Richard Milhouse Nixon
-
@Alex Papadimoulis said:
This is not the purpose of a CS education or degree. "Good code" is the output of designing for maintainability, which is an underlying goal of Software Engineering.
I guess I'd have to agree... I should rephrase my statement to say that many CS programs have been doing their students a disservice by neglecting SE practices. The majority of students enter the workforce wrongly thinking they have been properly prepared. To be fair, I don't think this is just restricted to CS programs, but I digress.
-
@gregbaker said:
@Oscar L said:
Thanks for sharing and going the extra mile for your students.
I'm not doing anything heroic... just smacking their hands for the worst offences.You'd be surprised how far beyond most profs' efforts this goes. I can sympathize, of course, because I've seen the code that most of my peers wrote. It would be enough to make almost anyone throw their hands up in the air and go get a job at a coffee house instead.
-
What about WTF code written by professors? Here is compiler written by one of our professors, intended to parse a simple language "PL/0" into a mockup assembly language. Our assignment was to add a couple of language constructs of our choosing.
He's an excellent professor, just not a very good lecturer.
-
@Snagglepuss said:
What about WTF code written by professors? Here is compiler written by one of our professors, intended to parse a simple language "PL/0" into a mockup assembly language. Our assignment was to add a couple of language constructs of our choosing.
He's an excellent professor, just not a very good lecturer.
Hang on - isn't that K&R C?
With more modern function definitions, some careful use of enums, clearer array initialisation, and some comments, it'd be more readable.
-
As a fourth-year CS student myself, and as part of a course-review
panel, we've asked this question many times. What can we do to
make our students better? We have run into all of these same
problems (flawed assignments, low expectations, no time to grade or
correct, lack of emphasis on SE practices, etc).
I agree whole-heartedly that you can't design a good system without
good specs. Can you expect good specs? Not realistically,
but they are a requirement nonetheless. The problem isn't with
requiring them, it's that they aren't available in the first
place. This is not the programmer's fault. However, it is
their responsibility to go back and say, "These specs aren't complete;
I need [this]." Prof's encourage asking questions, but few
students have the balls to do so.
Grading time is a huge problem. The answer? More
money. Prof's don't have time, and most markers are being paid
very little (as in, only a few hours) to mark 50-100 assignments.
No way in hell you could be expected to grade fairly, find bugs, and
offer corrections. I've found even receiving a one-line comment
is rare, even if you get a mark of 10/50.
But the most significant problem I find with students' programming
skills is that they haven't had time to develop them. They take
three or four courses, utilizing several different languages as tools
to learn concepts, and we expect them to be able to understand the
concepts and program them? Not likely. That's like teaching
me Math in Chinese, expecting me to learn both at the same time.
It's not a good way to teach either. Teach me Chinese, then teach
me Math. Or teach me Math first, then use it while teaching me
Chinese (this may not be realistic when we're talking about computer
programming).
Lastly, the real problem has nothing to do with how they are being
taught, or even what they are being taught. The real problem is:
what do we expect of them? A student graduating from CS could
know low-level programming, databases, number theory, algorithm design
and analysis, software engineering, and as much as a dozen
languages. And they don't even have to know all of these
areas. As one highly-skilled student pointed out, "A CS degree
isn't just about programming. You don't even have to write
programs or know any programming language to be in the CS field."
I think his point is obvious.
In my engineering program, the point is made very plain that what we
learn is a very general overview of everything we might need, and
certainly does not carry the breadth of everything we will encounter,
nor the depth to actually perform any job. All it does is give us
some basic tools so we can figure the rest out on our own when we need
it. I have found that CS does not make this point plain, and for
that matter doesn't even believe it. When pressed, they will
admit it, but they still teach like they can give you infinite breadth
and depth in only four years.
Don't expect a CS graduate to have even half-decent programming skills
any more than you would explain to somebody how a car works and how to
use all the tools and expect them to be able to fix your car.
Skills require more than learning methods: they require experience.
