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.
Do not, under any circumstances, code under the influence of alcohol.
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.
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
Dont compile on a regular basis, dont tiptoe your way forward. Youre a professional and professionals take giant steps. Write thousands of lines of code first and leave the compiling for later; it will be far more entertaining and worthwhile to look for compiling errors.
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.
Ecce Europa - Web Design for Business
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, 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), 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.
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.
I've been coding for some time very extensively using PHP. It, along with GTK is a good, high-level language that lets me get lots done, very quickly.
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!
I have no problem with your religion until you decide it's reason to deprive others of 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.
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" :)
Quidquid latine dictum sit, altum videtur
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)
My beliefs do not require that you agree with them.
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.
After 3 days without programming, life becomes meaningless
- The Tao of Programming
Hahah, I know exactly how you feel. I wasted 2 hours on what should have been an extremely simple C assignment in university one day. Back then, we did our C/C++ assignments on a shared Solaris server, working on dumb terminals in a lab. I was getting some kind of strange exception with my C macros. So, I created a "test" program and copied over the guts of the logic of my app, so I could re-add the functionality piece-by-piece until my test app broke. This would allow me to isolate the code that was causing the problem.
/usr/bin is at the beginning of the $PATH, and how one can use ./test to make sure that one is actually running the program in the current directory, rather than the system utility with the same name!
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.
Like woodworking? Build your own picture frames.