Programming Style

What do I mean by "programming style?" It's more than comments -- it's the approach you take when you are writing software. When I sit down to create some code, I put the various goals in an order: from most important to least important,

you can understand what it does: If you don't know what you are writing, there's not much chance that you can fix any mistakes you're making.
you will understand what it does two years from now: It's surprising how frequently you will find yourself being asked to perform the same sort of analysis as you make your way through a career: whether it's Fourier analysis, or Monte Carlo simulations, or fitting a gaussian to some measurements, you'll often wish you could re-use some program instead of starting from scratch.
someone else can understand it: Most scientific projects employ more than a single person, don't they? Wouldn't it be nice if you could share your programs with fellow students and colleagues? Wouldn't it be EXTRA nice if you didn't have to spend hours with them trying to explain why they keep getting the wrong answers?
it does the right thing: Sure, this is important. But this goal can be met EVENTUALLY, after you've tested it on a large number of cases. If you don't understand how it works, neither you nor anyone else will be able to track down and fix that one little remaining error.
In addition, there will be times when you want to change subjects slightly and do a slightly different analysis on some dataset. If you have a well-structured program that reads the data, does a similar calculation, and then produces output in the proper format, you can re-use portions of the old program and save yourself some time. So, you might throw away the tricky calculation portion of the code, and just keep the bookkeeping sections.
it's fast or efficient: It's very easy to spend hours and hours trying to make your program run faster. In the great majority of cases, it won't matter. You can always wait a year or so and purchase faster hardware, anyway. Focusing on unnecessary optimization has perhaps wasted more scientific time and effort than any other mistake.

Here is a summary of the very important programming style tips from Brian Kernighan's 1994 guest CS50 lecture.

Say what you mean, simply and directly.
Use the ``telephone test'' for readability.
Write clearly - don't be too clever.
Don't use conditional expressions as a substitute for a logical expression.
Parenthesize to avoid ambiguity.
Each time you make a test, do something.
Follow each decision as closely as possible with its associated action.
Use the good features of a language; avoid the bad ones.
Capture regularity in control flow, irregularity in data.
Each module should do one thing well.
Make sure comments and code agree.
Don't just echo the code with comments - make every comment count.
Don't comment bad code - rewrite it.
Use symbolic constants for magic numbers.
Watch out for side effects and order of evaluation.
Macros are not functions.
Watch out for off-by-one errors.
Test programs at their boundaries.
Program defensively.
Make sure input cannot violate the limits of the program.
Make it right before you make it faster.
Keep it right when you make it faster.
Don't sacrifice clarity for small gains in ``efficiency.''
Don't stop with your first draft.

[From The Elements of Programming Style, Kernighan & Plauger, McGraw-Hill, 1978]

Let me add a few suggestions of my own:

As you write a program, imagine yourself coming back to work on it again three years from now. Make sure that your future self will understand it.
In most cases, efficiency is MUCH less important than clarity. Computers get faster every year, but people don't get any smarter.

Some examples for you to ponder:

Examples of Good and Bad Function Descriptions
A function to convert rectangular to polar coordinates:
- written poorly
- written well

Some suggested references -- not specific to MATLAB

Documenting functions
Bomb-proof programming; read the first few screensful of introductory material

Some suggested books:

Elements of Programming Style, by Kernighan and Plauger.
Programming Pearls and More Programming Pearls: Confessions of a coder, by Jon Bently.
Code Complete, by Steve McConnell.
Writing Solid Code, by Steve Maguire.