What is Digg?Sponsored by newegg
Ready. Set. Shop view!
newegg.com - Newegg.com Black Friday Sale starting 11/25 3PM PST. No Lines, No Crowds, Click and Save.
58 Comments
- bitshifter, on 10/12/2007, -3/+6Good lord.
Such an old, tired, cliche set of opinions.
Nothing new, move along. Just another newbie coder trying to get to the top of digg by posting beginner coding articles. - gnuvince, on 10/12/2007, -0/+3Any story that suggests programmer use Hungarian notation is a Bad Article (tm) in my book.
- Animal, on 10/12/2007, -0/+2Whenever someone tells me to expect the unexpected. I want to kill.
- chicken101, on 10/12/2007, -0/+2Basic stuff. It just tells you not to write ***** code.
1) Make in manageable
2) Debug it
3) And most importantly, think about your program before you start to type! - ColdDimSum, on 10/12/2007, -0/+2*agrees with gnuvince* Hungarian notation is a blight on the programming world. Properly written code doesn't need it.
Here are my seven tips, some restate similar ideas in a slightly different way of course:
#1 revere simplicity, big programs are not impressive, small, functional, testable, programs are.
#2 use a thesaurus, function and variable names are important.
#3 whenever you see a compound function or variable name it's time to refactor, e.g., 'LoadRecord'
#4 comment WHY, well-written code should say WHAT. In the linked page they have a 'good' example of "Disable button to prevent its activation", a better example might be:
submit->disable(); // form is processing in the background
or maybe
submit->disable();
while (! form->processing(COMPLETED)) { spinner->update(); }
#5 refactor relentlessly, in the old days we called this 'throw the first one away' - but in the real world you rarely get to do that. Refactor is neuvo-speak for throw it away continuously.
#6 Interact with your program continuously as you develop it. Don't code for four days and then try to debug 1000 lines of code; instead code, test, debug, and interact in a constant cycle. Make your code do something observable and verifiable at every step. I've been programming for 25 years and I can tell you that when I use an interactive language I'm easily twice as productive. Don't rely on the debugger either, it's a hideously painful way to understand what your program is up to.
Corollary, if it's taking more than a few seconds to recompile and test your program then fix your development environment and/or code.
#7 Take breaks... study a problem really hard, then step back from it for a bit before you start coding. Play a mindless game or daydream for a bit. - tonicboy, on 10/12/2007, -0/+1*sigh* Why do people digg junk like this? Not only is it marginally useful, but anyone looking for this type of information can easily find 10,000 such lists at the click of a Google. Does not belong on Digg.
JUST SAY NO TO DIGG SPAM!!!!!!!! - emostar, on 10/12/2007, -0/+1If all programmers follow #1 we will have programs that are slow as hell and won't be optimized.. this list really doesn't say anything worthwhile. Only to an inexperienced programmer, they will think these are good things to follow.
- CaughtThinking, on 10/12/2007, -0/+1Seven Secrets of Successful Writers
1. Learn how to spell.
2. Use a dictionary.
3. Paragraphs, paragraphs, paragraphs!
4. Thesauruses are great too!
5. Read your sentences at least twice
6. Consider a notebook for writing in!
7. Use a word processor!
DIGG DIGG DIGG
DIGG DIGG DIGG
DIGG DIGG DIGG
DIGG DIGG DIGG
DIGG DIGG DIGG
DIGG DIGG DIGG
reporting this story as lame. - eastshores, on 10/12/2007, -0/+1I just started working for the first time as a contractor for a company who had several teams develop their in house desktop buisiness software.. so in many ways this is the first time in 8.5 years that I have inherited a very large code base. These 7 things, while some say are newbie fodder.. read all seven, and go back and read them again, this time ask yourself to be honest about whether you are doing that to the best of your ability.
Many programmers move past these foundational practices and grow into heavy use of reflection, design patterns, etc. but leave a complex codebase that will take much time and money to transition. - Ofaniel, on 10/12/2007, -0/+1"Good lord. Such an old, tired, cliche set of opinions. Nothing new, move along. Just another newbie coder trying to get to the top of digg by posting beginner coding articles."
I guess we tend to forget that some of us were born with coding skills...bitshifter, I recognize that you have the right to your opinion, but this is important information for an aspiring coder.
My nephew is 7 and I have started to teach him VB while gradually working in habits as discussed in this article. I hope that this "newbie" finds passion in what he is learning.
Sorry for the direct attack. I just feel strongly about making sure the next generation makes an attempt at getting it right. :) - inactive, on 10/12/2007, -0/+1"Comment often and comment well"
A bit contradictory to #1 (code for human consumption)
As Paul Graham (I think said) comments should be left only where necessary, and if you are commenting elsewhere, your code isn't readable enough.
/2p - Boris008, on 10/12/2007, -0/+0Shhhh.....these are "secrets"...mums the word!
- pjh3000, on 10/12/2007, -0/+0In college they taught us that "a good programmer is a lazy programmer".
It's always stuck with me. That's why I don't comment my code. :) - thezettabytes, on 10/12/2007, -1/+1bitshifter-:
"Good lord.
Such an old, tired, cliche set of opinions.
Nothing new, move along. Just another newbie coder trying to get to the top of digg by posting beginner coding articles."
NOT ALL THE PEOPLE WHO VISIT DIGG ARE ROFESSIONAL PROGRAMMERS, MOST OF THE PEOPLE COULD USE SUCH ARTICLES! - adolfojp, on 10/12/2007, -0/+0And for those of us who use more than one language on a daily basis:
Code in only one language.
I grow sick and tired of reading through pages and pages of Spanglish variables, methods, classes, tables, stored procedures...
Sorry for the rant. Off I go back to the code. - Chaos12, on 10/12/2007, -0/+0It forgot..... #8 keep your source code on a non-networked server
- inactive, on 10/12/2007, -0/+0I can't tell you how many lines of code my company has paid consultants for that ignore all 7 of these rules. This ***** can't be stated enough -- there are a lot of ignorant-ass retards out there pretending to be programmers who can't even spell "Comment" much less write one. Maybe if they read this enough times it'll sink in.
- Berkana, on 10/12/2007, -0/+0Here's a much better reading list of practices to avoid in coding:
http://en.wikipedia.org/wiki/Anti-pattern
If software developers would simply avoid these commonly-reinvented bad solutions to problems, much of the software problems we still see today would not exist. - Notluf, on 10/12/2007, -0/+0For a shell expert the following code might make sense and CAN be made smaller. It is only an example of "uncommented code", imagine a newb trying to follow this.
#!/bin/sh
if [ ! -d /mysql_backups ]
then
exit
fi
day=`date | awk '{print $2$3$6}'`
filename=$day.sql
if [ -f /mysql_backups/$filename.gz ]
then
filename=$day$$.sql
day1=$day$$
day=$day1
fi
day=`date | awk '{print $2$3$6}'`
filename=$day.sql
if [ -f /mysql_backups/$filename.gz ]
then
filename=$day$$.sql
day1=$day$$
day=$day1
fi
if [ ! -d /usr/local/mysql410/bin ]
then
exit
fi
/usr/local/mysql410/bin/mysqldump some-database-name --user=someuser --password=somepassword > /mysql_backups/$filename
....rest of script is making MySQL connects to a remote MySQL host and uploading the database with a unique name based on the timestamp from above if the database name already exists.
Same script below but with comments, it makes more sense, even to shell scripters in what I was trying to do. For those who know scripting at least they can follow my thought process and that would explain to them why I did what I did, even if I did it ass-backwards. It makes fixing something that somebody else did that much easier.
#!/bin/sh
#
# backupmysql.sh
# Author Name
# June 6, 2005
#
# switches: none
# run from/called by: command line or cron (intended for cron)
# dependencies: none
#
# Dump the *********** database from MySQL to a file
# with todays date as the filename. Create a new database
# with the same name (todays date) and upload that file
# to it. Connect to **********(remote server) and create a database with
# same filename and upload it.
# Zip the file to save disk space.
# =============================================================
#
#
# Check to see if the backup directory exists
#
if [ ! -d /mysql_backups ]
then
echo "Backup directory /mysql_backups does not exist. Fix this or change this script."
exit
fi
#
# Set variable for date to be used as the filename for the backup
day=`date | awk '{print $2$3$6}'`
filename=$day.sql
#
# Check to see if backup file already exists, if so, append process number to end of date to make unique
if [ -f /mysql_backups/$filename.gz ]
then
filename=$day$$.sql
day1=$day$$
day=$day1
fi
#
# Check to see if the Mysql 4.1.0 is installed at /usr/local/mysql410
#
if [ ! -d /usr/local/mysql410/bin ]
then
echo "Mysql ver. 4.1.0 does not appear to exist at /usr/local/mysql410. Fix this or change this script to point to new location."
exit
fi
#
# Dump ************ database to a file with todays date as the filename
/usr/local/mysql410/bin/mysqldump some-database-name --user=someuser --password=somepassword > /mysql_backups/$filename
....rest of script is making MySQL connects to a remote MySQL host and uploading the database with a unique name based on the timestamp from above.
Which is easier to follow? I think the version with comments is easier to follow for both camps. Could the above code (assuming it survives any filters in posting) be made bettter? Heck yeah, but that is not what I am aiming at here, I just wanted to provide a real world example of non-commented code versus commented code and which is easier to follow. - cmdrNacho, on 10/12/2007, -0/+0these are good tips .. but things you should know before even beginning
- inactive, on 10/12/2007, -0/+0"In college they taught us that "a good programmer is a lazy programmer".
It's always stuck with me. That's why I don't comment my code. :)"
They taught you the right thing but you learned the wrong lesson: A truely lazy programmer would recognize that proper commenting when what you are doing is fresh in your mind would make future refactoring easy. Without the comments or with the elusive "Self-documenting code" you will, in fact, make more work for yourself when you return to that method and have to figure out what you were doing. Worse yet is returning to an undocumented method and coming to the wrong conclusion about it's function -- now you're really up ***** creek. - laptopmafia, on 10/12/2007, -0/+0Goodness, this stuff is common sense people. I am not a professional programmer (nor do I want to be) as I have only taken 2 semesters of programming (in my third semester), but this stuff is still just the extreme basics. This doesn't belong anywhere but MAYBE in the first day of an introductory programming course.
- panique, on 10/12/2007, -0/+0@ 5blocksfree - Excellent point. Apparently this neophyte hasn't been working long enough to know that you can't trust comments. Whenever I look at code, I read the code, not the comments. Why? Because someone along the way more than likely changed how stuff works, and didn't change the comment.
When do I comment? When I'm doing something subtle that cannot be grasped by just reading the code, OR when it is really important, like documenting the misbehavior of a device my code interfaces too. - panique, on 10/12/2007, -0/+0Don't forget to brush and floss too. What a ***** lame ass list not even worthy to be printed in the introduction of a textbook. Anyone who needs a list like this has no ***** business whatsoever writing code.
- tracer999, on 10/12/2007, -0/+0"Most compilers will strip the comments from the executable program."
Most compilers? How about all compilers.
Not a very thought provoking list. - holybins, on 10/12/2007, -0/+0Teaching code to a 7yr old? That's pretty neat :)
But yet...they need to start teaching good coding practices in at least high school...I mean they don't even really do it in most colleges now! These students in college are so pumped when their code works first, but then you see they are somehow doing things with horrible, impossible manipulation of strings...when they were supposed to be designing their own classes! Horrible starts for so many...and nothing is said to them :-/ - teh_toaster, on 10/12/2007, -0/+0Thankfully, there are a lot of weedout classes to get rid of people that can't follow 7 simple rules.
Unfortunatly, more and more majors are requireing one programming classe be taken to graduate, (example: Education majors, Business, and Math). These people then think that they know how to program, they are sorely mistaken. - 5blocksfree, on 10/12/2007, -0/+0FTA: could someone understand what your program does if all but the comments were removed?
Another equailly interesting question: could someone understand what your program does if all the comments were removed? I think that code clarity is every bit as important as comments. There is no reason that code cannot be self-evident. - 0Troy, on 10/12/2007, -0/+0Most of this is common sense stuff you'd think everyone would do, but I've been on techrecipies... *shudder*
And I'm glad it wasn't just "COMMENT YOUR CRAP, DAMNIT!!!" seven times... - nfollmer, on 10/12/2007, -0/+0good read
- informatikon, on 10/12/2007, -0/+0Nice, common-sense list of advices. I wouldn't call them "secrets" though, for any other reason than making the front page in digg :-)
I have written a "Lessons from the Job" article (basically things I learned while working as a professional programmer for many years): http://beingaprogrammer.blogspot.com/2006/01/job-lessons.html - slack0re, on 10/12/2007, -0/+0notluf your a newb, go to a newb site :p or maybe i need to find a new site...
- slack0re, on 10/12/2007, -0/+0There are times when comments are important, but for the most part they are a waste of time
if you can't read code, your not a coder
what were the other 6 steps? - anirudhvr, on 10/12/2007, -0/+0/usr/src/linux/Documentation/CodingStyle - now that's an insightful, no-nonsense guide. but I guess these are required for newcomers, though the 'successful' part is a little exaggerated. i wish he'd have more points (as there should be) - like to get it working before optimizing, how important it is to keep testing each time you finish a module etc.
- thuss, on 10/12/2007, -0/+0No digg... how can you have the top development hints and not include test driven development!
- pinoyboy82, on 10/12/2007, -0/+0try programming some scheme/lisp with/without comments... confusing ANYWAYS!!
- v3xt0r, on 10/12/2007, -0/+0There is far more to it than that, but I'll digg it because it's Irish! =)
- CantDiggIt, on 10/12/2007, -0/+0Wow I didn't think it would make it to Digg, useful comments. Thanks - Jo, Irishdev
- zackarya, on 10/12/2007, -0/+0notluf gave a great example of why comments are important. It's not to reiterate the
code, it's to explain to someone else working on your code what your doing and why
your doing it. Personally I write code and a lot of the people I know write code. Every
single one of us use comments extensively. It's just how you do it.
Zack - mgrace74, on 10/12/2007, -0/+0Short and right to the point. Thanks!
- justsomeguy987, on 10/12/2007, -0/+0For a complete "how to program" reference, I recommend "Code Complete" by Steve McConnell.
- theearthling, on 10/12/2007, -0/+0What year is it? This is seriously dated. Sorry to be so negative, but there are only 2 good pieces of advice here, and not because they're not common knowledge, but because so many programmers don't follow them:
"Code for human consumption"
"Keep your functions and subroutines simple"
The rest is rubbish. Especially the one about code comments. If your code can't stand on its own, then you're not executing on the two points listed above. - jeromehorwitz, on 10/12/2007, -0/+0Completely useless. Anyone that doesn't already know that isn't a programmer.
- Zeuser, on 10/12/2007, -0/+0Straight out of a University handbook. Very basic stuff. And some of it is just wrong! After 15 years in the field I've discovered that while it all looks good on paper, in the real world it just doesn't make sense. Examples:
Code for clearity first. WRONG! While it's the ideal for the programmers, the programmer next to me isn't paying my salary; the customer is. And that customer wants ease of use and speed. Don't code for clarity first... code for the customer first.
Comment the code. Some commenting is good but I've seen programmers go way too far on commenting. To the point where there's more comment than useful code. The problem with that is the job has now taken twice the time to accomplish because the programmer over-commented.
And here's a hint from a seasoned pro: Don't do what this article says. That's the best way to shoot yourself in the foot. When they outsource your job, it'll be too easy for someone else to pick up. The more complexe and poorly documented the code is, the less likely an outsourced person will be able to handle it. The result? When said outsourcing company fails, your old employer will be giving you a call. That's when you can double your salary.
I'm speaking from experience here; I did that myself and it paid off.
The business world and the school world are two completly different animals. Learn how to exploit each for your own advantage. - theearthling, on 10/12/2007, -0/+0Arguably the #1 secret of successful programmers is:
"Write Unit Tests" -- Come as close as you can to 100% code coverage. - mtrutledge, on 10/12/2007, -0/+0I agree with theearthling. Unit Tests are my top priority when writing code. Still a good read though.
- alectec, on 10/12/2007, -0/+0Decent read but entirely common sense amoung moderate to experienced programmers. Don't use "a" and "b" as variable names, comment items that need clarification and so you can remember why you did something later.
- Battleman, on 10/12/2007, -0/+0sorry - 'past' not 'passed' - I wish they taught me to spell at uni :)
- Battleman, on 10/12/2007, -0/+0If you're after tried and true rules to program by, you can't got passed these maxims:
- from http://www.catb.org/~esr/writings/taoup/html/ch01s06.html - visit the link for further information.
1. Rule of Modularity: Write simple parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Composition: Design programs to be connected to other programs.
4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
8. Rule of Robustness: Robustness is the child of transparency and simplicity.
9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
10. Rule of Least Surprise: In interface design, always do the least surprising thing.
11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
16. Rule of Diversity: Distrust all claims for “one true way”.
17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.
These were tattooed into our souls at university - and we are better for it. - jeffreym, on 10/12/2007, -0/+0I always add comments. But I write comments that have nothing to do with the code.
http://celestial-reasoning.blogspot.com/ -
Show 51 - 58 of 58 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is