Slashdot Mirror
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!)"
I found that if you googled most of the CS lecture notes, most of them were plagiarized from some other school....
eat shiat and bark at the moon
Anyone want to see it? If you can get the page to load, click on the chart icon which leads you here...
12:32 EST 20 octubre 2004 1223... Took 300 hits since 2 minutes ago.. Neat
I highly (so to speak) advise avoiding coding under the influence of daytime cold medicine. The nighttime ones are not so bad, as they make me go to sleep and stay away from my keyboard. Dayquil on the other hand...
Well, the code was 100% accurate and fast, but when I went to refactor it, the logic was so bizarre that it was easier to rewrite it from scratch. It didn't run any faster [insert snide comment about my lack of skill here], but at least some random person could sit down and figure out what was going on afterwords.
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
There are a few things that you can still look for, here:
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.
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.
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...
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.
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?
Since then I always do some sort of rudimentary pseudo code on paper before implementing using a computer. - congrats. You and me, both. I didn't have a computer at 11, and that is when my grandma bought me a book on programming. Only the book was an adventure story and in order to progress in the story, I had to solve tricky problems that became more and more complex as the reading went on. For each new problem set I had to learn yet another programming concept, conditions, loops, function calls etc. The book was structured in a way that would not allow one to understand what was going on without solving the problems.
I didn't have a computer, but I became insanely interested in them and I did write my first dozens of programs on paper and traced them that way. Wrote games something like robots and FPSs on paper. Later was able to type them into translators and they worked.
Argh, where is my childhood?
You can't handle the truth.
A friend of mine once had a large windowing class he needed to write. He was late on a project and basically needed it done Now. Or sooner. So he resigned himself to an all-nighter and got crunching.
Round about 8pm, he realized he was getting overly stressed, and he still had about half the code left to write. So he decided to take an hour break, smoke some pot, and come back to the project after he was a little unwound.
The next thing he remembers is waking up the next day. He had that dawning moment of realization that I'm sure all of us have experienced at one point in our lives - "Oh CRAP I screwed up" - and ran to his computer to finish the code as fast as he could.
The code was finished.
Several thousand lines, all commented, all readable even without comments. The interface was clean. The implementation was clean. It was finished.
To this day, he has never remembered writing even a single line post-toke. He has also never found a single bug, and he's used that code quite often. Now, I don't recommend relying on this technique - but once in a while, it seems to work.
Breaking Into the Industry - A development log about starting a game studio.
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.
A few extra spaces can really help you catch mistakes when your using a lot of nested parenthesies. ( ( (th) ( (i)(s) ) ) is much easier to read than (((th)(i)(s))) if your trying to make sure you don't screw up your parenthesies.
Personal preference, I guess. I was able to almost immediately tell that the tighter set was correctly balanced, but I had to spend a lot more effort to determine that the first set is missing a closing parenthesis.
I can't help but wonder if your mistake was intentional humor, or unintentional irony.