Programming Assignment Guide For CS Students

kennelbound writes "For those students just getting started in a Computer Science degree or a career in software development, this guide has been written to help you understand what NOT to do when coding a project. Those with a little more experience should still read it to get a good chuckle (and hopefully the mistakes stated within will not seem too familiar!)"

Comments

The best advise....

[cjjjer]

For those students just getting started in a Computer Science degree or a career in software development.....

Quit now and take up a skilled trade. The odds that you will be employed in the future are marginal at best. While most here might think that as trolling or flame-bait it's the cold reality. I have several friends who are tradesmen who say in the next 5-10 years there will be a significant shortage of highly qualified tradesmen. Where as everyday more software jobs are going off shore, it's pretty hard to send manual labor off shore and be competitive.

My $0.02

Re:i can't get to the article, but...

[Christopher Thomas]

This really depends on how well the professor defines the assignment. If every aspect of the programming assignment is spec'd out to the point that there would only be one correct answer, it would be easy to get away with cheating since all of the good submissions would look the same.

There are a few things that you can still look for, here:

• Nearly identical style.
  This includes names, indenting, order of functions, spacing conventions, and so forth. Some similarity could be coincidence. Nearly identical style is very suspicious, especially if any of the other flags come up too.
  
  
• Nearly identical discussion.
  Many assignments (like the ones I'm currently marking, for instance) require a short write-up explaining what they did. This may only be a few sentences, but people who cheat tend to either copy it word for word, or do a broken copy of it taking key words and trying to paraphrase the rest. Usually badly. This leads into the next point.
  
  
• Identical mistakes.
  Two assignments. Both would fail on their own lack of merits, but curiously, they both made exactly the same set of errors, in addition to having very similar style. Not likely to be concidence, that. Especially since they were...
  
  
• Handed in on top of each other.
  These assignments are put in a drop box. Electronically submitted assignments are usually datestamped. Cheaters, once they finish cheating, tend to submit at the same time (at least in this course). Finding two matching assignments in a stack of a hundred would take a good memory (or a heuristic checker). Finding two matching assignments that are right on top of each other, or within a few entries of each other, is much easier.
  

Despite the fact that it's _possible_ to cheat without detection, a large number of people don't. Remember, the people who are cheating are the ones who can't hack a first-year CS course. While there will be exceptions, the kind of person who can't figure out how to make "hello, world" or set up a very simple Excel spreadsheet, with the instructions in front of them, is probably not going to be very good at cheating either.

If, however, the professor assigned a creative problem solving exercise and a proper solution could take many different paths, 2 or more identical submissions would be a dead giveaway of cheating.

The problem is that it's very hard to do this in a way that's easy to mark. In an ideal world, that wouldn't matter, but in practice, some poor TA is going to have to try to mark 200 assignments in 3 hours. That's hard enough when they _are_ written to be easy to mark (I still wince at the memory of one marking assignment that involved digesting a 5-page report and then visually determining whether another 5 pages of non-trivial code worked or not).

In summary, despite the fact that we're stuck giving cookie-cutter assignments for practical reasons, the cheaters (that I see, at least) seem to be as bad at cheating as they are at doing the work.

What would've been more helpful

[xRelisH]

might be a list of common typoes and also weird compile errors that often scare newer programmers. Here's are a couple that I know of

if( blah = true ){ // common single equal sign mistake
}

if( someclass->someMethod ){//I know of some compilers that do NOT give you a warning when you forget to put brackets in a function call.
}

As for compile errors, one that ususally scares newer programmers is making a mistake in a header file that in return causes a whole lot of other errors. This happens when you forget to put a ";" in a class definition in a header file, then in the source file, you include "someheader.h" and then include "" below it, I've noticed a lot of compilers spew out odd errors that can very confusing.
Another common compile error deals with mismatched curly brackets, editors like vim will point this out, but I know some 2nd year students here in Computer Engineering that still want to use Notepad and refuse to try anything else.
Anyone know of any others?

Develop a programming conscience

[Viv]

I've gone back to school, and have noticed that I have something that makes me a much better programmer than my peers.

Over the years, I've developed a little voice at the back of my head that speaks up every time I am having problems with code I've written.

It asks me, "Is the problem you're having a result of a broken implementation, or is it the result of a design that lends itself to a broken implementation?"

With a good design, the code is not only easy to bang out, but the good design will tend to prevent you from making errors in the implementation. With a poor design, the code is hard to bang out, and it actually tends to cause you to make errors.

Develop this programming conscience. Constantly ask yourself, "Is my bone-headedness in the code itself, or the design?".

This will make your life easier.