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!)"
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's SIGCSE in the June 2004 issue of Inroads, the SIGCSE bulletin.
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
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.
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."
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.
Rhymes that keep their secrets will unfold behind the clouds.There upon the rainbow is the answer to a neverending story
Comment removed based on user account deletion
Get your site linked from slashdot.
but also mirrordotted :).
I spent 2 days looking for a one character bug the other day, I hate these!
.. of course when I found it I felt stupid .. and well I should have :) hey wait, maybe I should have posted this Anonymously ...
if (condition);
{
myvar = 1;
}
The block was a lot bigger than myvar = 1, and my eyes kept skipping over the ;
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
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.
Quick guide to programming languages
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
This is stuff aimed at people without a whole lot of experience programming in first year CS courses.
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 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.
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?
Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
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
bash: rtfm: command not found
Here's a VERY GOOD hint for those of you who are starting to program:
.h header file or UML diagram on paper.
THINK UML.
THINK OBJECTS.
THINK MULTI-TIER.
THINK BOTTOM-UP.
USE A NOTEBOOK.
If you start designing on paper the functions/object/interfaces/etc for your program, then start coding. As you begin to code, you'll start realizing that you'll need auxiliary functions (like an array searcher or something - most of the time lazy guys like you or me want to do everything in one function or method. Don't fall in the trap. If a series of steps is going to be very difficult, thing bottom-up and put it in a separate function or method. But before you start coding it, add it to a "to-do" list in your notebook.
That way you can keep coding your current function, by calling the not-yet written function that only exists as a declaration on paper. But the idea is there.
In the end, you'll end up with practically a completed
That helps a lot when programming (specially for low-termed memory guys like me). When you're finished designing the code, all you got to do is start typing and see which functions need to be coded, or which details . Why? Because you've already solved the problems in your code.
In one day i could design an OOP SQL wrapper (business tier) for my database project, and i only had to adjust minor details (i.e. bugs) when finished coding.
So, believe it or not, paper SAVES TIME. Trust me.
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.
http://mindprod.com/unmain.html/
My favorite:
Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
Use clear, meaningful, variable names.
I was playing with obfuscated Perl code, and got about 300 lines out. It was a script to go through my gaim logfiles, and generate stats for how much I talked to each person, how verbose they were, and so forth. It mostly just shelled various shell commands like wc, and my PIDs jumped by about 1,000 at the end (meaning that it was spawning about 1,000 processes from start-to-finish.) It wasn't well-written or anything, but it was kind of cool. And writing obfuscated, hack-job code is kind of fun. It ended up producing an HTML file.
I finally decided that it'd be cool to have the program read its own source and output it to the HTML file. It was pretty easy, and, as with anything else done just for fun that isn't too challenging, I just assigned stuff to random variable names. $hats and $fog were the most commonly-used.
I simply opened the source as $hats, and opened $fog for write, and then wrote $fog to $hats. No errors or anything!
The output file was blank. So I went back to edit the source code. Umm, it's blank too. And, of course, I was just messing around, so I had no backups.
Then one day it suddenly occured to me: I probably screwed up the variable names for the input and output, reading the blank output file and writing it over the program's source code.
So, remember, kids, use meaningful variable names. Using $hats instead of $fog could be the end of your program.
________________________________________________
suwain_2
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.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
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.
I don't know, I've had some lengthy coding sessions inspired by alcohol. Usually wake up in the morning, stare at the code, realize it works, wonder how that is even possible, rename some stuff for clarity and redo the comments (drunk comments can be amusing, but not the kind of stuff you want to turn in).
That's a pretty pretensions comment. Many people don't have access, either through finance or friends, etc to get interested in CS things like programming at an early age. Granted, while in it you ought to be interested and enthused about, else you should probably be doing something else that does. But, that's the whole point of college; to discover what interests you if you haven't already and experiment with things. Many of these "majority of CS students" are taking a Java class to see if they enjoy it, thus it is the first time they have touched a command line. Many of them will find it's not for them and drop. Some will stick around for some reason.
Besides, if you knew anything of CS you would know Java and command lines have as much to do with it as telescopes do to astronomy, to paraphrase Dijkstra. In fact, I had professors who could care less about Java or command lines because their interests are in theoretical computer science, algorithms, math, theory, etc.
Perhaps you are in the wrong major. Maybe you belong in a traade school for programming?
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
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?
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).
As a TA, I've often felt that students who ignore errors should should get points marked off for reasons they can't understand. After all, if they're going to make me do more work because they can't be bothered with simple comprehension, shouldn't I give them the same?
Old comments:
-1 Missing ";"
-1 Changed case of variable; not recognized by the compiler.
-2 Need a closing bracket "}"
-3 Trying to write from an unassigned pointer.
New comments:
-1 Missing weasels exception error.
-1 I just felt like taking a point off here.
-2 For great justice
-3 Disco Inferno at this point in the code.
I never got up enough nerve to actually do it. Plus, I don't really want to risk any students suing the school.
Mod me down and I will become more powerful than you can possibly imagine!
I'm a CIS student, about ready to graduate. I'd already been programming for several years before I started school (and never allowed my school to interfere with my education), and I've spent a lot of time helping my fellow students, and here is some advice based on what i've seen.
Learn to love whitespaces. I don't know how many times i've seen people try to cram their code down as small as possible by removing every possible whitespace. 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.
DO NOT comment every line. Seriously. Comments are a good thing, but when you comment every single cin and cout, every single bracee and function call, then it can make it a lot harder to find what you are looking for. A good rule of thumb I tell people is to comment every line you have to think about for more than 30 seconds, comment every function and class, and comment every block of code that you have to spend more than 2 minutes pondering over.
Learn to use your editor. Whatever IDE or editor you decide to use, learn to use it well. Learn to use the debugger specifically, but also get used to the environment. I don't know how many people I've helped who's problem was not with their code, but with an improperly configured IDE.
READ Error messages. This sounds obvious, but I swear people don't read them, or don't think about what they could mean. I think a lot of this comes from programmign classes that teach people to memorize syntax, without giving them an understanding of what's going on at the machine level, or what the compiler is actually doing.
If you miracously fix something, understand why. Students seem like they can not resist randomly moving code around, and sometimes this does fix things. If this happens, take some time to understand what you moved and why it might have fixed the problem
Take Breaks. This one applies to everyone. I've seen a lot of good programmers go crazy over simple problems simply because they are too stressed out to think clearly. If you start to feel stressed, tired, or your mind starts to wander, then step away from the computer, have a cigarette or a cup of coffee, take a walk, and get your mind away from the problem for a bit. Even if you have a deadline, a 15 minute break can often save an hour of frustration at the computer.
Famous Last Words: "hmm...wikipedia says it's edible"
Yeah. Thats what the college of business is there for.
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. 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. 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). 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. 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. 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.
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.
Rudolf Diesel, the inventor of the engine, graduated from University and then went and trained as a skilled mechanic. Isaac Newton could use a lathe by the time he got to Cambridge. And Alan Turing could machine his own relays. Apart from the career options, acquiring both academic and practical skills makes you a more rounded person, and thus more employable generally.
Panurge has posted for the last time. Thanks for the positive moderations.
As far as I can tell, especially with people from an academic background (PhDs! argh!), this guide is way too advanced -- something like this might be more useful to start with:
-- Do not keep the entire project in
-- Use source control
-- Run the code before delivering it
-- NOT JUST ON YOUR OWN WORKSTATION, BUDDY!
Then, from that one could work up to 'try and ensure it is possible to install the software by some deterministic process', and only then would it be worth actually starting with actual code...
Well, they learn eventually I guess, in most cases.
Whence? Hence. Whither? Thither.
If you don't compile every few minutes, you're running your tests every few minutes.
If you're not running your tests, how do you know your code works?
If you're not compiling and testing, how are you figuring out what the code you're writing is meant to be doing?
I used to code for a day without compiling, then sit in amazement as my code compiled first time. Luckily computers are faster now and it doesn't take the better part of an hour to recompile - it takes a few seconds - long enough to pick up my coffee, take a sip and think about the next test I'm going to write.
Now that I compile more often, and run tests several times an hour, my code is immensely higher quality, I write it faster, I spend far less time sorting out compile errors and random bugs and I can safely walk away from the computer with just a couple of minutes notice without worrying about leaving a nasty mess that it'll take me a couple of hours to understand, finish and compile the next day.
In other words, thanks for the advice, I'll follow it if I want to return to where I was a decade ago.
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!!!!!
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
The great irony, of course, is that at some time in your programming career you probably will come across a genuine compiler bug, and no-one will believe you...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.