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
rule one: do not post vulnerable servers on slashdot without a mirror
"goodbye and hello, as always" ~Prince Corwin, from Zelazny's Amber series
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.
Not cheating would be a good important one.
OBVIOUS, but always missed. If you need to cheat, change majors.
Wow... this story has been up for no more than 5 minutes, and already the site's almost dead...
Regardless, it's a clean, informative setup.
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 ;
It's satire dude...
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 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 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
Irony - look it up.
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.
If that's not Celcius, I'd love to know where the Spaniards are getting their heatsinks from...
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.
I can just imagine someone passing out halfway through a CVS commit and breaking the whole project, hehe.
If you are very good at programming and there are cute gals in your class take it upon yourself to offer then help and late night tutoring (if they ask for it.) If you are the typical geek who is akward in social situations then trust me there is never any easier way than this.
Quick guide to programming languages
Why not? As long as you can diff it the next day...
You would had proves highy superior documents which even you couldn't have understood (hic. - later)
I hope you don't work for Diebold.
I go to the ETS, (Superior Technology school) in Montréal, and currently strudying CS. The part : "Copy the programs. Lecturers will probably have to mark dozens of them, making it difficult to spot similarities between them. And even if they do, it sure as hell ain't easy to prove..." don't really apply to us.
... at least with respect to CS assignment handling...
You see, they have a kind of program, which they use to compare all the assignement that are handed in. Not only does it compare it with everyone in your class, it compares your code with the code of all the students from the last four year.
Try and copy anything now... good luck!
This is how you run a school
Any other school has a similar setup?
Here are the site's hit statistics (scroll down to October 20):1 461
http://www.nedstatbasic.net/s?tab=1&link=1&id=311
All your Sybase are belong to us.
hmm, does that mean I need to stop working on my java project due tomorrow in class? I mean I followed the rules that said to wait till the last minute!
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.
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.
I find that with a little alcohol in my system, I code better, my programs seem to be more readable, as well as perform better. Not to mention that the comments in my code seem more complete.
Try doing the opposite of what it talked about in the article and it might actually get you somewhere
What are you expecting to find here?
Already slashdotted, so i'll write my own guide.
Problem: Need a balanced 2-3 tree implemented in C++ due tomorrow?
Solution: Google it.
Problem: The Junit test fails at line: assertTrue(true);
Solution: Switch majors.
Problem: Mutual exclusion is not guarenteed in your critial section.
Solution: Use a single thread.
Problem: Deadlocks occur when you access the disk controller and main memory, but only in that order.
Solution: Get more memory from Dell.
I hope the rest of your deadline riddled, extreme programming and debugging sessions are as enjoyable to you as they were to me.
Hrmm did you know a java constructor will call super() for you if you dont do it yourself? Even if you have no super() without parameters? And that it will refuse to compile without telling you it has done this?
Thanks, but I have my very definitive programming guide already. Mwaahahha
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...
Indy Media Watch-Proctologist of the Internet
Here's somethign useful: Apparently, some graders do not like you to use the ? : operator. They get confused, and mark you down. Getting the points back can be annoyingly time consuming.
/usr/games/fortune
After all, all the coding jobs will be in India now, no?
I appreciate that you're trying to point out common mistakes and misconceptions, but the whole tone of the thing just seemed like it was aimed more at making fun of students past and present than at helping them. Am I the only one that thinks constructive criticism is better than being a jackass? Almost all the tips had nothing to do with actual coding. ("Ignore error messages, you'll be soo c00l!!11!") Somehow I doubt that this will endear you to your students.
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.
.. most CS students should not be in the program much less touching computers. A good programmer is usually found in someone who does it outside school or work requirements. Someone who touches the command line for the first time in their Intro to Java class (one of the first ones in most CS programs today) is not one of these people. That is the majority of CS students. The ones who do the tihngs listed on that page.
One of the banes of my existence is "normal" warning messages. Warnings that everyone expects to see and just ignores, completely unaware of the very important message (e.g. An uninitialized variable) that got lost in the noise.
Unfortunately, the VC6 compiler we use has a few useless messages that can't be disabled. (e.g. "Symbol too long for debugging" when a template is being expanded.) Those cause some serious grief on occasion.
Dont compile on a regular basis, dont tiptoe your way forward. Youre a professional and professionals take giant steps. Write thousands of lines of code first and leave the compiling for later; it will be far more entertaining and worthwhile to look for compiling errors.
Actually that's uncalled for. Compiling frequently is not good because you should not be thinking about such details as syntax and var name spelling until the very end.
For most of the time you're writing code, what you have should not be compileable. Well, doesn't need to be. Since you (hopefully) are doing things top-down, at first you're going to have a lot of empty functions and comments.
Then you're going to fill in code. During coding, why bother compiling? Who cares if you get a 100 compiler errors at the end when you compile once, vs. getting 1 error each time, but having to compile 100 times?
Don't bother. Focus on the higher picture. Implement your vision. Only once you've done that, fix what the compiler is bitching about. Doing the same things along the way can sidetrack you from your higher-level view of the program.
Besides, it's a lot less annoying. Say, you're done coding. All you have to do is go make tiny changes to shut up the errors. Probably won't have to think too hard how to fix them. And then you're DONE!
The other way, you go fix your errors, and you still got mad code to write. And now you're annoyed and distracted so it won't even come out as good.
Also, sometimes I actually shock myself by writing code for an entire day and then having it compile w/o errors the first time! I really don't expect that, and it's a "wow" thing when it happens.
Ecce Europa - Web Design for Business
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
that fills me with so much shame i just want to rip my anus open really wide.
Read one of Asimov robot books. You're probably going to be working on positronic brains and doing robot psychology, anyways. Humanoid robots are going to do all the coding for us in the near future. ;->
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.
WOW U R SMART MISTER MAN
Or, perhaps not read this...
Okay, I know that there are a lot of professional developers out there who follow some of the "rules" in the article, especially those involving ignoring warnings. I've been in professional programming environments, and I've seen this sort of thing excused all too often (personally, my code isn't done until it compiles 100% cleanly). However, for good or bad, this is typically hidden in closed-source projects -- how many compilation warnings does Microsoft get in its nightly Windows builds? I have no idea.
Unfortunately, in Open Source Software everyone gets to see where the developers ignore warnings, and IMO there isn't much excuse for it. Honestly, there are far too many Open Source projects which seem to do the things this article "advocates". And everyone gets to see it.
I remember all of the warning messages I get when building the Linux 2.4 series kernels. And I recently looked into forking the recently cancelled JPluck, but its near complete lack of code commenting makes the effort exceedingly difficult.
This has long bothered me. If you're going to release your code as Open Source so others can work with it, it should at least have some comments in it (even just simple things like the expected input.output values for procedures, functions, or methods, expected use for variables/fields, etc.), and it should generally build without a single warning [1], in order to make it easier for others to work with the code, and to ensure them that there aren't going to be any unexpected results due to ignored warnings.
Yaz.
------------
[1] Okay, I know someone is going to call me a hipocrite when they go and grab the sources for the Open Source project I administer (the jSyncManager), build it, and find well over 100 warnings. I just want to preempt this by stating that these deprecation warnings occur because I've specified parts of the jSyncManager API to be deprecated to ensure developers currently using these deprecated classes move their code over to their replacements.
here Still takes forever to load though.
http://mindprod.com/unmain.html/
My favorite:
Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
LINT, on the other hand, needs to die.
meet yourself
1. Estados Unidos 3542 74.2 %
2. Canadá 344 7.2 %
3. Australia 334 7.0 %
4. Reino Unido 82 1.7 %
5. Nueva Zelanda 67 1.4 %
6. Japón 37 0.8 %
7. India 37 0.8 %
8. Alemania 34 0.7 %
9. Finlandia 33 0.7 %
10. Suecia 18 0.4 %
Desconocido 52 1.1 %
El resto 191 4.0 %
I can't seem to figure out what "El resto" means
-888 Geek Help (888-433-5435)
More interesting still are the Browsers used and OSes by the Slashdot crowd.
Hey, Firefox is doing pretty well around here. Still surprised at all the IE6s though.
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
but if its a team project you will probably wake up to an angry mob of people because you submitted a bunch of BS code that doesn't work.
No, they'll just call it WindowsXP Serice Pack 2
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
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
For once I think someone shouldn't have read the article! You should have just read the post. Perhaps your point is that ignoring messages is a mistake made all too often in the real world, and not just a common CS student blunder. They way this post was phrased though, it sounds like you just didn't get the humor.
I disagree. Coding under the influence will NOT get you arrested and sometimes the results are pretty funny.
if it was difficult to write, it should be difficult to undestand.
(I wish I could remember where I read that!)
Oh, and write lots of swear words in your closed source. That way if it's ever leaked people can say how unprofessional you are.
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).
In Soviet Russia comments insert you into the code.
"Like fire and fusion, government is a dangerous servant and a terrible master."~RAH
I agree with this. Trust me, I managed to code for about 6-8hrs straight after a bottle of Shiner....course this wasn't school assigned work, it was a project I was working on. Curious? Visit http://motd.4d2.org/TJ/ I was the "supporting programmer". :P
afterwards, the hitwomen declare, "All your base belong to us!"
Sorry, I can't seem to find my funny bone. Yes, the point is that the mistake is a common real world blunder that causes serious problems and it's not confined to those learning the trade.
meet yourself
1. Estados Unidos 4828 72.3 %
2. Australia 503 7.5 %
3. Canadá 490 7.3 %
4. Nueva Zelanda 98 1.5 %
5. Reino Unido 92 1.4 %
6. Finlandia 64 1.0 %
7. India 62 0.9 %
8. Alemania 54 0.8 %
9. Japón 54 0.8 %
10. Suecia 43 0.6 %
Desconocido 65 1.0 %
El resto 325 4.9 %
I can't seem to figure out what "El resto" means though
-888 Geek Help (888-433-5435)
Re-use is ok after you graduate so the professors are OK, copyright assumed not to be an issue. While you are learning you need to do things yourself.
but 50% of /.ers use window$
-888 Geek Help (888-433-5435)
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.
There was one very funny incident in my school, a long time ago. This student copied the code from this other geek. Unfortunately the original writer put his name all over the place, like (c) Bill Gates, etc. So, the student had to do a manual find and replace (because he didn't know how to work vi either).
As we, in the software community know, manual find and replaces are prone to errors. So, he submitted the code to his professor, who approved it and executed it.
Unfortunately, the output started with something like:
THIS PROGRAM IS WRITTEN BY BILL GATES
Luckily, the professor did not see the message printed, and gave him a high score.
If you try to keep your program correct as it grows, it will be too easy to pinpoint a new bug. Only cowards do that. A real programmer writes the entire program and then digests it whole like a boa constrictor. Looking for a bug hidden in the last 10,000 lines is exciting but if there are only 10 or 20 lines, well, what fun is there in that?
Was this written by someone at Microsoft? What a waste of time
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 there (I've had to TA programming courses many times).
This article is a load of bullshit. If it is trying to be serious (which i'm almost certain it is not) then it could not be farther from the truth. If it is trying to be comedic, it isn't really very funny...How does this crap make the front page of Slash Dot?
Bad Joke (Score:3, Insightful)
I kneel before your trolling abilities!
Tell that to the programmers at microsoft
But then I'd never get any coding done....
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
The primary component of daytime sinus/cold medicine can create a mental state that is medically indistinguishable from mania. Any diagnosis of mania is automatically shelved for the time being if cold medicine might have been involved.
That is to say, Sudafed makes you insane in the same way Lord Byron and Van Gogh were. Good for poetry and painting. Bad for coding.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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?
#pragma warning(disable:4786)
rather than include the #pragma in-line in your .CPP. Then,
#include "pragmaDisableInvalidWarnings.h"
in your .CPP above any STL includes, and the magic should take over from there. (I think -- my code that does this is at work and I don't have access to it at this time.)
John
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).
Check this link for a workaround that I know we use. For whatever reason, declaring a static with an exceedingly long name made it happy.
John
There was one language missing on the list: C+-. This is /. curriculum, so go get some some info about it. A slightly different explanation of it also exists.
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.
Muchas Gracias, Señor Edward Snowden !
this article was pretty f-ing stupid
Could Jesus microwave a burrito so hot that he himself cou
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.
Gorkman
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!
John
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"
I don't think the article applies to drag-and-drop-right-click-properties-check-smart-o ption programming style. First, it's like using a pencil to draw the idea to someone, then, it performs, as a program, in the same manner (as the pencil?).
OTOH, "Lecturers will probably have to mark dozens of them, making it difficult to spot similarities between them": you'd be suprised the science lecturers develop to measure the software quality and compare the algorithm's implementations. I think it's like researching on teaching techniques & prevetion of student's cheating, but it's reasearch, dammit, it's payed, so:
Rule #FFFFF: do not write code, give it to your students and then ask smart questions about it
gtkaml.org
When borrowing someone else's code to finish an assignment that totally stumps you... don't forget to change the variable names.
-Bullseye
My profs insisted that we should diagram the process algorythym before coding.
..ramble on...
They recommended strict diagramming techniques like Warnier-Orr. They said use a white board with big erasures and little markers because large sections are going to be junk.
Strict and systematic Warnier-Orr diagramming can be a real discipline.
I've gone back to it in order to code very tight , time-dependent 50 nanosecond mulitple interrupt routines in assembler for microcontrollers and embedded systems. I've even placed the white board on the flatbed scanner to copy it when I've gotten that finally works in a walk-through (take the hinged cover off- it goes much easier.)
Even after doing this..and then assembling and burning the code into the chip..and having the device actually function correctly..I still get the feeling that there is something stange and magical happening that I'm not aware of.
One just sits down and tells oneself that, no, there's no magic here. You designed a complicated machine, you throughly tested a precise simulation, you built it, and it worked exactly like it supposed to because there wasn't any possiblity that it could not work like it was supposed to. It's just going through hundreds of precisely defined steps many millions of times a second...and gives the illusion of magic and sentinite intelligence.
I find that with a little alcohol in my system, I drive better, I am more assertive, and perform better. Not to mention that the other cars on the road seem less important.
The article was well written but based on my own experiencies the reason exercises are sometimes terribly badly written is because a lack of time, not because you didn't know what that there were better ways to do things.
Exercises are usually done as quickly as possible and code readability and maintanability is thrown out of window because only thing that matters is to make it pass the minimum requirements.
I've been coding for some time very extensively using PHP. It, along with GTK is a good, high-level language that lets me get lots done, very quickly.
In many cases, it will accomodate common errors, such as strings not being quoted, etc seemingly without complaint.
However, I recently changed my strategy to one of "zero tolerance", which entailed me reducing the error reporting threshold to 0 (all errors) as well as defining a standardized error handler callback function. I spent about a month just going thru the existing codebase to quote all the strings, etc.
However, now having done paid that price, I'm quite surprised at how often bugs that would have previously gone un-noticed pop out in clear view.
Undefined variables previously translated to equal false now stand out as a mis-spelling. Database errors previously un-noticed suddenly highlighted and shown to me. Hiccups in the code previously shown to users now archived and hidden away so that I see them instead.
It's made a HUGE difference - I'm more productive despite the appearance of having more to look out for!
I also have a generic error() function defined that's really a wrapper for the error handler - so the error logging system now in place works for language errors and logic errors alike.
It's awesome!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Years ago, a server product I worked on had a nasty race condition in an error path that was only hit under heavy stress. Another engineer and I spent hours staring at the source, spelunking through the debugger, and creating dead-end theories. The next day, after getting sloshed at a Friday afternoon beer and wine party at work, we decided to attack the problem again. 15 minutes later, the bug was obvious, and easily corrected.
DUI (Debugging Under the Influence) can be highly productive.
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.
so youngster studying this stuff will be half way there. . .
I think both exercise makers AND course staff should have less arrogance. It is also really annoying when a older student who have only passed the course with no real C++ experience starts claim that he is right and therefore you must be wrong without even reading your arguments. By that time I had 10+ years experience in C++ coding (and software development and basic algorithms of course) and had written my own (primitive, not-full) C++ compiler.
It'll work.
I actually submitted an assignment without testing it AT ALL once, and it worked without a hitch. Scary thing is: it was a cyclic-executive real-time scheduler in 68hc11 assembler.
Of course, I'd very very thoroughly stepped through every code path by hand.
Since modern code editors force tabs or spacing in these scenarios, I find comments like "// end if" to create more noise overall. The other problem that "// end if" is trying to fix is when the original statement is off the screen, in which case your code desperately needs to be refactored. Finally, I believe that the next version of VS.NET tells you the expression and line number when you hover over a closed brace. The bottom line is, I'd rather rely on tools to force style such as indenting, as well as clean code to avoid the need for comments that can add noise as well as become outdated and accidentally express the wrong meaning.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
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.
I think you got it: I found it painfully un-funny ... likely it'd key right in with first year students' sense of humour.
--
If you look to see how the system works
likely you'll find that it doesn't.
-- When you look to see how the system works, you usually find that it doesn't.
The best part is I read that while putting off a programming assignment.
Hikery.net - The best hiking site ever. Made by yours truly.
I checked it the day after. It was still beautiful.
Insert `fortune -o` here
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.
"Asserting that one must first know the rules to break them, this classic reference book is a must-have for any student and conscientious writer. Intended for use in which the practice of composition is combined with the study of literature, it gives in brief space the principal requirements of plain English style and concentrates attention on the rules of usage and principles of composition most commonly violated." This book has never been out of print since 1918, and Lo! W. Strunk and E. B. White (you may recall a fiction of his) still hit the nails on their heads! I highly recommend every person have this thin volume on their desk for casual perusal, but failing the hard copy, here's a link to the online version http://www.bartleby.com/141/
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.
In debugging an NES emulator, I once spent at least 13 work hours going through M6502 emulation code, and all the other byte and bit-level logic that goes into an NES, only to find I'd used two == instead of one somewhere.
Another time (5 hours of work buried in run-time assembly debug output) I found out a bug was placed because I had the two controllers set to the same input. (I.e. they'd both hit select at the same time. Couldn't start mario, etc.)
Some mistakes are just unavoidable.
There is actually a better way of getting rid of these rather than contaminating your code with unecessary #includes. Check this out. Basically add the same pragma command to YVALS.H which is in the include dir for the Visual studio installation.
In case you are wondering whether you are really going to break something, the error message relates to the debugger not being able to handle >255 chars.
The problem with this warning message is that it can obscure real error & warning messages.
meh
Shoulda' just done what I did, and replaced the compiler with a spurious error message generating wrapper...
Compiler says 'Ack' from rec.humor.funny
I thought: "I don't think the Counter Strike addicted students will be interested in this!" ;-)
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 one floppy because it was really just a program loader and a half-hearted attempt at a shell, and "searching your filesystem" meant rummaging through desk drawers for a floppy disk! Programmers could fit apps of the time into tiny memory spaces because their programs didn't *do* much of anything, not because they had some magic ability to "code properly" that's lost on programmers of today.
0 1 - just my two bits
Don't start computer programming - it is a dying industry. Unless you want to work in India or China.
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.
Bureaucracy loves company.
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
you must have a 3 digit IQ
LMAO
-888 Geek Help (888-433-5435)
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] will work."
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
In my company, coding under the influence of alcohol is standard operational procedure. We do all the hacking late at night with some beers. Errorhandling and refactoring is done the next day when sober.
Catfish lover wrote:
I jacked off so hard to this the skin on my dick came off.
[slurping up cum as I type this]
Apparently there are oodles of televisions available at Best Buy that can be purchased for mere hundreds of dollars, but after thousands of man hours and hundreds of thousands of dollars invested into equipment and experimentation, I have learned a lot more by building my own television than I ever would have by buying one.
I think I'll even build a color television within the next three years!
Seriously, advancement of society DEPENDS on NOT repeating the mistakes already made by others. You'll have plenty of chances to make mistakes no one has made before after you've brushed up on mistakes you shouldn't repeat.
paintball
(Posted in "Code" so as to get the formatting right).
/All/ of your sources are using this. Someone comes along and uses an editor which inserts a tab character instead of spaces, with a 3-character tab stop. They work on a file, and check it back in.
/multiples of eights/! If developer number 2 didn't just add new functions/methods/etc. to the end of the file, and they added lines inside existing blocks, the code readability is now totally fubar.
/noise/ provides structure, and allows you to determine which close braces go with what statements. It is due to this sort of potential confusion that many non-C derived languages actually use specific close statements for each different type of open statement (ie: Pascal, Modula-2/3, Ada83/95, shell script (although for a somewhat different reason).
...
...
...
... // Oops -- not supposed to be inside the for statement
"Since modern code editors force tabs or spacing in these scenarios, I find comments like "// end if" to create more noise overall."
It's additional meta-information. And if you're working in a group where each developer gets to choose their own editor (such as in virtually any Open Source project on the web), if one user sets their tabstops to something different from the rest of the group, and/or someone starts using spaces instead of tabs (or vice-versa), you wind up with indentation problems.
For example, you're using tabstops every 3 characters, insterted as tab characters. Some guy working with your file is using 4-space tabs, inserted as spaces. They need to add a line of code below an existing line starting at column 12 on their display (ie: three tab stops in your editor). So they hit tab three times. Looks correct to them, and the editor permits it, so they save the file and fire it back to you.
/You/ look at the newly added line, and see that where the previous line starts at column 9 on your display, their newly added line starts at column 12, one whole tab-stop extra.
Or how about if you're always working with only spaces (ie: tab is set to insert three spaces, and not a tab character).
Developer number 3 checks out the file, and for whatever reason always uses the space bar instead of the tab button for indentation. Because of this, they never bothered to change their editors default tab stop of 8. They load up the file, and suddenly it's a mess: the space-stopped lines are still indented in multiples of threes, but the lines containing tab characters as inserted by developer number 2 are now indented in
And yes, I see this happen all the time, both inside and outside commercial development. You can mitigate this through education and enforcement, but anyone who does any real development work has seen this happen.
Adding what you call
And in some environment, it can be exceedingly important if you're nesting a large number of blocks. Take this simple Java example, for example:
// A fragment of Java
class MyClass {
method someMethod() {
for(int i=0;i<100;i++) {
if(i<50) {
synchronized(this) {
try {
} catch (Exception e) {
}
}
}
}
}
}
Here there are six closing tags in sequence, in short, concise, and valid code. It doesn't take much to scroll the top few lines off the top of the screen (I'll get to why your refactoring comment is invalid in a second). It is exceedingly easy to introduce errors here, such as inserting code in the wrong place, such as:
class MyClass {
method someMethod() {
for(int i=0;i<100;i++) {
if(i<50) {
synchronized(this) {
try {
} catch (Exception e) {
}
}
}
doSomethingElse();
}
}
}
This is very easily mitigated through the mechanism I've already demonstrated:
class MyC
You only catch bad cheaters, by definition.
paintball
... to be the microsoft way. did you copy it from them?
".Sig Stealer" was here
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.
cat
I own a program that myself and one other person do the development of.
His If syntax is always
if ()
{
}
else
{
}
And mine is always
if () {
} else {
}
Which always frustrates me due to vertical space wastage, but it makes it easy to determine who to blame when a bug is found.
paintball
Take a program done by 3-4 people , pick the best parts, integrate
Macros from one, sortings from another, recursion from yet-another...
It's a lot less hard than writing it yourself and the result is often better than the originals .. Most of all, you actually learn from other people's mistakes .
Even after getting a job, I find that this is a much more stable way of programming newish things -"find a lot of similar things, pick the best strategies & adapt".
Btw, these days - that's called "Research" :)
Quidquid latine dictum sit, altum videtur
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.
Yahh, hiii haaaaa! -Major Kong, from Dr. Strangelove
You're a Java or C# "developer", right? There's no way in heck you can program all day in C++ and get everything to compile without at least warnings.
That's a real word?
paintball
The errors and warnings are almost always printed out in the order the compiler found them; fix the first one. Once you've fixed the very first error or warning, you may have completely solved the problem; continue to go down the list of errors in order until you find one that might not be an error or warning. Then recompile, and restart.
I've written C that when fed to a compiler generates a few thousand errors; once I'd fixed the first error ("Cannot find ; skipping"), they all disappeared.
I appear to have a blog. Odd.
Every response to the parent has been negative.... "That's horrible advice" etc etc. However, I find myself agreeing with the parent, as long as you have atleast one year experience programming.
:P
For most of the time you're writing code, what you have should not be compileable. Well, doesn't need to be. Since you (hopefully) are doing things top-down, at first you're going to have a lot of empty functions and comments.
How could you disagree with this statement? This is basically writing pseudo code, which is how most things should be done. It's just an OO approach. Write code that utilizes functions / class methods that dont yet exist, this lets you create your logic. Then go in and write the actual methods, which eventually will make your logic work. OO approach lets you focus on logic and fiddle with technicalities later. This is how it should be done.
Joseph?
Actually, if CANNOT code while totally drunk, then your brain is probably too fragile to handle crunch deadlines of 19hrs/day coding before release.
:)
But I guess that situation is caused by under resources because of management.
Now try coding in assembly while on LSD, if you cannot do that, then your not mentally strong enough
Think of it as a Metnal Gym, you're putting extra weights/obstacles to make things more difficult, if you can handle that, then your even better when normal just like running training.
Liberty freedom are no1, not dicks in suits.
I cann't read clearly,who can aid me and be my firend,gangshuo@126.com,
I'm glad the BSD guys followed that rule.
I think I have some more
The sad thing is that the kids won't read this. After all, they don't like to read.
The really sad thing is that if you are after some Slashdot fame, you shouldn't be reading igt either. The point is writing those comments, not reading those stories. You might end up on page 2 if you read the story first.
TFA may be ironic but it might help more if it was sarcastic. The number of sites at which I've worked where Warning messages are set to Ignore is ridiculous.
At one place, so many warning messages were being generated that when I eventually got a decent developer on board, after writing some scripts and working hard to reduce the number of messages, he got the overall compile time to go down significantly. Of course, despite my 'petty Hitler' rantings, most of the team decided not to fix the cause of these errors and the compile time started creeping up again. The arrogance of these guys was palpable, they had no intention of improving, they were, after all, the A-team (or so they said). I eventually moved on to running another team in another part of the company - who were prepared to listen (or were more afraid of me maybe) and, with other processes, productivity shot up over the course of a few months.
Did he inhale?
I was marking some assignments, which included screenshots of graphs with black backgrounds, well...
:)
One student copied and pasted someone's graph into his report, but to stop them being similar he decided to blank out a box of numbers in a paint program...
Somehow he used a dark grey instead of sampling the true background color
I really wanted to write... "If you are going to cheat, at least cheat properly, retard!", but I was afraid of retributiuon.
The worst part is that it was modded +5 insightful, huh !
Yes, but how about when you sober up ?
Acrobat Reader 6.0.2 on WinXP SP1 reports an error #140... :-(
You might want to check that...
Totally agreed. The "witty saying" is bullshit. Think about it like math: if you read about the mistakes someone made when solving an equation, and not make them yourself, you will never know how the mistake was made and will ony be able to solve the equation routely, not be able to consider how to solve the equation and do it properly. Reading other peoples mistakes is worthless unless you are making that mistake and are reading how others solved it.
...it's probably just coincidental, because all the schools have been mandated to teach the same contents!
Whatever. All learning is copying anyway. And the idea that we "shouldn't" is just another primitive manifestation of that deranged IP regime. I'm just glad I don't get charged for every word I use that Shakespeare used before me...
Might as well have a guide to it: http://mindprod.com/unmain.html
Zeks: Look, man, if there's one thing I know, it's how to drive while I'm stoned. You know your perception is completely fucked so you just let your hands work the controls as if you were straight.
It's the most agile form of code re-use.
You'll get marked down in Programming class but you should get EXTRA marks in Software Engineering. You could get a job at Micro$oft; on the downside you will get an 'F' in Software Patents.
Nothing to C here, move on.
One of the banes of my existence is "normal" warning messages. Warnings that everyone expects to see and just ignores, completely unaware of the very important message (e.g. An uninitialized variable) that got lost in the noise.
Nothing annoys me more than compiling an open-source app and seeing 100,000 warnings scrolling up the screen. Many huge projects have this tendency.
I rum on the x86_64 platform, and sometimes I wonder if I wouldn't have nearly as many porting-related bugs if more people paid attention to complier warnings. (That and data type sizes...) Sure, the program might work without correcting whatever caused the warning, but just wait until you migrate to gcc 3.whatever...
Hey, as one of the (many? :-)) dinosaurs on slashdot, I take personal offense: I acutually DID learn to program in FORTRAN in high school in 1972...ah, those were the days...and IBM360 assembler...on punch cards...without monitors...:-) Ah, these young whipper snappers with their LCD monitors and Visual Basic...what do you expect when they are confronted with a REAL compiler like gcc? The nonsense I get from students who have been trained on VB, (and of course, even worse, using windoze) in high schools...sigh...our education system is doomed! ;-)
- Don't use Microsoft products
- Don't use C++
- Don't use XML
Tripping on dextromethorphan and boosted by ephedrine.. that's Dayquil for you.
:)
It's not exactly LSD, but there's no wonder your logic was bizarre
Since drinking alcohol would be frowned upon here I take the drink-crap-loads-of-coffee approach to feeling buzzed at work! Most days it does the trick. When it doesn't at least I can take lots and lots of trips to the bathroom.
Yeah, because, as we all know, weed causes you to totally blackout for HOURS on end with no recollection of the evening *rolls eyes*
BS.
Please, you bloody septics, learn to measure temperature properly. Like the rest of the world. Like this.
;-)
-273.16 degrees = as cold as it gets
0 degrees = water freezes
4 degrees = water expands whether you heat it or cool it
5 degrees = warm enough to wear short sleeves
15 degrees = warm enough to wear short sleeves, even for nesh southerners
20 degrees = verge of breaking into a sweat
37 degrees = human body temperature
60 degrees = a good washing temperature for cotton
64.5 degrees = boiling point of methanol {wood alcohol}
70 degrees = too hot for most living things
78.5 degrees = boiling point of ethanol {grain alcohol}
100 degrees = water boils
Note, boiling points are quoted at sea level. In the mountains the atmospheric pressure will be less, so the molecules will have less opposition to escape, i.e. the boiling point will be lower.
Now, you absoutely have to have access to an IDE to look up api definitions and to write a bunch of testcases to figure out what the function really does, since the documentation is usually gibberish. Oh, and googling for examples of workarounds when you figure out how screwed up the function really is.
Never operate any machinery under the influence of alchohol or drugs. Even computing machinery. And certainly not chainsaws.
And remember, class, that every year I'll take one and only one work, the worse you produced, and sent it to the obfuscated C contest! And now let's review last year's winners of that dubious award:
http://www0.us.ioccc.org/main.html
Here teacher pretends that students from last year won IOCCC, and wants student to figure one which IOCCC program fits a class assignment *by looking at the code but not running it*. Or teacher pretents they didn't win, depending on your class...
Microsoft is pure dog-ma. FreeBSD is pure cat-ma.
Boss: "Johnson! Why are there crude sketches of naked women and throw-up all over these design specs!"
Johnson: "Company policy boss."
SIGFAULT
His name, Bill Gates. His windowing code: Windows 1.0
SIGFAULT
I actually disagree here (for school projects anyway). I have some of my best coding when hammered on wine my father made. I simply woke up with the laptop laying next to me and all the homework done, correctly, and COMMENTED.
His wine tends to sneak up on you.
Seriously I write my best stuff while drinking, when I was younger I used to do my assignments when drunk. Occasionally after a saturday night of drinking I'd jump into coding. it is great at like 3am on a saturday night you cannot talk but the code is a flowing.
Not only can you code, but you can code three times as fast. The only issue is it must not be thought intensive algorithms, if you want good design and performance figure that out while sober. If you try to design something while you are drunk things get ugly, i was had a TA tell me that my program worked, there was no reason it should work but it worked. This man was totally dumbfounded by 200 lines of C++. I also find that you can come up with good ideas drunk. I have done some of my best thinking under the influence.
As for waiting to the last minute, well if you can't code drunk this is a good substitute, nothing like a deadline to get the blood flowing.
look at the sats on the page . Quite interesting. So apparently 46% of slashdot is from the US? or only 46% reads the story? hmm
The war with islam is a war on the beast
The war on terror is a war for peace
Not having parenthesis in a pointer to function is fairly normal for functions that take no parameters.
Best Slashdot Co
AMEN BROTHER!!!
Better yet, take a software engineering course if it is offered. Granted, it was back in the early 90's when I was in college, but my software engineering course was what got me my first job out of college with a big company. I took my senior project with me on my interview and showed it to the first person I talked to - she said "show this to every person that interviews you today". There was ZERO code for this project. What it did have was requirements, design, budget, test plans, mock-ups, documentation outlines, etc. All the stuff that is done outside of actual coding. This is how things work in the real world. It was the most important class that I took in CS. I probably won't be coding in Pascal any time soon, but I still use the principles I learned in that Software Engineering class.
I will admit that it has been a while since I did any hardcore coding, but if you are doing any kind of project, design it first. Draw pictures. You'd be surprised how much easier it can be. I am still amazed after working in the industry after 10+ years how little software engineering education a lot of coders have. And there is a HUGE difference between a coder and a software engineer. Learn the concepts early and try to use them as much as possible. I couldn't write requirements to save my ass in college, but just the fact that I tried, and knew where they fit in the process made a huge difference. Do you know what a testing organization does and why? Where I work, we just got a set of issues out of a "lessons learned" session for our release that just went out. Many of the questions that came out of our development group were along the lines of "What does our QA group do, and why?" Some of these people have been coding for 10 years or more, and they don't understand why we have a QA group (QA and testing, which aren't the same thing)
My beliefs do not require that you agree with them.
The best for this is absinthe - too bad you can't find it in the US, and only the crappy stuff in Canada. Good (European, or even South African) absinthe "quiets my brain" better than Ritalin, and without any of the annoying side-effects of Ritalin.
Just remember - moderation is key (and not the Slashdot-type moderation). TA's *hate* to mark assignments covered in human "spewage". (Trust me on this!)
I was a Teaching Assistant (read: I graded assignments and tutored students) for an introductory computer course at my university. The course was affectionately referred to as "Chips for Dips," since it was intended for non-comp-sci majors (in fact, comp sci majors were ineligible for the credit). It taught things like how to use the Internet, how to use Word, PowerPoint, email, that sort of thing.
Anyway, amazingly, some people couldn't even be bothered to learn how to "create a Word document describing your major, using 5 different fonts." Spotting copying was generally pretty easy. On more than one occassion, 2 students would pass in identical assignments, with only the name changed. The giveaway was that the copier had forgotten to change the student ID number on the assignment, which was still that of the person he copied from!
Like woodworking? Build your own picture frames.
it is very simple to defeat these systems because they are done by a computer. if you have someone else's source don't submit that rewrite it, use different variable names, different code structures. if it is a single block make yours functions, if it is functions make yours a single block. Change data types and use pointers instead of standard variables, use different data structures, use your own data structures. i have helped friends by rewriting my own code our wiz bang system could not detect the similarities because while the logic was the same, computers do not know logic. they know variable names, function calls, and program size. Clearly two very similar programs will be flagged because it will match the structure of the code or the variable names, function calls or structure of the functions.
But if you reorder the code, change the functions and structure, that dumb ass autocheck will not discover it nor will a lazy TA or Prof.
If you like this approach, you might want to take a look at Knuth's "Literate Programming." One place to start is http://www.literateprogramming.com/
In either case, one needs to remember that too much can be as bad (or worse!) than too little. In real life, you may not always be the one to edit the code, and if someone edits the code but doesn't update the commentary, you can get into real trouble.
-Hil
Hahah, I know exactly how you feel. I wasted 2 hours on what should have been an extremely simple C assignment in university one day. Back then, we did our C/C++ assignments on a shared Solaris server, working on dumb terminals in a lab. I was getting some kind of strange exception with my C macros. So, I created a "test" program and copied over the guts of the logic of my app, so I could re-add the functionality piece-by-piece until my test app broke. This would allow me to isolate the code that was causing the problem.
/usr/bin is at the beginning of the $PATH, and how one can use ./test to make sure that one is actually running the program in the current directory, rather than the system utility with the same name!
Only one problem: my "test" app didn't appear to be doing anything. It would run fine, with no error messages, and then exit quietly. In fact, it was producing no output at all. I began removing code, and adding printf()'s, desperately trying to get my app to say something, anything. After a couple of hours, I had stripped my "test" app down to little more than a "Hello, world" app, but it still wasn't producing any output! I would just type
dragon:/home/kombat/> gcc test.c
dragon:/home/kombat/> test
dragon:/home/kombat/>
Can anyone spot the problem? Anyone?
It turns out that "test" is actually a built-in system utility for regular expressions, used in scripts. That was the day I learned what my $PATH means, why
That day ranks as one of my most stressful, and yet most educational, at university.
Like woodworking? Build your own picture frames.
THE MOST IMPORTANT THING FOR YOUNG PROGRAMMERS TO LEARN IS READABILITY.
Yes, code must work, it must error check and be stable. Good design is an obvious requirement. But, too many young programmers don't know the true value to business of code readability. I'm a 15-year veteran primarily in C, C++, Perl, Java, and alas, Cobol. I've seen crappy code for years as a contractor, coming in to fix problems or add features.
The statistics on business costs bear me out. Nearly 50% of the cost of a program is incurred during the long in-use / maintenance phase. There are definite rules for making code readable and they should be taught early.
Practice during programming classes should include:
* Code reviews - other people looking at your code;
* Code reviews - reviewing other people's code and asking lots of questions;
* Style guides - rules re: what coding style (where to put curly braces, for one) to use on a project are common, be prepared for them;
* Simplification paradigms - stuff like avoid do_while loops since they're seldom used and often just confuse people;
* Reliability lessons - lessons like don't use while(1) loops with breaks, rather for(1..n) with an overlarge n and subsequent test if N got big to know if things failed;
* Max Subroutine sizes - too often violated but a bigger deal than you think;
* Global variable minimization - sometimes it does make it simpler to use a global variable, just keep it to a minimum;
Lots of these rules apply. SIMPLIFY! SIMPLIFY!
It speeds up everyone's life.
--Kevin
Unitarian Church: Freethinkers Congregate!
I find that usually the only way I can slow my brain down enough to write code is to consume alcohol.
My best code is written under the influence of moderate amounts of red wine (usually Merlot). By moderate I mean between 30-50% of a 0.75 litre bottle, sustained over 2 hours. Any more and I become too tired. Beer is no use. It makes me too lethargic and happy. I listen to heavy metal instead.
Stick Men
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.
Tsunami -- You can't bring a good wave down!
(*) Profesor Auxiliar is a student who already has already passed the class/course, usually with high marks, that does practical classes (as in "problems like the ones you are likely to see in the written tests" or "some tips for this week's assignment") to complement the professor's theoretical classes, and usually runs the "accounting" (grades and all that), takes care of the course website, that thing.
It happened that this time, the professor had been appointed as "Director de la Escuela", and, as an official of the Uni bureaucracy and not just "a professor", he was bound to apply the rules to the letter. So we had to (I was TA) hand out a sheet of paper during the first test and I told them "people, we're onto you. We have tens of cheaters (from a 100-people class) indentified in assignment #1, and this time, you are S.O.L. because the prof is ALSO the director, so he's bound to send you straight to the rectory, instead of marking you with the customary 1.0. In this paper, you can write your name if you admit to copying the first assignment. You'll get an 1.0 score on that, and at the end of the course you'll have to do a "live assignment" in the computer lab with the prof perched at your shoulder to prove that you learned something in this class.".
Almost all the identified cheaters turned in, and a hefty quantity of unidentified cheaters turned themselves in, and even some people turned themselves in for the #2 assignment!
Another funny one, at the final examn of a course, when I (I was TA) said "ID will be requested while the test is in course, please place your University Card in your table next to you". I had just finished saying this when I saw one of the students jump out the window (it was a 2 meter drop to the grass outside). Never figured out who he was subbing for. (Whoever he was, he failed the class, since we customarily let the students who have an average such that an 1.0 in the final will still give them a passing grade keep their average and skip the final)
Isn't this article a bit like the classic, How to Write Unmaintainable Code?
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
I'm guessing you do a lot of debugging.
why do that when you can work effectively drunk?
As long as you have someone to drive you around, of course.
Do they still teach assembly language to CS majors?
I was doing some PIC microcontoller programming recently and was remembering indirect addressing and thinking "jeeze, I haven't thought about that since college, where they were teaching us the assembly language of the PDP/11."
It's a funny read for experienced coders, but to the newbies who actually do some of these mistakes, I find that the whole sarcastic angle to the article would just go over a newbie's head without them really understanding what's sarcasm and what is not.
I had a graphics program I had written that inverted color channels every once in a while for no reason I could identify- specifically, red and blue would get swapped, green would stay the same. The problem eventually turned out to be with the following function call: foreach(pixel) { putpixel(x,y,arr[n++],arr[n++],arr[n++]); } arr was an array with r,g,b data for all of the pixels on the screen. As you may have guessed by now, for each iteration through the for statement, because the compiler pushed function parameters onto the stack in reverse order, the final arr[n++] was evaluated before the first one, so r,g,b were pushed on by the caller and r,g,b was popped in the callee, swapping r and b. The bugs I love (and sometimes hate) are the ones that make you think a bit about what's actually happening. The other ones that come to mind are having a C++ function of a non-instantiated class work without complaint (it was a small method that turned out not to rely on any data in the class, so it didn't matter that the this pointer was filled with garbage), and a story I recall about someone having a problem in an old Fortran program where they had set 4 equal to 2 at some point in the program, and every 4 after that was interpreted as a 2...
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.
When I code at the computer, I tend to work in clumps, making this work, then that, then the other, and it works, but it's ugly and I get stuck in the minutia rather than the big picture. When I print out the code and think through it, I tend to work out what I don't even need and what would make it all more elegant.
This is good advice. I'll get stressed out during some assignments, mix up a cocktail and continue coding. I make really good progress and then hit some magic point where I just don't care.
On one particular assignment, Aaron and I turned in exactly the same code. I mean, down to the indenting and variable names ("numberOfCallers", "totalWaitTime", things like that). What probably saved us was the fact that we turned in our hardcopy program listings at about the same time, compared homework to see how we'd each approached the problem, and got completely shocked and flustered when we realized that we were probably getting ready to fail the course for plagiarism.
Fortunately, our teacher knew us well enough to believe our hasty and obviously on-the-spot explanation and let it slide. If we'd been freshmen who didn't know our professors, or if we hadn't caught the problem ourselves before the teacher found it, I'd probably be posting this to Fark from my Assistant Manager's cubicle instead of Slashdot from my Senior Programmer's office.
Dewey, what part of this looks like authorities should be involved?
"Absorb what is useful, Discard what is not, Add what is uniquely your own" -- Bruce Lee
He probably took five minutes to download the code from the internet, then passed out...
Yeah, well if the college actually followed through and expelled plagiarists maybe people would think twice before doing it?
Over half of my networked operating systems class was caught cheating on a machine problem (write a UNIX shell with job control and I/O redirection). The professor announced this during class and said whomever came forward wouldn't face any punishment. The college handbook clearly says that this is an offense that may result in explusion from the University. What happened? Not only did the University not expell any of these students, the professor wouldn't point them out in class so the rest of us knew who they were.
During an exam for a linear algebra class, I saw students pulling crib sheets out of their backpacks and placing them between their feet during the exam. Surely the proctor saw this (~35 students in the class), but nothing was done.
If colleges want to cut down on cheating, they need to start enforcing their own policies.
What about doing a hypercard implementation of Daleks while on LSD? Does that count?
In the spirit of the original article, recycling isn't just for Mountain Dew cans! Try to reduce consumption by reusing names of variables as often as possible. Sometimes you can even use the same names for global variables, local variables, and parameters! Confusion shouldn't be a problem, since scope is obvious to a good programmer.
Actually, really good bud can do that to girls. I've seen a couple get all loopy and not know where they are after smoking a couple of bowls.
Actually, really good bud can do that to girls. I've seen a couple get all loopy and not know where they are after smoking a couple of bowls.
Uh dude... they're just pretending. They're acting like that because they want you to fuck them.
Lots of us figured out the concept of a pointer about 20 seconds after it was introduced to us, but still I constantly see people struggling with simple things like linked lists, segfaults, null pointers, malloc(), free(), sizeof(), and such thinking that it's a syntax problem. No! Just understand the difference between a variable and the address where that variable is stored, and know where to use each one and then your problems will vanish!
I used to get stoned every day at work and would code like a madman. Of course, it was just Cold Fusion.
Some parts of scripting/programming may be exciting, but a lot of it is pretty dull and mind-numbing. That kind of work is always more tolerable high.
I clicked on Mavaddat's "Publications" link. Apparently he doesn't have any...
Ah, yes, the war stories...
I once worked with a guy who spent several days trying to solve a difficult coding problem, and wasn't getting anywhere with it. Then, he injured his back doing yard work and came to work high on painkillers. He coded up a working solution to the problem. Days later, he looked at it again and couldn't figure it out. He ended up putting in a comment, something like "I don't understand this, I was on drugs when I wrote it, but it works: DON'T MESS WITH IT."
If you are not an Indian in India change your major.
Otherwise fixing slurpie machines at 7-11 may be your ultimate career goal when your done.
http://saveie6.com/
Well yeah. Of course. That's the nature of the universe. The only sure way to find a piece of information is to give up all hope of ever finding it. :-)
I've tried using pragma warning(disable:4786) many times with no luck (It has no effect, even as the first line of stdafx.h). I'll try this "long static" approach when I'm back in the office. Thanks!
That explains the state of design specs and documentation, now doesn't it?
Most of my best comments were written as a result of alcohol... I liked to think seeing: //Drunk. fix later.
would cheer up those poor TA's miserable lives.
Writing good comments is a skill or possibly a set of related skills. One of the things that good comments can do for you is help you find things. They should work with your tools. Putting the right words into your comments so that you can find them when you tell your editor to search for them is invaluable. That's why I correct misspellings in comments. I'm going to search for some of those words some day, and I intend to spell them correctly.
If you've ever worked with code that has gone through several revisions, you know that what things are called in the docs and the GUI is not always what they were originally called when the code was first written. Either change the names in the code, or at least put in a comment that explains the mapping. It will help to preserve your sanity.
Use some kind of version control. If you have nothing else, store old versions somewhere. Better still, install CVS. Figuring out what you changed and why it worked is going to be at least partly a guess if you don't.
One of the best projects I had as a student was one where the professor required us to subject a prototype after a week. He responded to the prototypes with a few small changes to the requirements. He had warned us that that was the intent of the exercise and that we should make the code maintainable.
The net will not be what we demand, but what we make it. Build it well.
It was the Pot fairy. It does things like this from time to time. Like when it knocked up Mary in the bible.
Hear, hear!
I'm someone who deals with optimized code all the time, and for good reason. When you're programming an embedded system and you're trying to tweak every last penny out of it, you're in a different world than the "throw a faster Pentium at it" crowd.
Personally, I prefer mnemonic variable names that aren't terribly long, and fairly uniform in length. I find that the physical layout of the code communicates as much or to me than verbose variable names.
It's much easier to look for i, j and k as loop iterators too, than "arrayIndex." It lets me skip the carrier and get to the signal. IDIOMS ARE YOUR FRIENDS!
Anyone else find it ironic that mathmeticians make their language as terse as possible, whereas computer science (which is really applied discrete math in most cases) wants us to be as verbose as possible. Maybe more people would find math more approachable if it were a little more verbose.
--JoeProgram Intellivision!
It's too bad Diebold didn't read this before launching electronic voting machines in Florida.
Coding Style
//increment i
One thing I've noticed, well at least the university I went to (Arizona State - ok I've heard all the jibes), is that there is not as much emphasis on coding style as there is in just getting the assignment done. This article is essentially talking about the bad habits that students develop, and mostly this is due to insufficient emphasis on good coding style. I had been writing code for almost five or six years before I started college, so it was second nature to me. However, some of the people I met hadn't written a single line of code in their life. They were genuinely interested in CS (but there were some who were in it just because "CS people make a lot of money"). Most first year programming classes that I know of, just give you to tools to the language without telling you how to use it well. It's like you know English, but does that mean you can write a really good Story, or an Essay that is grammatically correct all the way? No, it takes training - and that is what I think some of these first year classes fail to provide. Sure, later on in your CS/CSE degree you may come across a professor/class that emphasizes good coding style, but by then some of these bad habits may be so ingrained. Like for example, I have seen C programs without ANY indentation. How terrible is that? Whitespace is awesome - use it liberally.
I was lucky enough to have a good professor my first year in college. I rememember that he eschewed the use of "goto's" (ok I have heard enough debates on this). His reason was that many students simply did not know how to use them right, leading to the inevitable spaghetti code. Also since we were using Java, it wasn't possible anyway.
Anyway, my point on Coding Style is that first year classes should emphasize that point so that students can learn to write programs that are easy to debug and document.
Proper Specs, Writing Algorithms, Documentation, and Knowing what your code does
I can't even begin to say how important this is. The major problems (some) Engineers have is that they write terrible comments, or none at all, or cryptic ones. I have come back to code that I wrote months ago and I have had a hard time deciphering what it is that I wrote. Documentation may seem like a pain, but in reality it makes the maintenance of your code more effective. Also, in an industry setting if someone else has to come along and look at your code, it makes it easier for them. How many times have you had to go over someone else's code and found no comments, or terribly obvious ones like:
i++;
I took an assembly language class in my sophomore year, and another one in my junior year - they were required courses. The prof in the first class was a former student of the prof in the second class, so they had the exact same methods. They had three main emphasis points:
1) Algorithm
2) Program Size
3) Documentation
Both these professors gave our excellent specs on our assignment (something more professors should do). They were extremely detailed and they exactly told us what was expected. In addition to this, they graded on program size and execution time. This prompted (most of) us to create efficient algorithms. I have to say that usually I'd just jump into the code and start coding, with a hazy algorithm in my mind. This time, I really had to sit down and come up with an algorithm. I discovered that it made my coding process much easier. It's better looking at your algorithm in paper and the comparing it to your code than doing it in your head. Their final emphasis was on documentation. 20% of the points for a lab assignment was for documentation. We had to provide an introduction/user's guide for the program. By reading it, any person should know WHAT the program does. Secondly, we had to provide an internal overview. This is esesentially the description of the algorithm that we use. Any person, by reading the internal overview, should have a good idea o
Vivin Suresh Paliath
http://vivin.net
I like
OK, this article pushed a couple of my hot buttons since I get to see the results of the "good" schools during interviews almost every week (and if you're willing to live in San Antonio and know Hibernate, go ahead and email me).
First, because of all the concern about "cheating" I often spend weeks getting recent graduates to work on teams. The idea that sharing and collaborating on code is "OK" is so foreign to them, that I get people who won't show their work to anyone.
Next, because they have learned that the instructor "has the answer", they will come up to me and ask me how to solve the problem I asked them to work on several days ago. I work at a research institute, and if I knew the answers I wouldn't have bothered asking in the first place. I can help you figure out ways to find the answers, and suggest sites to look for examples of code that might solve similar problems to use as a guide (oh, but there's that cheating problem again), but if I have to figure out the answer for you, then why am I paying you a salary in the first place?
Finally, and I think I've seen this a few times in this discussion already, there's people skills. No program seems to bother to teach folks how to talk in front of a group, and if they do it's to tell them how to cover their Powerpoint slides. Folks, if I can read (and I wouldn't be where I was otherwise), I don't need you to recite your slides. I need you to tell me what you couldn't put on them, or to expand upon the couple bullets you have on each.
Sorry, but when I see how what people learn in school makes them start out on the wrong foot in the "real" world, it does get a little upsetting.
No way. The first time I wrote decent linked list code was the same night I got drunk for the first time.
I eventually moved on to running another team in another part of the company - who were prepared to listen ...
I guess all the companies I've worked for are bad companies. I end up being the only one who complains about people checking in changes that break a compile, or don't run, or generate a crapload of warnings, or don't document... etc. I thought that type of attitude (theirs not mine) was standard at all places.
Can I get a job in your group?
That article was a complete waste of my time. It was neither insightful nor humorous. Somebody owes me 2 minutes of life.
Most plumbers, electricians and carpenters are not capable of running a business because they lack the organisational and IT skills that are needed nowadays.
Nice subtle dig at manual laborers. Most carpenters, etc., run their own businesses, and do quite well, so I'm not sure where your observation comes from. You don't need IT to run a carpentry shop or install some pipes.
If you are capable of doing comp sci and becoming a plumber, you could end up running Kohler...well, I exaggerate a bit
You exaggerate a lot. Big companies no longer use people familiar with the market for management. They use managers with MBAs. The days of coming up from the mail room to the board room are gone.
I don't know what it is with everyone and comments!
If you write code that is well written and structured, the amount of comments needed is very low as the code is self-documenting.
Ofcourse comments as to how to use a function should always be there, even if the function name gives a clear understanding of what it needs to do.
In my opinion, comments aren't needed when the code is clear and structured. It's much better than having cryptic logic, and stupid comments since then neither the code is readable nor are the comments really explaining it.
More likely than not, someone who can't write at least half-decent code, also won't be able to write good comments, as the programmer's logic might be clear to him and so will his comments be in that way of thought, but other programmers won't understand either.
^_^
is the way to go!
At least in small quantities... it gets a little tricky when your screen is melting...
This method works even better for humanities papers...
Right, he never found any bugs in the code. Just features.
Actually, it happens to some of us. Everytime I tried pot, the following 3-6 hours was a total blank. Friends would tell outrageous stories of the the stupid things I had done and said, but I remembered none of it.
Naturally, since I couldn't remember having enjoyed myself or not, I gave up on the idea of smoking pot after the three tries.
"A friend of mine" ---> the usual excuse when I need to tell a funny story but I feel too embarrased to accept it :)
Yah, that's fine, and that's what I do - I didnt go into enough detail. First, I write the code that will utilize methods that dont exist. Then, I write the classes and create dummy methods, that dont do anything yet, but have comments describing their purpose. I usually dont do the return statement though, because there's usually quite a while before. The basic point of my original post was that this apporach is very useful if you know some basics. Adding in return statements is fine and dandy if thats what you want. :)
Joseph?
First off thank you for taking the time to reply to my post. Awesome detail - not something I'm used to on these forums.
...if you're working in a group where each developer gets to choose their own editor...
... ... // end-catch // end-synchronized // end-if
Every project I work on mandates the use of a consistent toolset with consistent parameters (I've been repremanded for using tabs before). The purpose of this goes way beyond this particular subject. I believe strongly in the enforcement of this as I've seen it work very well. On the other hand, I appreciate that distributed projects without central management (eg. many OSS projects) do not have this luxury. I would maybe reconsider if I was in this position.
This is very easily mitigated through the mechanism I've already demonstrated:
if(i<50) {
synchronized(this) {
try {
} catch (Exception e) {
}
}
}
end-if? - Which "if" am I ending? I still need to scroll up to figure out which "if" statement I'm looking at. All this comment tells me is that this close brace _might_ be the close to _some_ if statement. The reason that I say "might" is because that comment can go out-of-date accidentally and confuse me even more (for example, the "if" is changed to a "for" but the ending brace comment is never changed).
It all comes down to my philosophy that tools should be helping us solve these problems. If the tools that are being used are inadequate (vi, pico, notepad, etc...), that does not mean that we should invent ways to clutter (IMHO) our code, it means that we need better tools. Again, VS.NET takes care of spacing braces properly even accross different tab or no tab settings (it reformats to the local settings). I can't believe that it's the only tool that does this. And even if I'm incorrect about VS.NET's "close brace info" feature, doesn't that sound like a better solution than a vague and potentially inaccurate comment? Maybe the OSS tools that we're using should consider this feature. I'd rather spend my time improving the tools in this regard, and especially with the OSS tools we have the opportunity to directly make these improvements. And again there are many reasons, this issue being one of many, why a consistent toolset for a development team should be required. If a developer on a non-commercial OSS project wants to read the code nicely, they can still choose to use the tools that make it easier.
Thanks again for conversation. This is a fairly subjective topic but I'm sure you agree that it's important to think about and discuss different opinions as it affects code quality and ease of maintainability.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
This article basically seems to be the motto of most developers at Microsoft. They barely grasp the fundamentals of programming, so why bother with anything else? They just assume more code will solve their problems, or that they will just go away on their own.
At the University of Newcastle(in Australia) where I was a tutor for a 2nd year Web Engineering course (using JSP), the students didn't have too much experience with Exceptions (in their Javabeans) and hated the way the exceptions always stopped the execution.
So my addition to the ironic programming advice would be: Can't get rid of those damn annoying exceptions? Just put "try catch" blocks around ALL your code and either just have a basic console print statement in the catch area such as System.out.println("error"); OR to be even more professional, have NOTHING in the catch area! This way your console wont be filled with unprofessional error messages AND you wont have to deal with those annoying exceptions anymore!
Then when your program seems to be acting REALLY bizarre, first hack away at it to the point where it will in fact do something that resembles a half working state, then throw it to your tutor and ask him to fix it. Finally sit back and watch as he pulls his hair out discovering the myriad of exceptions being generated and ignored left right and centre...
Yet to this day, i still work with people who should know better then to put try catches around EVERYTHING and then have absolutely MEANINGLESS catch code that actually gives less information and achieves less then actually just letting the exception go uncaught and bubble up to the screen or console!
Classic line people tell me when looking at my code: "Why on earth are you purposefully throwing an exception?? What could that possibly achieve??!!" - having no idea that i'm actually catching it in a carefully planned area.
Make the f^&$ers take an HDL course and learn verilog
No he didn't. He liked to flout spelling rules. To flaunt spelling rules, he would have to adhere to them meticulously and conspicuously, because flaunt means a gratuitous display of something - for example, driving a fancy car in Harlem is flaunting your wealth, or wearing snug yellow spandex over impressive cleavage flaunts another kind of asset.
I live in the US and work in a lab on a daily basis. That means I use both Fahrenheit and Celsius (or Centigrade) on a daily basis. That means if I write a temperature in my lab notebook, I'd damned well better note what units I mean. The fridge is 4 C, but if I left off the "C" then someone looking at my notebook in the future might store a reagent at 4 F, which would be a big problem if the reagent didn't tolerate freeze-thaws. That's not even considering the absolute temperatures (Kelvin and Rankine) which are especially important in chemistry and physics.
And seeing as how everywhere outside of the US uses Celsius, but a very large percentage of native English speakers use only Fahrenheit, it would indeed make sense for someone translating the article into English to specify what kind of degrees they were talking about. Would you say that someone weighs 15? What would that mean? It's an acceptable weight for an infant, in pounds, but in the UK they still use stone to specify weight (which does mystify me).
The parent poster obvious was able to infer that the article meant Celsius from the context. Sounds like you're the one who doesn't understand this is a diverse planet.
Si la vida me da palo, yo la voy a soportar Si la vida me da palo, yo la voy a espabilar
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" Thank you. Now I know never to hire you. That's not called "Research" that's called stealing. Taking someone else's copyrighted code and passing it off as your own is stealing. Not only can you lose your job over that, you can get your company sued for millions and millions of dollars. Cheating in college should always result in immediate explusion otherwise you get people in the real world who think this sort of thing is ok.
That is FANTASTIC! Feel free to TA at Leander any time. High school students can't sue for much....
Graham "Teach" Mitchell, computer science teacher, Leander HS
pay someone on rentacoder.com or elance.com to do it.. Like this dude does.
I guess you invented all your crypto and wrote your own libc ?. Reading a reference implementation is MANDATORY for doing most of the things I do . I've read a lot of os-specific code and often there are no two ways to do it either. (yeah , like reading pySerial and redoing it in C is copyright violation).
What all this gave me in college is a skill at understanding code I never wrote and debugging it. It turns out that I do the SAME THING AT WORK - DEBUG SOMEONE ELSE's BUGGY CODE !!!
Quidquid latine dictum sit, altum videtur
I guess you invented all your crypto and wrote your own libc? No, I've used libraries that I have the legal right to use provided I use the publicly documented interfaces and/or abide by the copyright restrictions. Reading a reference implementation is MANDATORY for doing most of the things I do. Reference implementations are often in the public domain. They always are licensed in such a way that you can use the code in your own application. (yeah , like reading pySerial and redoing it in C is copyright violation). Actually, it can be. If you took pySerial and rewrote it in C, then your creation is a derivative work. If it's a derivative work, it's a copyright violation. What all this gave me in college is a skill at understanding code I never wrote and debugging it. No, it simply taught you how to steal. You can learn to understand code by participating in Open Source projects or by working on programming project teams. Pair programming seems to be all the rage these days in Universities so I contend that there are plenty of opportunities to pick up these skills without resorting to stealing.
The Brownies were at work.. definitely Brownies.
Lost in space at an early age. Survived the vacuum. Now rebuilding castle in air.
And sadly, a proper OOG post is no longer even possible, since the 'lameness filter' doesn't allow all-caps posts.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Imagine a collection of dipoles in a magnetic field, with two energy levels. The maximum entropy occurs when there is enough energy for half of them to be high. If you manage to get more than half of them high (by suddenly flipping the magnetic field), the temperature is negative, because an increase in the energy leads to a decrease in the entropy (and T = DE/DS).
Of course I could just be smoking crack. Who knows?
It's not wasting time, I'm educating myself.
Also, how many comp sci graduates start in the mailroom? I submit that, other things being equal, a graduate with practical skills in the industry will have the edge over a new graduate joining the same industry but without those skills. At the moment we have a division of labor which means that even management is over specialised. What makes you think that fashion will last through the next ten or twenty years, when today's new graduates will be reaching senior levels?
Eventually the lessons of Barings and Enron will filter through. As usual, it will be by new companies springing up with diferent business models.
Panurge has posted for the last time. Thanks for the positive moderations.
I'm a CIS student, about ready to graduate. I'd already been programming for several years before I started school
Can you actually get a job with a CIS degree? I work full time as a programmer and I went back to school to finish my degree, and I'm trying to decide between Computer Science and CIS as my major. Even though CS will take much longer for me, I took that. I'm tempted to switch to CIS since my previous credits would count more twards that degree. Would I actually get a job with a CIS degree though? It seems like every ad I see says "BS Degree in Computer Science required" which scared me away from the BA in CS and CIS degree