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!)"
Slashdotted. Already. Here is article text. (Score:4, Informative)
Computer programming students invariably fall into more than one bad habit. It can be extremely difficult to eradicate them (and many lecturers and professional programmers keep succumbing to them time and again). I wrote this when, in the days leading up to an assignment deadline, I saw these things happening so often that I couldnt help but recall my classmates and I a decade earlier doing exactly the same things as my students.
This article is an attempt to show these irrational attitudes in an ironical way, intending to make our students aware of bad habits without admonishing them.
NOTE: This text was published by ACM [acm.org]'s SIGCSE [sigcse.org] in the June 2004 issue of Inroads, the SIGCSE bulletin [sigcse.org].
All about programming, in the strictest sense of the word Ignore messages
Compilers, operating systems, etc. generate error messages designed only to be read by their creators (maybe to justify their salaries). Precious time is wasted reading these messages; time that could be better spent writing code, of course! Error messages make us less productive. Dont fall into the trap. Ignore them.
As for warning messages, ignoring them makes you feel like a professional programmer whos not scared of computers. What better way of showing ones experience as a programmer than delivering a program that generates dozens, no, hundreds of warning messages when it compiles without its author feeling the slightest bit concerned? Everyone can see that youre an experienced, laid-back programmer who is too busy to waste time on drivel.
Dont stop to think
Lets not kid ourselves here. What are we building? A program. What is the only thing that really matters in a program? Code. What really works? Code. Why use outdated resources like pencils, pens or paper? You are a paid-up member of the SMS generation; you dont make a fool of yourself writing time-consuming syllables, right? Then, stop messing around thinking about nothing when theres so much code to write.
You should never stop coding. We all know that error messages are an unacceptable interruption, a pointless obstacle as we go about our work. So what do you do if you get a compiler error message? As you should know by now, reading and understanding it is just not an option.
You can try making some random change to the source code. You never know, you might pull the wool over the compilers eyes. But if this doesnt work, dont waste any more time. NO, dont be tempted by trying to read the message or understanding it. Just keep churning out code - thats the only way of finishing off this horrendous assignment. Youll get to sort the error out later on. And as we all know, errors tend to disappear by themselves if theyre ignored. At the end of the day youll compile, youll
Slashdotted ... (Score:5, Informative)
high school (Score:5, Informative)
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
"Cheat with your assignment" - ETS (Score:2, Informative)
You see, they have a kind of program, which they use to compare all the assignement that are handed in. Not only does it compare it with everyone in your class, it compares your code with the code of all the students from the last four year.
Try and copy anything now... good luck!
This is how you run a school
Any other school has a similar setup?
For the curious (Score:1, Informative)
http://www.nedstatbasic.net/s?tab=1&link=1&id=311
Re:One thing not to do (Score:2, Informative)
My advice for young programmers (Score:5, Informative)
1. Get a software engineering book, and study the concepts of software design. Even if you're just doing some small little "print a schedule" type assignment, thinking about how you would design a bigger project will help you.
2. Get a good book on algorithms. I'm partial to Introduction to Algorithms [mit.edu] but there's lot's of good choices. So when your prof assigns you to do a project using a circular linked list, think about what might be better. But resist the temptation to smart off and try to do better, and complete the assignment the way (s)he says to. Perhaps ask the instructor what they wanted you to learn from the assignment if you feel that the algorithm is particularly inappropriate.
Don't just read the alogrithms, write them from scratch as well until you understand them. Be aware that some algorithms are completely different if you're using a language that starts arrays at [0] than at [1].
3. Take good technical writing courses. Many CS majors can't write well. Being able to clearly communicate is a great skill to have, regardless of what your position is, and it's a good way to differentiate yourself from the masses. Being able to write in American style English is something that many Indian/Chinese/etc. programmers won't be able to offer.
Take business courses, etc. Broaden your horizons in profitable ways.
4. Network, network, network. Not LANs and wireless, but people. They are the ones that will get you jobs in the future, who will provide you with sales leads and consulting. Mingle with people in the field. Mingle with business majors. Start it now, not in your senior year. Today's seniors may be the one's e-mailing you about a great position three years from now when you're about to graduate. I've seen very smart, very talented people sit for months without a job because they didn't start this process early.
5. Get out and enjoy yourself. You have the rest of your life for LAN parties and coding sessions. If you're in college and not working, you are likely never to have the same freedom that you do now. (Excepting unemployment...) Get out, go hiking, meet people of the appropriate sex, see concerts, learn to cook. Virtually no one dies wishing they'd spent more time in front of an LCD screen.
Wait until the PENultimate minute. (Score:3, Informative)
Re:Finer points of Spanish-English translation (Score:2, Informative)
Real Programmers (Score:4, Informative)
Re:Most of the Prof's lecture notes are plagarized (Score:5, Informative)
It's one thing to use somebody else's lecture notes. But this guy clearly didn't even read them before coming to class. You'd ask him a question and he'd just say "Uh, I don't know, these aren't my notes." For crying out loud! And I was paying $700 or so for that course! The prof was Mavaddat [uwaterloo.ca] in case you're curious. If you're ever scheduled to have a course with him, SWITCH as fast as you freaking can! You're better off Googling for stuff and reading other people's PowerPoint slides by yourself.
Re:Cheating. (Score:2, Informative)
Re:Compiler Warnings (Score:2, Informative)
Re:One thing not to do (Score:2, Informative)
1) If you ever end up with mismatched braces you can do this:
egrep '{|}' program.c
to get an overview of the braces to more easily find the mismatch (no "if" or "for" stuff to clutter it). This is probably less useful with modern editors that do brace matching.
2) Personally, I think it makes it easier to skim the code. For example, look at:
if (condition)
x = y;
and then look at:
if (condition)
{
x = y;
a = b;
}
When reading either of the above, I think "If I care about what happens when the condition is satisfied, indent one level and read, otherwise skip to the next line with the same level of indentation." If you do braces the other way, when you skip forward to the next line with the same level of indentation you may or may not run into a "}", which seems out of place to me (i.e. the braces are part of the statement to be executed, not part of the "if"). Just my opinion though. Do whatever makes you happy.
Re:One thing not to do (Score:1, Informative)
So the compiler catches me, even if I do:
Re:What would've been more helpful (Score:3, Informative)
Worst programming bug ever (Score:1, Informative)
Another time (5 hours of work buried in run-time assembly debug output) I found out a bug was placed because I had the two controllers set to the same input. (I.e. they'd both hit select at the same time. Couldn't start mario, etc.)
Some mistakes are just unavoidable.
Re:What would've been more helpful (Score:2, Informative)
Here's something I've learned over the years:
- Start compilation. Get a gigantic mass of wierd compiler errors.
- Fix the first one and the first one only
- Restart compilation. Goto top of this list unless there are no more errors.
Seriously, most errors are caused by the parser being off track after the first error. Don't sift through your entire error list trying to find the cause for each one. In most cases, it will be the first error.
And for those who say "compilation takes far too long!": that's what make is for. And distcc.
Always blame the compiler or even the computer (Score:4, Informative)
Say things like: Ho! That computer in the computer lab is so crippled, I am sure that my code would run fine on a fresh Windows install.
Re:What would've been more helpful (Score:4, Informative)
E.g.could be rewrittenor simply(I just finished reading "C Traps and Pitfalls". It contained many amusing errors, but it was very sparse on defensive coding advice.
I wouldn't recommend the book. Read "Code Complete" instead, that's a gem!)
Re:The best advise.... (Score:2, Informative)
What a joke, be a kitcken cabinet installer, get mega bucks, if you want to be creative, do it at home, why spend 9hrs/day being a slave and getting fat.
How Pertinent (Score:2, Informative)
One thing I've noticed, well at least the university I went to (Arizona State - ok I've heard all the jibes), is that there is not as much emphasis on coding style as there is in just getting the assignment done. This article is essentially talking about the bad habits that students develop, and mostly this is due to insufficient emphasis on good coding style. I had been writing code for almost five or six years before I started college, so it was second nature to me. However, some of the people I met hadn't written a single line of code in their life. They were genuinely interested in CS (but there were some who were in it just because "CS people make a lot of money"). Most first year programming classes that I know of, just give you to tools to the language without telling you how to use it well. It's like you know English, but does that mean you can write a really good Story, or an Essay that is grammatically correct all the way? No, it takes training - and that is what I think some of these first year classes fail to provide. Sure, later on in your CS/CSE degree you may come across a professor/class that emphasizes good coding style, but by then some of these bad habits may be so ingrained. Like for example, I have seen C programs without ANY indentation. How terrible is that? Whitespace is awesome - use it liberally.
I was lucky enough to have a good professor my first year in college. I rememember that he eschewed the use of "goto's" (ok I have heard enough debates on this). His reason was that many students simply did not know how to use them right, leading to the inevitable spaghetti code. Also since we were using Java, it wasn't possible anyway.
Anyway, my point on Coding Style is that first year classes should emphasize that point so that students can learn to write programs that are easy to debug and document.
Proper Specs, Writing Algorithms, Documentation, and Knowing what your code does
I can't even begin to say how important this is. The major problems (some) Engineers have is that they write terrible comments, or none at all, or cryptic ones. I have come back to code that I wrote months ago and I have had a hard time deciphering what it is that I wrote. Documentation may seem like a pain, but in reality it makes the maintenance of your code more effective. Also, in an industry setting if someone else has to come along and look at your code, it makes it easier for them. How many times have you had to go over someone else's code and found no comments, or terribly obvious ones like:
i++;
I took an assembly language class in my sophomore year, and another one in my junior year - they were required courses. The prof in the first class was a former student of the prof in the second class, so they had the exact same methods. They had three main emphasis points:
1) Algorithm
2) Program Size
3) Documentation
Both these professors gave our excellent specs on our assignment (something more professors should do). They were extremely detailed and they exactly told us what was expected. In addition to this, they graded on program size and execution time. This prompted (most of) us to create efficient algorithms. I have to say that usually I'd just jump into the code and start coding, with a hazy algorithm in my mind. This time, I really had to sit down and come up with an algorithm. I discovered that it made my coding process much easier. It's better looking at your algorithm in paper and the comparing it to your code than doing it in your head. Their final emphasis was on documentation. 20% of the points for a lab assignment was for documentation. We had to provide an introduction/user's guide for the program. By reading it, any person should know WHAT the program does. Secondly, we had to provide an internal overview. This is esesentially the description of the algorithm that we use. Any person, by reading the internal overview, should have a good idea o
Re:Always blame the compiler or even the computer (Score:2, Informative)
Did it ever occur to you, at this point, to:
I find that the believability of compiler bug reports goes way up if you actually look at the compiler's output and can say "See! There it is! It's wrong!" And once you do that, you should point it out to the vendor so they fix it. (I say all this as someone who actually has spent signficant time filing compiler bug reports of my own.)
Finding a bug and just kluging around it might be a nice short term expedient, but it doesn't increase the long-term quality of the tools.
--Joe