Programming Assignment Guide For CS Students 761
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!)"
Most of the Prof's lecture notes are plagarized (Score:5, Interesting)
Ye old Slashdot Effect (Score:5, Interesting)
12:32 EST 20 octubre 2004 1223... Took 300 hits since 2 minutes ago.. Neat
Re:Advice from a fellow student (Score:5, Interesting)
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.
Re:Advice from a fellow student (Score:4, Interesting)
This was actually a rule at a company for which I worked. We'd occasionally have beer or wine at company parties and such, and writing code after drinking was verboten. You could go back to your desk and work on design, documentation, etc. But no programming after drinking.
It's a damn good rule.
Comment removed (Score:5, Interesting)
Bad Joke (Score:3, Interesting)
Actually that's uncalled for. Compiling frequently is not good because you should not be thinking about such details as syntax and var name spelling until the very end.
For most of the time you're writing code, what you have should not be compileable. Well, doesn't need to be. Since you (hopefully) are doing things top-down, at first you're going to have a lot of empty functions and comments.
Then you're going to fill in code. During coding, why bother compiling? 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?
Don't bother. Focus on the higher picture. Implement your vision. Only once you've done that, fix what the compiler is bitching about. Doing the same things along the way can sidetrack you from your higher-level view of the program.
Besides, it's a lot less annoying. 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. And then you're DONE!
The other way, you go fix your errors, and you still got mad code to write. And now you're annoyed and distracted so it won't even come out as good.
Also, sometimes I actually shock myself by writing code for an entire day and then having it compile w/o errors the first time! I really don't expect that, and it's a "wow" thing when it happens.
Some F/OSS develpers need to read this. (Score:4, Interesting)
Or, perhaps not read this...
Okay, I know that there are a lot of professional developers out there who follow some of the "rules" in the article, especially those involving ignoring warnings. I've been in professional programming environments, and I've seen this sort of thing excused all too often (personally, my code isn't done until it compiles 100% cleanly). However, for good or bad, this is typically hidden in closed-source projects -- how many compilation warnings does Microsoft get in its nightly Windows builds? I have no idea.
Unfortunately, in Open Source Software everyone gets to see where the developers ignore warnings, and IMO there isn't much excuse for it. Honestly, there are far too many Open Source projects which seem to do the things this article "advocates". And everyone gets to see it.
I remember all of the warning messages I get when building the Linux 2.4 series kernels. And I recently looked into forking the recently cancelled JPluck [sourceforge.net], but its near complete lack of code commenting makes the effort exceedingly difficult.
This has long bothered me. If you're going to release your code as Open Source so others can work with it, it should at least have some comments in it (even just simple things like the expected input.output values for procedures, functions, or methods, expected use for variables/fields, etc.), and it should generally build without a single warning [1], in order to make it easier for others to work with the code, and to ensure them that there aren't going to be any unexpected results due to ignored warnings.
Yaz.
------------
[1] Okay, I know someone is going to call me a hipocrite when they go and grab the sources for the Open Source project I administer (the jSyncManager [jsyncmanager.org]), build it, and find well over 100 warnings. I just want to preempt this by stating that these deprecation warnings occur because I've specified parts of the jSyncManager API to be deprecated to ensure developers currently using these deprecated classes move their code over to their replacements.
Re:i can't get to the article, but... (Score:5, Interesting)
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.
Re:One thing not to do (Score:3, Interesting)
Yes, in fact I do. It makes it obvious what statement a close-brace goes with, in the event the indentation is screwed up, or if it's on a separate page from the block opening. Take this class, for example [sourceforge.net].
I'll give you an example of where this is useful:
(Note: I tried typing up this post using <ECODE> with spaces and non-breaking spaces, but /. appears to strip them all out. The code below was intended to be indented, but it doesn't look like /. is going to let me. The point is even more poignant without the indentation, but as very few people code without indentation, it doesn't make for as good an example IMO. So please imagine the code below as being indented).
This code is obviously incomplete, as it specifies more open braces than close braces. I coded it, but it's up to you to fix it.
However, without knowing the algorithm, where do you add the extra close brace? Note that the first close-brace isn't at the same indentation level of anything else (due to developer typo) -- was it intended to close the if statement (and thus it's the for statement that is missing its closure), or is it the closure for the for statement, and it's the closure of the if statement that is missing?
Using my syntax, this is brutally easy to fix without going through the algorithm to discover what was intended:
Thus, it's the if statement that is missing its close block. The code should look like:
You may think that looking at the indentation might tell you where the closing brace is missing -- but just try working in a development group sometime where some developer is using 2 or 4 character tabs instead of 3 character tabs, or where they're using spaces instead of tabs (or tabs instead of spaces). Indentation is easily munged in such a case, and it can creep into source very easily. Without close-brace comments, a missing close may be very difficult to insert in the correct position.
So yes, I do add such comments to every close tag. They're quick to type, but generally I set-up my code editors to either insert them automatically, or to at least assign a macro to insert them. It makes the code easier to maintain if someone accidentally forgets to close off a block, and makes it easy to determine what statement a given close goes with if the close is on a different page from the block opening statement.
Yaz.
Pseudoephedrine (Score:1, Interesting)
That is to say, Sudafed makes you insane in the same way Lord Byron and Van Gogh were. Good for poetry and painting. Bad for coding.
What would've been more helpful (Score:5, Interesting)
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?
Re:high school (Score:5, Interesting)
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?
Re:Bad Joke (Score:3, Interesting)
If you can code all day with minimal errors and minor cleanup afterwards, great, you've found what works for you.
But compiling frequently is sound advice for the vast majority of programmers, in line with the maxim to keep your code in a shippable state at all times so that bugs don't fester. Also, you're violating another maxim that may be false in your case, but is generally true and sound advice: design first, code later. According to you, the design is happening at coding time, which is something most programmers don't do well.
A top down programmer can still be an incremental developer by stubbing out the design, thus leaving it compilable without getting distracted coding helper methods.
Don't compile now, diagram instead (Score:3, Interesting)
They recommended strict diagramming techniques like Warnier-Orr. They said use a white board with big erasures and little markers because large sections are going to be junk.
Strict and systematic Warnier-Orr diagramming can be a real discipline.
I've gone back to it in order to code very tight , time-dependent 50 nanosecond mulitple interrupt routines in assembler for microcontrollers and embedded systems. I've even placed the white board on the flatbed scanner to copy it when I've gotten that finally works in a walk-through (take the hinged cover off- it goes much easier.)
Even after doing this..and then assembling and burning the code into the chip..and having the device actually function correctly..I still get the feeling that there is something stange and magical happening that I'm not aware of.
One just sits down and tells oneself that, no, there's no magic here. You designed a complicated machine, you throughly tested a precise simulation, you built it, and it worked exactly like it supposed to because there wasn't any possiblity that it could not work like it was supposed to. It's just going through hundreds of precisely defined steps many millions of times a second...and gives the illusion of magic and sentinite intelligence.
Zero tolerance for errors (Score:4, Interesting)
In many cases, it will accomodate common errors, such as strings not being quoted, etc seemingly without complaint.
However, I recently changed my strategy to one of "zero tolerance", which entailed me reducing the error reporting threshold to 0 (all errors) as well as defining a standardized error handler callback function. I spent about a month just going thru the existing codebase to quote all the strings, etc.
However, now having done paid that price, I'm quite surprised at how often bugs that would have previously gone un-noticed pop out in clear view.
Undefined variables previously translated to equal false now stand out as a mis-spelling. Database errors previously un-noticed suddenly highlighted and shown to me. Hiccups in the code previously shown to users now archived and hidden away so that I see them instead.
It's made a HUGE difference - I'm more productive despite the appearance of having more to look out for!
I also have a generic error() function defined that's really a wrapper for the error handler - so the error logging system now in place works for language errors and logic errors alike.
It's awesome!
Re:One thing not to do (Score:3, Interesting)
I don't know, but now that you know, feel free to use it in your own projects :).
Actually, for anyone interested in how I typically write easy-to-read code, check out this PDF document [sourceforge.net] (or the HTML version [sourceforge.net]). These are the coding guidelines I wrote up (and follow) for the jSyncManager Project [jsyncmanager.org]. And yes, they're enforced (albeit not in a draconian manner -- if another developer misses something, I usually just fix it for them as opposed to nailing them to the wall :) ).
Good Open Source code needs to be readable and easy to work with IMO. If you want to attract more developers to your project, and/or want third-party developers to use your Open Source APIs, you need to make sure when they grab your code they can get working with it with an absolute minimum of hassle, and as much information as they need. The last thing you want to make them do is go through all your code with a fine-toothed comb trying to figure out what it's doing. They want to write code, not try to figure out what the existing code is doing manually.
Just as nobody likes to read a novel with no paragraph breaks/indentation, no chapter breaks, and no formatting, nobody should have to read messy code. Writing elegant looking code with useful comments takes very little time (particularily if you're a fast typer), and is always worth the extra effort, especially in an Open Source project that is close to your heart.
Speaking of which, if anyone out there is interested in developing code for an Open Source, pure Java data synchronization solution for Palm OS-based handhelds, or using such code in one of their own projects, send me an e-mail :) ).
Yaz.
Re:Advice from a fellow student (Score:5, Interesting)
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.
Develop a programming conscience (Score:5, Interesting)
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.
Re:Advice from a student (Score:5, Interesting)
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.
Re:Compiler Warnings (Score:3, Interesting)
In case you are wondering whether you are really going to break something, the error message relates to the debugger not being able to handle >255 chars.
The problem with this warning message is that it can obscure real error & warning messages.
Re:One thing not to do (Score:3, Interesting)
Unfortunately, if I'm not mistaking neither C++ or Java designer had the guts to make {} mandatory after an if,for..
C is a language with lots of pitfall, but usually they are not too difficult to catch:
1. read a document which list the pitfall.
2. when you have a problem, first a. stop 10min to free the mind, b. use debugger, printf to narrow the search, c. if it doesn't work ask for help: two are better than one. Of course it means that you two must work to solve it on the same screen, as you will probably be the one who catch the bug anyway (don't send by email the code waiting for the magic answer).
Re:"Cheat with your assignment" - ETS (Score:2, Interesting)
The good thing about it is that it is not just to catch cheats, but to educate students (particularly in the sciences) about referencing quotes etc, and to not just block copy other peoples work. Courses will either have the students submit to Turn-it-in and see the reports before they actually submit and fix it if necessary (at least one dumbass submitted his copied assignment anyway!), or markers can submit bits they think are suspicious.
plagarize code from Many.... integrate and deliver (Score:4, Interesting)
Take a program done by 3-4 people , pick the best parts, integrate
Macros from one, sortings from another, recursion from yet-another...
It's a lot less hard than writing it yourself and the result is often better than the originals .. Most of all, you actually learn from other people's mistakes .
Even after getting a job, I find that this is a much more stable way of programming newish things -"find a lot of similar things, pick the best strategies & adapt".
Btw, these days - that's called "Research" :)
Christ, people.... (Score:3, Interesting)
For most of the time you're writing code, what you have should not be compileable. Well, doesn't need to be. Since you (hopefully) are doing things top-down, at first you're going to have a lot of empty functions and comments.
How could you disagree with this statement? This is basically writing pseudo code, which is how most things should be done. It's just an OO approach. Write code that utilizes functions / class methods that dont yet exist, this lets you create your logic. Then go in and write the actual methods, which eventually will make your logic work. OO approach lets you focus on logic and fiddle with technicalities later. This is how it should be done.
Re:your code should read like a novel (Score:2, Interesting)
The main point to remember is that comments are not there to describe what code does for non-coders. It's there to describe why you did it (to aid maintenance) and to reduce the brain lag of trying to follow what amounts to a foreign language (code). Admittedly, in your example it's likely that the comment might be limited to
(That said, if I wanted a novel, I'd read Stevenson. Keep it simple)
Re:Compiler Warnings (Score:2, Interesting)
At one place, so many warning messages were being generated that when I eventually got a decent developer on board, after writing some scripts and working hard to reduce the number of messages, he got the overall compile time to go down significantly. Of course, despite my 'petty Hitler' rantings, most of the team decided not to fix the cause of these errors and the compile time started creeping up again. The arrogance of these guys was palpable, they had no intention of improving, they were, after all, the A-team (or so they said). I eventually moved on to running another team in another part of the company - who were prepared to listen (or were more afraid of me maybe) and, with other processes, productivity shot up over the course of a few months.
Re:i can't get to the article, but... (Score:3, Interesting)
This is what arrogance is. When you put down a professor, when you aren't even right.
Sometimes just a little rephrasing can make a world of difference. Instead of "Your professor obvious had no idea what he was talking about", how about: "How would the professor spot plagiarism if I did:
Re:i can't get to the article, but... (Score:3, Interesting)
I used to have prof who did the semi-creative assignment thing, and this assessment is bang on the money.
I once had to write a blackjack game in SmallTalk. The only mark I lost is because I made the dealer inherit from the player class, instead of the deck.
WTF?! The deck? HELLO! Maybe, MAYBE I could see him wanting to inherit from the game, and make him part of game play. But making him inherit from the deck means replicating draw and hit methods, and makes no sense whatsoever.
10 years later and about a billion lines of code later, I'm still pissed at that TA.
Let me expand on #1... (Score:4, Interesting)
AMEN BROTHER!!!
Better yet, take a software engineering course if it is offered. Granted, it was back in the early 90's when I was in college, but my software engineering course was what got me my first job out of college with a big company. I took my senior project with me on my interview and showed it to the first person I talked to - she said "show this to every person that interviews you today". There was ZERO code for this project. What it did have was requirements, design, budget, test plans, mock-ups, documentation outlines, etc. All the stuff that is done outside of actual coding. This is how things work in the real world. It was the most important class that I took in CS. I probably won't be coding in Pascal any time soon, but I still use the principles I learned in that Software Engineering class.
I will admit that it has been a while since I did any hardcore coding, but if you are doing any kind of project, design it first. Draw pictures. You'd be surprised how much easier it can be. I am still amazed after working in the industry after 10+ years how little software engineering education a lot of coders have. And there is a HUGE difference between a coder and a software engineer. Learn the concepts early and try to use them as much as possible. I couldn't write requirements to save my ass in college, but just the fact that I tried, and knew where they fit in the process made a huge difference. Do you know what a testing organization does and why? Where I work, we just got a set of issues out of a "lessons learned" session for our release that just went out. Many of the questions that came out of our development group were along the lines of "What does our QA group do, and why?" Some of these people have been coding for 10 years or more, and they don't understand why we have a QA group (QA and testing, which aren't the same thing)
Re:Always blame the compiler or even the computer (Score:4, Interesting)
Oh so true... I once hit such a bug (be it compiler, OS or whatever, I didn't investigate that deeply), I was compiling an OpenGL/Qt application with g++ on an IRIX platform, and something just wasn't right... One of the most basic ways of debugging being sending output at just about every line of code, here's what I saw on the console :
I lost about 2 days just trying to find that stupid "bug", but damn did it feel good that I could actually prove I was not wrong on that one.
I never knew exactly what caused it, but fixing it required to scrap 2 files (declaration and implementation of the class) and write it again.
Compiler bugs *do* exist, you just need to find a way to prove it to your boss.
Annoying bugs (Score:4, Interesting)
Only one problem: my "test" app didn't appear to be doing anything. It would run fine, with no error messages, and then exit quietly. In fact, it was producing no output at all. I began removing code, and adding printf()'s, desperately trying to get my app to say something, anything. After a couple of hours, I had stripped my "test" app down to little more than a "Hello, world" app, but it still wasn't producing any output! I would just type
dragon:/home/kombat/> gcc test.c
dragon:/home/kombat/> test
dragon:/home/kombat/>
Can anyone spot the problem? Anyone?
It turns out that "test" is actually a built-in system utility for regular expressions, used in scripts. That was the day I learned what my $PATH means, why
That day ranks as one of my most stressful, and yet most educational, at university.
Re:Most of the Prof's lecture notes are plagarized (Score:1, Interesting)
You are in an UNDERGRAD program at a RESEARCH university. You're lucky they're making pretenses at teaching you at all. They ony see you as funding their research projects. Waterloo's undergrad CS reputation is NOT that you receive a good education. It's that in one of the most massive CS programs in the country, they are barely able to scrape together 6 students that can perform on ACM (see performance of Waterloo 3 if you doubt this). It's that the students are willing to bend over and pay twice as much in tuition as any other university around. It's that they breed right-wing yes-men with absolutely no social conscience. It's that everyone there is falling over each other to fall into line and BE part of the machine. The reputation has NOTHING to do with undergraduate CS education.
Same thing happened... (Score:3, Interesting)
It happened that this time, the professor had been appointed as "Director de la Escuela", and, as an official of the Uni bureaucracy and not just "a professor", he was bound to apply the rules to the letter. So we had to (I was TA) hand out a sheet of paper during the first test and I told them "people, we're onto you. We have tens of cheaters (from a 100-people class) indentified in assignment #1, and this time, you are S.O.L. because the prof is ALSO the director, so he's bound to send you straight to the rectory, instead of marking you with the customary 1.0. In this paper, you can write your name if you admit to copying the first assignment. You'll get an 1.0 score on that, and at the end of the course you'll have to do a "live assignment" in the computer lab with the prof perched at your shoulder to prove that you learned something in this class.".
Almost all the identified cheaters turned in, and a hefty quantity of unidentified cheaters turned themselves in, and even some people turned themselves in for the #2 assignment!
Another funny one, at the final examn of a course, when I (I was TA) said "ID will be requested while the test is in course, please place your University Card in your table next to you". I had just finished saying this when I saw one of the students jump out the window (it was a 2 meter drop to the grass outside). Never figured out who he was subbing for. (Whoever he was, he failed the class, since we customarily let the students who have an average such that an 1.0 in the final will still give them a passing grade keep their average and skip the final)
Re:Advice from a fellow student (Score:1, Interesting)
I once worked with a guy who spent several days trying to solve a difficult coding problem, and wasn't getting anywhere with it. Then, he injured his back doing yard work and came to work high on painkillers. He coded up a working solution to the problem. Days later, he looked at it again and couldn't figure it out. He ended up putting in a comment, something like "I don't understand this, I was on drugs when I wrote it, but it works: DON'T MESS WITH IT."
Advice from an Employer (Score:3, Interesting)
First, because of all the concern about "cheating" I often spend weeks getting recent graduates to work on teams. The idea that sharing and collaborating on code is "OK" is so foreign to them, that I get people who won't show their work to anyone.
Next, because they have learned that the instructor "has the answer", they will come up to me and ask me how to solve the problem I asked them to work on several days ago. I work at a research institute, and if I knew the answers I wouldn't have bothered asking in the first place. I can help you figure out ways to find the answers, and suggest sites to look for examples of code that might solve similar problems to use as a guide (oh, but there's that cheating problem again), but if I have to figure out the answer for you, then why am I paying you a salary in the first place?
Finally, and I think I've seen this a few times in this discussion already, there's people skills. No program seems to bother to teach folks how to talk in front of a group, and if they do it's to tell them how to cover their Powerpoint slides. Folks, if I can read (and I wouldn't be where I was otherwise), I don't need you to recite your slides. I need you to tell me what you couldn't put on them, or to expand upon the couple bullets you have on each.
Sorry, but when I see how what people learn in school makes them start out on the wrong foot in the "real" world, it does get a little upsetting.
Re:The best advice[sic]-off topic but (Score:3, Interesting)
Nice subtle dig at manual laborers. Most carpenters, etc., run their own businesses, and do quite well, so I'm not sure where your observation comes from. You don't need IT to run a carpentry shop or install some pipes.
If you are capable of doing comp sci and becoming a plumber, you could end up running Kohler...well, I exaggerate a bit
You exaggerate a lot. Big companies no longer use people familiar with the market for management. They use managers with MBAs. The days of coming up from the mail room to the board room are gone.