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

Bad Idea

[Anonymous Coward]

I'm sure many people will say this, but you learn much more from making mistakes and working out the problems than by reading a book on common mistakes.

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

[ansleybean]

a HUGE thing is not to plagarize code. I was a TA for CS101 at my school, and plagarism is not only rampant, but really really easily detectable. besides, you don't learn anything; although, as one of my professors said, "if you can copy someone else's code and alter it so I can't tell, you may as well have actually done the assignment."

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

[gcaseye6677]

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. 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. If professors really want to stop cheating, they need to take the initiative to assign work that requires creativity on the part of the students as opposed to submitting code that could be a cut and paste of textbook examples. Having had both kinds of professors in school, I saw first hand what kind of work students provide in each environment.

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.

Additional Advice

[nebaz]

Use the minimum number of keywords in the language as possible. For example, all loops (for, while, do) can all be handled by a simple if and goto statement.

Re:Additional Advice

[nebaz]

Oh, and also, always use labeled line numbers in multipes of 10. That way, if you need to insert lines later in the middle, you have some line numbers to use later.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Slashdotted ...

[ggvaidya]

but also mirrordotted :).

One thing not to do

[esac17]

I spent 2 days looking for a one character bug the other day, I hate these!

if (condition);
{
myvar = 1;
}

The block was a lot bigger than myvar = 1, and my eyes kept skipping over the ; .. of course when I found it I felt stupid .. and well I should have :) hey wait, maybe I should have posted this Anonymously ...

high school

[Anonymous Coward]

This may sound a bit odd, but I went back to my home country Iran for 2 years as a teenager. This is when I had my first insight into computer programming.

At the time I along with most students didnt have a computer, not did I have access to one properly.

I did my first BASIC coding on paper. Looking back, working that way worked extremely well.

Since then I always do some sort of rudimentary pseudo code on paper before implementing using a computer.

note: I never finished high school and I haven't been to university

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:Compiler Warnings

[nwbvt]

So let me get this straight, you didn't get that the article was a work of satire, yet this is the only part of it you felt needed to be challenged?

Re:Advice from a fellow student

[ErichTheWebGuy]

I heartily disagree. Personally, being buzzed (but not hammered) provides my otherwise erratic brain the opportunity to focus intently.

My motto: code drunk, debug sober

your code should read like a novel

[Simonetta]

Yes, seriously...
your code should read like a novel.

After finishing the program, compiling, and debugging it, get out your microphone and one of those speech-to-text programs. Train it if you haven't done so already by reading the presented text for twenty minutes or so. Do the training twice: once when sober and properly intoxicated. (Myself, I grew up in the 1970's and consider alcoholic beverages déclassé, but everyone has their own favorite intoxicant).
Get a picture of your favorite dreamboat celebrity and put it next to the screen. Load your source code on the editor and start the speech-to-text converter in the background.
Take a deep breath and gaze adoringly in eyes of the person in the photo. Pretend that they are hopelessly infatuated with everything that you say and just love to hear you talk about your programming.
Then start talking. Talk about your code. Start at the beginning. Talk about every line and what it does. How it works. How it fits. How totally cool it is. Just go on and on.
When you're done, turn off the speech-to-text generator running in the background and save the hopefully rather large text file.
Go back and cut and paste lines from the source file into the spoken description text file. (Use the speech-to-text engine to make this step go fast.)
Hopefully you will now have about a half a page or more of rambling, but technically dense and accurate, speech text for every line of source code.
This is the proper amount of commentary that every line of code needs.
Put comment markers around your spoken text and lots of white space above and below the actual source lines.
Your program is still good: it compiles and runs. But it now looks like a novel.

This is good! The single line coding format that we all use is an obsolete product from the 1950's when a byte of computer RAM memory cost more than a good restaurant dinner. Those days are gone.
Now you want to be able to read and understand the code quickly. It's far easier to glance and read through pages of rambling dictation describing the code than it is to try to understand 'normal' code with little pissant comments pasted randomly through it.
You're a professional now. Anything that makes your job easier is good .
If your CS professor disagrees, give them a copy of your speech-to-text software and a picture of Lindsey Lohan to place next to their screen and have them try it themselves.

What to do an not to do in CS

[nate nice]

Do not slack at your math. You will repeat it. It often takes time. It is very important. Learn to utilize math and make it one of your more powerful tools.

Do not cheat on code assignments. Once again, it may take time but you need it. Messing up and looking through code more than writing it is what really makes you good.

Take hard CS classes. Take advantage of rare courses your school may offer in CS. Take tough classes like compilers or computational geometry. Make sure you take some diverse classes but also try and focus on something a bit that you enjoy.

Take more math. This is a skill that can really differentiate you from other programmers in the industry, If you have good math skills, you can get good paying, secure jobs in fields like computer graphics, physics, medical and other science fields that demand proficient math skills. It will also change the way you think if you really take it seriously and understand that much of the early math is indeed lame, but necessary to understand useful math that you will eventually learn.

Take other classes, like art. You can learn a lot from these things and apply them to what you are doing. Knowing about various things will come in handy at some point.

Learn more than what your school will teach you. It is up to you to read about things in the field, both theory and practical. Learn languages not needed in your school. Play around with things. Put together a cheap Linux computer at home and play around in it if you haven't already. You are interested in this anyways, so this shouldn't be something you have to do.

