Forgot your password?
typodupeerror
Education Programming IT Technology

Programming Assignment Guide For CS Students 761

Posted by timothy
from the don't-do-this dept.
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!)"
This discussion has been archived. No new comments can be posted.

Programming Assignment Guide For CS Students

Comments Filter:
  • How NOT to go about a programming assignment

    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

    • And what about that bloke in Operation Swordfish? Would he have cracked the Pentagon password if one of Travoltas hitmen hadnt been pointing a pistol at his head while another Travolta hitwoman was trying to distract him? - I think it should be mandatory for every CS class to have their own hitmen who would point guns at the students' heads while some hitwomen would try to distruct them. Then everyone would be like those hackers in movies, hacking away those 128bit encryption algorythms in just under 60 se
    • by Simonetta (207550) on Wednesday October 20, 2004 @01:03AM (#10572734)
      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.

      • by Ed Avis (5917) <ed@membled.com> on Wednesday October 20, 2004 @05:35AM (#10573710) Homepage
        Yes, your code should read like a novel or at least like a well-written newspaper article or technical paper.

        However, it should read like that _without_ comments! If you need to add long comments to make the code clear then fix the code first. In general, it is better to say something in code than in comments, for example 'const int x' is better than 'int x' plus a comment saying 'x will not be changed'. Well-chosen variable and subroutine names are also important. Finally arrange things in a sensible order: when writing you can either lay out the simple concepts first and use them to build up more complex things (like writing a mathematical proof) or you can start with a broad overview and then fill in the details. Either of these two styles may be appropriate depending on what your program does.

        Remember: comment _how_ and _why_, not _what_.
        • by Erik Hollensbe (808) on Wednesday October 20, 2004 @07:51AM (#10574027) Homepage
          Your assertion is too absolute.

          Sometimes, especially in the real world, commenting what is just as important.

          In the real world, a comment like this: // writing pseudo-pascal sucks

          Is common - in class, it got me a D when the rest of the code was well commented and the code well-formed. It was in direct protest to the assignment I was given. In reality, my fellow coders would probably agree with me.

          However, that's not my point. I've written blocks of code that were hard for me to understand after I put them away for a month, not because of poorly named variables or functions, but because they made use of side-effects. A great example of this is optimization. Optimization in many cases has the deliberate effect of making your code harder to read for a number of reasons.

          Duff's device is a great example of an optimization that, without explanation of what, you certainly won't get how or why.

          Well chosen names only go so far. I've worked on code that used sentences for the names of some of it's DB calls. And one could say that OCI has well-chosen names, but only the bravest database programmers tackle that mess.
    • by ArcticCelt (660351) on Wednesday October 20, 2004 @04:17AM (#10573516)
      He forgot to mention that you should always blame the compiler or even the computer for any bug.

      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.

      • by Anonymous Brave Guy (457657) on Wednesday October 20, 2004 @08:06AM (#10574089)

        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...

        • by Phisbut (761268) on Wednesday October 20, 2004 @09:06AM (#10574429)
          at some time in your programming career you probably will come across a genuine compiler bug, and no-one will believe you

          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 :

          SomeClass::SomeClass() // default constructor
          {
          cerr << "Beginning constructor\n" ;\
          myAttribute = 5 ; // myAttribute is an int
          cerr << "myAttribute = " << myAttribute << endl ;
          // [...] rest of the constructor
          }

          ... and then, I got an output of "myAttribute = 0"...

          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.

  • Bad Idea (Score:5, Insightful)

    by Anonymous Coward on Wednesday October 20, 2004 @12:23AM (#10572467)
    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.
    • Re:Bad Idea (Score:5, Insightful)

      by xs650 (741277) on Wednesday October 20, 2004 @12:50AM (#10572642)
      No need to repeat others mistakes, learn from theirs then go on to make you own unique mistakes.

      A smart man learns from his mistakes
      A wise man learns from others mistakes.
    • Re:Bad Idea (Score:5, Insightful)

      by Concerned Onlooker (473481) on Wednesday October 20, 2004 @01:19AM (#10572831) Homepage Journal
      It's not about not making mistakes, it's about bad habits being formed. Of course we're going to make mistakes starting out, but this is about avoiding the mistake of forming harmful habits.

      We cement our knowledge by doing hands on programming and working out problems, but we have to learn from someone/something in the first place, otherwise we'd be always reinventing the whole process.

  • by ansleybean (618941) on Wednesday October 20, 2004 @12:25AM (#10572477) Homepage
    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."
    • by Cryofan (194126) <cryofan.yahoo@com> on Wednesday October 20, 2004 @12:31AM (#10572521) Homepage Journal
      I found that if you googled most of the CS lecture notes, most of them were plagiarized from some other school....
    • by gcaseye6677 (694805) on Wednesday October 20, 2004 @12:34AM (#10572542)
      This really depends on how well the professor defines the assignment. If every aspect of the programming assignment is spec'd out to the point that there would only be one correct answer, it would be easy to get away with cheating since all of the good submissions would look the same. 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. If professors really want to stop cheating, they need to take the initiative to assign work that requires creativity on the part of the students as opposed to submitting code that could be a cut and paste of textbook examples. Having had both kinds of professors in school, I saw first hand what kind of work students provide in each environment.
      • by Christopher Thomas (11717) on Wednesday October 20, 2004 @01:29AM (#10572889)
        This really depends on how well the professor defines the assignment. If every aspect of the programming assignment is spec'd out to the point that there would only be one correct answer, it would be easy to get away with cheating since all of the good submissions would look the same.

        There are a few things that you can still look for, here:
        • Nearly identical style.
          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.

        • Nearly identical discussion.
          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.

        • Identical mistakes.
          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...

        • Handed in on top of each other.
          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.
    • by Gopal.V (532678) on Wednesday October 20, 2004 @04:15AM (#10573510) Homepage Journal
      Like we used to do in college :)

      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" :)

    • True story (Score:4, Funny)

      by markov_chain (202465) on Wednesday October 20, 2004 @09:38AM (#10574670) Homepage
      In an algorithms class (about 60 students) at my school there was a big challenging programming assignment mid-semester. The prof and the TAs caught a couple of people cheating, like 3 or so. Now this was a cool prof who didn't want to get kids kicked out of school so he decided to give them a second chance. On the final, there was a question worth 1 point stating "We found some cheating last month. If you did it, confess and you only fail the course. If you don't confess, we'll get you kicked out. Did you cheat? (1)"

      Half the class confessed.

  • by nebaz (453974) on Wednesday October 20, 2004 @12:27AM (#10572491)
    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.
    • by nebaz (453974) on Wednesday October 20, 2004 @12:33AM (#10572530)
      Oh, and also, always use labeled line numbers in multipes of 10. That way, if you need to insert lines later in the middle, you have some line numbers to use later.
    • Declaring local variables will just add unnecessary typing. Just put it all in globals for maximum code reuse.

      And classes, they don't add anything you can't get with functions. All they do is restrict you.

      But why even use functions? All that happens is you try to make one piece of code serve multiple uses when you'll be better off tailoring the code to each instance where it's needed.
    • Why use boring old For and While loops when recursion is so much more fun? Next time you start typing 'for (i=0;'... ^H^H^H^H a few times and do it with a recursive function call instead. It's a lot more exciting, and just think of the fun somebody else is going to have in a few years when they try to update your code!

      That'll teach those dirty corporate &%*@!s. Lay me off will you? I hope the Indians like puzzles!

      Besides, nothing's cooler than that which has the rule "Just have faith it [recursion] wi
  • by cloudkj (685320) on Wednesday October 20, 2004 @12:27AM (#10572493)
    Do not, under any circumstances, code under the influence of alcohol.

    • by jschottm (317343) on Wednesday October 20, 2004 @12:33AM (#10572538)
      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.
    • by YouHaveSnail (202852) on Wednesday October 20, 2004 @12:36AM (#10572559)
      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.
    • by ErichTheWebGuy (745925) on Wednesday October 20, 2004 @01:00AM (#10572717) Homepage
      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
    • by Mmmrky (607987) on Wednesday October 20, 2004 @01:17AM (#10572812)
      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).
    • by ZorbaTHut (126196) on Wednesday October 20, 2004 @02:52AM (#10573197) Homepage
      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.
  • by Rufus211 (221883) <rufus-slashdot AT hackish DOT org> on Wednesday October 20, 2004 @12:27AM (#10572495) Homepage
    Get your site linked from slashdot.
  • Slashdotted ... (Score:5, Informative)

    by ggvaidya (747058) on Wednesday October 20, 2004 @12:27AM (#10572497) Homepage Journal
    but also mirrordotted [mirrordot.org] :).
  • by esac17 (201752) on Wednesday October 20, 2004 @12:29AM (#10572507)
    I spent 2 days looking for a one character bug the other day, I hate these!

    if (condition);
    {
    myvar = 1;
    }

    The block was a lot bigger than myvar = 1, and my eyes kept skipping over the ; .. of course when I found it I felt stupid .. and well I should have :) hey wait, maybe I should have posted this Anonymously ...
    • by LeiGong (621856) on Wednesday October 20, 2004 @12:38AM (#10572570) Homepage
      Maybe you should have used a debugger and stepped through the code. A good programmer knows when he's defeated and when he has to step through the code. Maybe that should be one of the rules. Use the debugger, it's there for a reason. Don't assume you're wiz and will fix the problem by just reading the code line by line. If you're a neophyte, chances are you're going to mess up existing working code.
    • by Yaztromo (655250) <<moc.cam> <ta> <omortzay>> on Wednesday October 20, 2004 @12:44AM (#10572608) Homepage Journal

      Oh I just know I'm going to open up a huge bag of worms with this one, but this is why I vastly this sort of syntax:

      if (condition) {
      myvar = 1;
      } // end-if

      It makes it easier to identify which statement the block is intended to begin with, and makes it easier to spot if there are un-intended characters between the condition and the block-opening (besides reducing vertical space wastage).

      Yaz.

      • by cheekyboy (598084) on Wednesday October 20, 2004 @04:43AM (#10573596) Homepage Journal
        I used to do that in the previous millenium, but its crap, you cant just // comment out the condition and run the code as is, you have to move the { later.
        Besides it looks ugly the way you have it.
    • by Taco Cowboy (5327) on Wednesday October 20, 2004 @01:58AM (#10573010) Journal


      Many a programmer will give you tons of insights on what not to do, but everyone and their great-granduncle seem to forget that the use of FONTS is of great important on eye-balling bugs.

      Your example of the ";" could have easily caught if you use a font that makes stuffs like ";" "." "," "`" and so on FAT and OBVIOUS.

      And on more thing - ENLARGE the size of the font to a comfortable degree, instead of squiming your eyes to look for ridiculously faint dot.

      For programmers, although our brains are important, it's our eyes that have often been over-strained.

    • by renoX (11677)
      Well, unfortunately this is a pretty common mistake, blame it on K&R to introduce such an easy pitfall.

      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 be
    • Annoying bugs (Score:4, Interesting)

      by Kombat (93720) <kombat@kombat.org> on Wednesday October 20, 2004 @09:23AM (#10574560) Homepage
      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.

      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 /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!

      That day ranks as one of my most stressful, and yet most educational, at university.
  • high school (Score:5, Informative)

    by Anonymous Coward on Wednesday October 20, 2004 @12:30AM (#10572510)
    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
    • Re:high school (Score:5, Interesting)

      by roman_mir (125474) on Wednesday October 20, 2004 @01:50AM (#10572965) Homepage Journal
      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?

  • by Fluidic Binary (554336) on Wednesday October 20, 2004 @12:31AM (#10572514) Homepage
    I was hoping for something educational and instead I found a collection of jokes that I don't find very amusing. I mean sure I'm smirking, but shouldn't something that took that many bytes at least make me chuckle?
    • I was hoping for something educational and instead I found a collection of jokes that I don't find very amusing.

      This is intended to be educational. Rather, it is intended (at least in part) to be yet another thing to point first-year (and later!) students to, in the hopes that they decide to absorb it for a change. Give the advice in enough forms, and maybe one of them will take.

      That, and it reads a bit like it was written to vent frustration. I know I can sympathize with a lot of what was expressed ther
  • by beacher (82033) on Wednesday October 20, 2004 @12:31AM (#10572522) Homepage
    Anyone want to see it? If you can get the page to load, click on the chart icon which leads you here [nedstatbasic.net]...
    12:32 EST 20 octubre 2004 1223... Took 300 hits since 2 minutes ago.. Neat
  • The best advise.... (Score:5, Interesting)

    by cjjjer (530715) <<cjjjer> <at> <hotmail.com>> on Wednesday October 20, 2004 @12:50AM (#10572640)
    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
    • by panurge (573432) on Wednesday October 20, 2004 @03:02AM (#10573242)
      Yes, take up a skilled trade, or preferably two, one of which is IT related. Most plumbers, electricians and carpenters are not capable of running a business because they lack the organisational and IT skills that are needed nowadays. If you are capable of doing comp sci and becoming a plumber, you could end up running Kohler...well, I exaggerate a bit but I think the point is valid.

      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.

  • by jschottm (317343) on Wednesday October 20, 2004 @12:50AM (#10572641)
    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 [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.
    • by gosand (234100) on Wednesday October 20, 2004 @09:04AM (#10574412)
      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.

      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)

  • by emarkp (67813) <slashdot@r[ ]q.com ['oad' in gap]> on Wednesday October 20, 2004 @12:50AM (#10572648) Journal
    Nearly every assignment I received was modified between assignment and due date when earlybirds ran into difficult or unsolvable snags. These were the only classes I found in which waiting to start was really did help.
  • Real Programmers (Score:4, Informative)

    by gustgr (695173) <rondinaNO@SPAMgmail.com> on Wednesday October 20, 2004 @12:53AM (#10572667) Homepage
    Thanks, but I have my very definitive programming guide [welho.com] already. Mwaahahha
  • by Indy Media Watch (823624) on Wednesday October 20, 2004 @12:53AM (#10572669) Homepage
    The proliferation of 'happy-clicky' programming environments has led to sloppy inefficent coders who have limited understanding of how to write clean code.

    The result? Word Processors which ship on 5 CDs and do little more than similar products from a decade ago.

    More RAM, bigger hard-drives, faster processors, and for what? A new version of software that doesn't do a whole lot more to justify the upgrade?

    Meanwhile, a lack of formal coding education also means we still see buffer overflows and other security nasties that should never have happened in the first place.

    The good news, is devices like the Palm have forced people to operate in the limited hardware/memory environments of years ago. The result, clean efficient code in just a few kilobytes.

    Time to go back to school people...

    • Every /. story about programming seems to bring this tired meme out of the woodwork yet again. There never was a time when people wrote apps that do almost as much as current software in a tiny fraction of the disk and memory space.

      What people forget is that old games and GUIs only had 1/50th of the pixels (and 2 of the 16 million colors) a modern display has to contend with, that their old 100KB "word processor" was really a stripped-down text editor with 3 fonts and no spelling check, DOS could fit on o
  • Bad Joke (Score:3, Interesting)

    by cookiepus (154655) on Wednesday October 20, 2004 @12:59AM (#10572711) Homepage
    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.

    • Re:Bad Joke (Score:5, Insightful)

      by Martian_Bob (695825) on Wednesday October 20, 2004 @01:12AM (#10572787)
      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.
    • Re:Bad Joke (Score:3, Interesting)

      by jjohnson (62583)
      You're an excellent example of a freak who does a particular thing very well, and so convinces others to do it not nearly as well as you can.

      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 i
    • My profs insisted that we should diagram the process algorythym before coding.

      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 p
    • Re:Bad Joke (Score:5, Insightful)

      by aussie_a (778472) on Wednesday October 20, 2004 @02:41AM (#10573170) Journal
      Why am I not seeing +4 Funny? Oh well, time to argue your ridiculous post point by point (I've got 2 assignments due tomorrow, I'm using this time as a break from coding, dear god I'm a nerd).

      Compiling frequently is not good because you should not be thinking about such details as syntax and var name spelling until the very end.
      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.
      For most of the time you're writing code, what you have should not be compileable.
      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.
      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?
      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).
      Focus on the higher picture. Implement your vision.
      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.
      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.
      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.
      Also, sometimes I actually shock myself by writing code for an entire day and then having it compile w/o errors the first time!
      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.
    • Re:Bad Joke (Score:5, Insightful)

      by Cederic (9623) on Wednesday October 20, 2004 @03:22AM (#10573302) Journal

      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.
  • by Spy der Mann (805235) <spydermann.slash ... m ['ail' in gap]> on Wednesday October 20, 2004 @01:03AM (#10572733) Homepage Journal
    Here's a VERY GOOD hint for those of you who are starting to program:

    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 .h header file or UML diagram on paper.

    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.
    • by roman_mir (125474) on Wednesday October 20, 2004 @02:02AM (#10573023) Homepage Journal
      Here is a better hint:

      get your hands on an old 386, a debugger and an assembler. Figure out your way through building simple tools for cutting and concatenating files, fixing file system, writing simple menu driven apps. Attempt a calculator, a text editor (try this one in assembler, I am dead serious,) try a few games. A labyrinth game, an FPS, maybe some sort of a space ship game.

      Write all this stuff first the way you like, don't worry about style and comments. Stick to it, work on your own spread sheet, graphics library, TSR programs (ah, good old DOS.)

      Once you are comfortable (this will take at least 6 months, maybe more,) go back and revisit your own code. Now you will learn that all your good old code will not stay in your own head forever, you will learn to appreciate structure and comments.

      Noone can make you do it unless you realize it yourself - structure is important.

      From procedural programming, move into something more esoteric - try to write an adventure game in Prolog so that you will have to learn more and more about that way of programming. You will spend a minimum of 3 days learning and writing that shit. You know - you are in a room, now the lights are off, you have this in your hands... what are your actions.... etc.

      Now you can go into OO. OO is not a natural way of writing code or even thinking about software. You will make common mistakes, like using OO as a procedural language. But if you are still interested at that point, you will continue learning and you will understand the difference between OO and procedural or imperative. Don't use OO for everything, please, network is not object oriented. Neither is HTML. Whatever.

      But start with a 386, on that platform you will really have an opportunity to learn and control the hardware. If you will like that you will know that programming is for you.

  • by Yaztromo (655250) <<moc.cam> <ta> <omortzay>> on Wednesday October 20, 2004 @01:05AM (#10572742) Homepage Journal

    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.

  • by nwbvt (768631) on Wednesday October 20, 2004 @01:06AM (#10572749)
    This has probably been posted on /. before (in fact I probably origionally found it here), but I can't resist posting this site:

    http://mindprod.com/unmain.html/ [mindprod.com]

    My favorite:

    (On naming) # Bedazzling Names : Choose variable names with irrelevant emotional connotation. e.g.:

    marypoppins = ( superman + starship ) / god;

    This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about.
  • Another Tip (Score:5, Funny)

    by suwain_2 (260792) on Wednesday October 20, 2004 @01:10AM (#10572772) Journal
    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 [sf.net] 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.
  • by nate nice (672391) on Wednesday October 20, 2004 @01:11AM (#10572777) Journal
    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.
  • My favourite (Score:4, Insightful)

    by smallpaul (65919) <paul&prescod,net> on Wednesday October 20, 2004 @01:28AM (#10572883)
    When I was in university I would spend 90% of the time putting together a "framework" to solve the actual problem (much more general and thus useful for future classe). Then I would spend 7% of the time debugging it. Then I would spend the remaining 3% desperately trying to figure out how to use the framework to solve the assigned problem.
  • by xRelisH (647464) on Wednesday October 20, 2004 @01:49AM (#10572960)
    might be a list of common typoes and also weird compile errors that often scare newer programmers. Here's are a couple that I know of

    if( blah = true ){ // common single equal sign mistake
    }

    if( someclass->someMethod ){//I know of some compilers that do NOT give you a warning when you forget to put brackets in a function call.
    }

    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?
    • if( blah = true ){ // common single equal sign mistake Not so common in these days of modern compilers:
      $ javac test.java
      test.java:7: incompatible types
      found : int
      required: boolean
      if (i = 1)
      ^

      $ gcc -Wall test.c
      test.c: In function `main':
      test.c:6: warning: suggest parentheses around assignment used as truth value
    • by nmnilsson (549442) <magnus@fr e e shell.org> on Wednesday October 20, 2004 @04:18AM (#10573518) Homepage
      ... and suggestions how to avoid those errors in the first place.

      E.g.
      if( blah = true ){ // common single equal sign mistake
      }
      could be rewritten
      if( true = blah ){ // the compiler won't let you do this
      }
      or simply
      if( blah ){ // if blah is used as a boolean flag
      }
      (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!)
  • by pres (34668) * on Wednesday October 20, 2004 @01:53AM (#10572985)
    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).
  • by Chanc_Gorkon (94133) <gorkon&gmail,com> on Wednesday October 20, 2004 @02:04AM (#10573032)
    If the class is not a early class in the CS flow, don't place the focus of the course on simple documentation. Also, on a scripting class like Javascript, enforce what would be asked for on your job. Inline comments. Block diagrams or system flows are more used in industry then nitty gritty flowcharts and pseudo code. As most CS projects are too small to go beyond building just a flow, I can see why they don't use block diagrams.

    Classes should try to focus on teaching as much of the subject as possible in the time alotted especially if it's further down the prereq list. The subject should not be if you got your flowchart right! it should be if you got the program right AND knowing how you did it. Require the documentation, but don't let it weigh in heavy on the grade.

    In my current class, there are also group projects (in a web class no less). While a little hard to deal with, it's not too bad as that is the way alot of developers are meeting.....just in e-mail or IRC or what have you.

    In any case, as far as supporting others work, comments in the code and decent end user documents is all I ask.

    Also, alot of languages don't lend themselves to flowcharting...so why require it?

    Sorry, just venting on how far back in the times some instructors are! I spent the first 3 weeks of class learning basics....basics I learned 15 years ago.
  • by miyako (632510) <miyako AT gmail DOT com> on Wednesday October 20, 2004 @02:10AM (#10573056) Homepage Journal
    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.
    • by stewby18 (594952) on Wednesday October 20, 2004 @03:21AM (#10573299)

      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.

  • by Bullseye_blam (589856) <(moc.oohay) (ta) (1_eyesllub)> on Wednesday October 20, 2004 @02:17AM (#10573084) Journal
    When borrowing someone else's code to finish an assignment that totally stumps you... don't forget to change the variable names. [slashdot.org]

    -Bullseye
  • by mcrbids (148650) on Wednesday October 20, 2004 @02:43AM (#10573175) Journal
    I've been coding for some time very extensively using PHP [php.net]. It, along with GTK [php.net] 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!
  • by Viv (54519) on Wednesday October 20, 2004 @02:57AM (#10573220)
    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.
  • Way too advanced. (Score:5, Insightful)

    by kahei (466208) on Wednesday October 20, 2004 @03:07AM (#10573257) Homepage

    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 /tmp
    -- 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.

  • by hussar (87373) on Wednesday October 20, 2004 @03:44AM (#10573388) Homepage
    Don't provide solution sheets that contain code that will actually compile. After the frustration of working unsuccessfully for days (nights) to get her assigned programming project to compile and run correctly, what the student really wants is the character building exercise of debugging the instructor's solution to the exercise. When the students see that their instructor also has problems writing bug-free code, it will help to buttress their self-confidence.
  • by jlemmerer (242376) <xcom123 @ y a h oo.com> on Wednesday October 20, 2004 @04:07AM (#10573480) Homepage
    ... to be the microsoft way. did you copy it from them?
  • They forgot (Score:3, Funny)

    by coolgeek (140561) on Wednesday October 20, 2004 @04:10AM (#10573490) Homepage
    Don't waste valuable coding time checking for various error conditions and handling them. Most of the time the return code from various functions is just fine. If it isn't, then there is something really wrong with the system, or the user is a complete jackass who deserves to spend hours scratching their head trying to figure out why your program doesn't work.

    Time wasted coding error handlers is better spent implementing more features in your program. You can always wait for version 2 to implement real error handling where it is needed based on user reports.
  • by $criptah (467422) on Wednesday October 20, 2004 @10:32AM (#10575131) Homepage

    Computer Science is a good major to be in. It is useful, hard and interesting at the same time. However, given the fact that IT job cuts are on the rise, students should learn more things than just coding.

    I am a recent CS grad. I work in the field and yet I am thinking of getting a second degree that is not related to computer science because I realized that in several years developers who know only one thing -- that is coding -- will become extinct. What you need to teach CS students is how to develop valid and correct solutions that can be used by real people and businesses. These solutions must be well designed first; then developed. If I got a cent for every piss poor designed program that I have seen in my life, I'd be Bill Gates :)

    Developers solve problems with code; however, just because you have an ability to write a program does not make this program a valid solution! I have noticed that there are too many people with excellent software engineering skills that are simply out of touch with reality and its business side. If your "cool" program does not solve a problem it is absolutely useless in the real business world (the world where you get a pay check for what you do).

    Despite being relatively young, I have been employed in the field during all downturns. I managed to survive using only one rule: you must come up with solutions that are valuable for customers who are willing to pay for it. Unfortunately, many of the recent comp. sci. grads do not understand this rule. Instead of focusing on real life and its business needs, they spend their time learning languages without even knowing what these languages are good for. Then they use wrong tools for wrong tasks. My favorite example is my friend who used J2EE to build a site that could have been (and should have been!) done in PHP. He spent half a year on the fucking thing just to realize that a simpler solution could do everything that he wanted!

    Then there are people who run into terrible coding problems because their design is flawed. For some odd fucking reason people never think before they start implementing. I use one great rule: software engineering does not provide efficient solutions for some of the problems. Period. Too many people jump into coding without even thinking about the problem. They waste their time on something that can either be done manually with lower cost OR cannot be done at all. The worst thing is that most of these people are afraid of throwing their initial design away and starting from scratch...

    With this in mind, here is what I think every comp. sci. student should know:

    How to meet business needs with software engineering. How to "read" requirements and come up with solutions that meet them.

    How to realize that your design leads to implementation problems and when to throw such a design away.

    A well-written program is good. A well-written program that meets customers' needs is better.

    How to use a right tool for the right task.

    How to become employed and stay employed.

    How to use computer science in various aspects of real life. When I am talking about real life, I am talking about something useful that can be actually used by people. I found out that this can be achieved by taking a second minor or getting a second major that is not related to technology.

"The pyramid is opening!" "Which one?" "The one with the ever-widening hole in it!" -- The Firesign Theatre

Working...