Digg

Discover the best of the web!
Learn more about Digg by taking the tour.

Seven Secrets of Successful Programmers

irishdev.com — Nice quick list of seven good programming practices.

Bury

netmancer 2 years 174 days ago, made popular 2 years 174 days ago

919 diggs
digg it

nfollmer, on 10/12/2007, -0/+0good read
matx, on 10/12/2007, -0/+0I would imaging all good programmers already know this, if not, they better start doing it now!
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...
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.
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!
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.
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.
foolio, 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
CrankyPants, 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.
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!
Animal, on 10/12/2007, -0/+2Whenever someone tells me to expect the unexpected. I want to kill.
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. :)
Boris008, on 10/12/2007, -0/+0Shhhh.....these are "secrets"...mums the word!
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.
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.
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. :)
cmdrNacho, on 10/12/2007, -0/+0these are good tips .. but things you should know before even beginning
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 :-/
CrankyPants, 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.
TomPTraynor, on 10/12/2007, -0/+0Not a bad start. One other thing to keep in mind is that a module does one and only one job.

I have to maintain code that breaks almost every rule in the book. I remember one module that reads data, manipulates that data, spits it out into an internal file for an internal sort, reads the result of that file and then manipulates it more before spitting out data for other programs. Those other programs manipulate that data and then feed it back into the same program, but, with a flag to trigger another database read, manipulate, sort, read, manipulate and then report. We know the input and the ultimate output, but, no one can figure out how the results are generated.

Another good practice is to put a short description at the top of the program describing what it is doing, required inputs, optional inputs, and the outputs generated along with any special processing rules.
phage434, on 10/12/2007, -0/+0The thing that needs the comments is the data structure created and maintained by your program, not the program. Comment the arrangement of the data, and the consistency requirements on it. Make the program action on the data structures evident in the code.
heifetz, on 10/12/2007, -0/+0This is seven tips for programming n00bs
gnuvince, on 10/12/2007, -0/+3Any story that suggests programmer use Hungarian notation is a Bad Article (tm) in my book.
peerk, on 10/12/2007, -0/+0These are common sense tips that bad programmers are aware of.

It should have one simple rule: "DON'T BE LAZY!"

What's next? Secret tips on how to walk?

"Rule 1) Don't jaywalk, you may get hit by a car!"

How about walking a few more steps until a traffic signal ya freaking lard ass.
MikeCampo, on 10/12/2007, -0/+0Umm if you are a programmer then you would already know this...unless you are retarded.
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.
Berkana, on 10/12/2007, -0/+0Here's what I notice about most of the articles labled as "secrets" of masters: the "secrets" are not secret, and they are not the material of the masters. Rather, they are fundamentals, and they should be learned to competency by beginners.

This article lists fundamentals of complexity management for coding. The same thing goes for almost every "secrets" list I've seen in magazines and articles everywhere. If everyone would simply stop calling them "secrets" and calling them "fundamentals", perhaps people would take a better attitude toward mastering them. Or, perhaps they have to be called "secrets" for people to take them seriously to begin with. If this is so, this is sad.
Berkana, on 10/12/2007, -0/+0@emostar,

optimization is often done by compilers nowadays. In a different sense, coding by the recomendations given in that article do give you optimized code: optimized for maintenence, teamwork, clarity, and debugging.

If you're programming with a team, and in any language but assembler or C using low-level operations, giving priority to clarity is better than coding as if the only thing that will consume your code is the machine. (And before anyone misconstrues me, don't confuse picking bad algorithms or sub-optimal solutions with coding in an hard-to-read manner. Picking cryptic variable names and coding in a manner that takes no consideration for other people doesn't make the code run appreciably faster if at all in all cases that I've ever come across, certainly not enough to outweigh the drawbacks of coding that way.)
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.
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.
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.
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.
Chaos12, on 10/12/2007, -0/+0It forgot..... #8 keep your source code on a non-networked server
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.
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.
pinoyboy82, on 10/12/2007, -0/+0try programming some scheme/lisp with/without comments... confusing ANYWAYS!!
thuss, on 10/12/2007, -0/+0No digg... how can you have the top development hints and not include test driven development!
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!!!!!!!!
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.
v3xt0r, on 10/12/2007, -0/+0There is far more to it than that, but I'll digg it because it's Irish! =)
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?
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...
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
CantDiggIt, on 10/12/2007, -0/+0Wow I didn't think it would make it to Digg, useful comments. Thanks - Jo, Irishdev
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.
mgrace74, on 10/12/2007, -0/+0Short and right to the point. Thanks!
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.
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/
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.
jeromehorwitz, on 10/12/2007, -0/+0Completely useless. Anyone that doesn't already know that isn't a programmer.
Show 51 - 58 of 58 discussions
Login or register to add a comment

Create a new account or login to join in the conversation on Digg. You'll also be able to Digg stories to help promote things you like.

Seven Secrets of Successful Programmers

Login or register to add a comment