Maybe CS is not for you. The future is not guaranteed in this field as far as job security is concerned. You may spend a lot of time taking hard classes only to have to end up doing something else. You may not even make it through the program. Personally, I think there will always be a need for well educated, creative, smart people. The analytic skills you can learn will do more for you than anything else. Pay attention.

If you love it and are good at it and really spend the time in school to really learn this art, you could enjoy a career working in an industry you love. If you are ambitious, there will be many trails to be blazed in the future in this young, ever changing field. It's not about "computers". It's about computation, a modern subset of math that we can abstract in electronics. The possibilities are endless and you may invent the next big thing.

Re:Bad Joke

[Martian_Bob]

I've got to disagree - for beginning CS students, compiling frequently is an excellent thing to do. I'm a CS TA, and most of the panicky emails I get from students the night before a project is due revolve around small, simple problems that get blown way out of proportion. A single misplaced semicolon can make the compiler spit out dozens of errors for lines of code below it, none of which will make any sense. Errors propogated through code are terribly difficult to detect; your program's output might be incorrect due to something that you wrote two class files ago and have already forgotten about. And then there's the problem of poor program planning combined with infrequent test compilations - namely, the design sucks donkey balls and you just spent three hours laying down the foundation for a code base that is completely useless. I wrote code like this until I because a grad student, and it shows - I spend way less time designing and write far better programs due to multiple test compilations.

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?

not stopping to think

[pres]

While some thought is, of course, necessary I have definitely seen the problem with new programming students of thinking too much.
Basically, they try to understand the whole problem fully before writing the first line of java or C. My feeling is that this is not possible for a new student. There is just too much. Rather you just have to write code at some point. Forcing yourself to try things in code is often the only way to really get started in your first programming language. (After the first one, you should be able to think as much as you want because you should have enough background not to get lost).
I have actually noticed this problem more in girl then guys. Guys tend to rush right in and try to hack it while girls try to understand it fully first. Sometimes the hacking approach is just the necessary one. (Of course this then flips in the second or third CS course where NOT fully thinking through the problem hurts more).

Re:Cheating.

[demonbug]

OBVIOUS, but always missed. If you need to cheat, change majors.

Yeah. Thats what the college of business is there for.

Re:Bad Joke

[aussie_a]

Why am I not seeing +4 Funny? Oh well, time to argue your ridiculous post point by point (I've got 2 assignments due tomorrow, I'm using this time as a break from coding, dear god I'm a nerd).

Compiling frequently is not good because you should not be thinking about such details as syntax and var name spelling until the very end.

As of tomorrow I will have done 5 assignments in C++ this year. For 4 of those assignments I didn't have a compiler at my home (our program had to compile in Turbo C++, you could tell who used different compilers at home). Instead I had to go to school to debug my programs, so what I did was I'd write out my code at home in a day, go to school and then spend a few days debugging it. For 1 of my assignments (my last one) I had a compiler at home so I could debug as I go. Guess which assignment I actually enjoyed. That's right, the last one. Not knowing if my code will work makes coding unfulfilling. Spending days debugging is tedious and stressful.

For most of the time you're writing code, what you have should not be compileable.

This just sounds plain lazy. Your code should (with as minimal effort as possible) always be compilable. If you've got a menu that calls 5 modules, write stubs for the modules. Utilise flags. This allows you to compile as you go along.

Who cares if you get a 100 compiler errors at the end when you compile once, vs. getting 1 error each time, but having to compile 100 times?

Actually it's closer to "create 100 errors get 10000 error messages, try to sieve through all the messages to find the correct 100." Whereas it's much easier to go through 10 error messages to find the correct 1. You'll notice you tend to get the same 9 error messages each time, whereas having 1000 makes it a lot more difficult. And this is just syntax errors. We're not even talking about logical errors (and yes, there will be some, no-one's perfect).

Focus on the higher picture. Implement your vision.

Actually you won't be implementing anything. You haven't implemented it until it's working. And focusing on the higher picture should be done in the PLANNING STAGE. NOT the CODING STAGE. Ideally you shouldn't even be on a computer when writing the algorithm (which is where you focus on the higher picture). You should have a pencil, a rubber and lots of pieces of paper. But even if you are on the computer it should be done in Pseudocode.

Say, you're done coding. All you have to do is go make tiny changes to shut up the errors. Probably won't have to think too hard how to fix them.

I bow before your intelligence, for you can write code without debugging it at all and only have "a couple of errors." You must truly be a coding genius. That or you're talking out you're ass. I haven't met anyone who can do what you just described. Not any students and not any teachers.

Also, sometimes I actually shock myself by writing code for an entire day and then having it compile w/o errors the first time!

Either you write simple code or you're a liar and/or a troll. Because the chances of that being true is (IMO) very small.

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.

MAVADDAT SPEECHLESS!!!

[Trepidity]

mavaddat prefer people not post on slashdot using mavaddat name

mavaddat work very long time downloading lecture notes for ungrateful kids paying only $700!

mavaddat remind you 30" lcd monitor needing to purchase but cost much more!!!!

MAVADDAT THE PROFESSOR!!!!! MAVADDAT BREAK HEAD WITH PLAGIARIZED CD!!!!!