Sometimes, I wonder “WWFD?”
Here’s a collection of ideas and resources for scientific programming.

The best personal advice I can give you is : take your time to design (spending 10 minutes can save you a week).
Also, do not hesitate to spend time on thinking of how to visualize your data : it makes a huge difference, for you and for others !

For the rest, follow the list !

Coding best practice

1. Commenting & documentation (design and purpose, not mechanics)
   1. Consistent indentation (do not mix space and tabs)
   2. Avoid obvious comments
2. Consistent naming scheme (define it!)
   1. Minimize the use of abbreviations
   2. Consistent temporary names
   3. Avoid homonyms
   4. Pair antonym procedures (open/close, etc.)
3. Keep your code simple (The “20 lines” rule)
   1. Avoid deep nesting (hard to read)
   2. Limit line length (hard to read & viewer dependancy)
   3. File and folder organization
   4. Don’t repeat yourself
   5. Code refactoring
   6. Code grouping
   7. Use globals sparingly
4. Write programs for people, not computers
   1. Do you have testers/hallway usability testing?
   2. Provide useful error messages
5. Have a high level design or a low level design and Function specification and proof of concepts
   1. Push interface up and implementation down
      1. i.      Level 1 (high): accept user input
      2. ii.      Level 2: taint check and normalize user input, and check for errors
      3. iii.      Level 3: process user input according to business logic
      4. iv.      Level 4 (low): store data
6. Separation of code and data
   1. Wrap built-in functions and third-party library functions with your own wrapper functions
   2. Don’t assume output formats
   3. Internal data should be in native format
   4. Operate on objects, not data structure
7. Test returned status for error conditions
   1. Recover or fail “gracefully” : Robust programs should report an error message
8. “Premature optimization is the root of evil” (Optimize software only after it works correctly)
9. Never rewrite code from scratch

I found this list on the internet, less formal but still very interesting :

• Found on a wall in a mechanical engineering shop. But many of these dicta apply just as well to software engineering.
• Engineering is done with numbers. Analysis without numbers is, at best, only an opinion.
• Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.
• Everything is linear if plotted log-log with a fat magic marker.
• When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when real numbers come along.
• The odds are greatly against your being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, the chances are better that you’ve screwed up than that you’ve invented warp drive.
• At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.
• In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.
• Not having all the information you need is never a satisfactory excuse for not starting the analysis.
• Your best efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.
• Sometimes, the fastest way to get to the end is to throw everything out and start over.
• There is never a single right solution. But there are always multiple wrong ones.
• Design is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate.
• “Better” is the enemy of “good”.
• The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.
• The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.
• The fact that an analysis appears in print has no relationship to the likelihood of its being correct.
• Past experience is excellent for providing a reality check. On the other hand, too much reality can doom an otherwise worthwhile design.
• A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
• Half of everything you hear in a classroom is crap. Education is figuring out which half is which.
• When in doubt, document. Documentation requirements will reach a maximum shortly after the termination of the project.
• It’s called a “Work Breakdown Structure” because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.
• The first 90 percent of the project takes 90 percent of the allotted time. The last 10 percent of the project takes the other 90 percent.

Programming books :

For programming, I don’t have a particular reference, apart “The numerical recipes (in C)”  (pdf here) which is a reference if you want to find any particular type of algorithm (and that wouldn’t be otherwise coded in Matlab;-). If you want to learn how to code, you should look at the many tutorials arund the web. To learn C#, I liked “C# step by step». “The Art of Computer Programming” by D. Knuth is said to be a reference, but I haven’t read it yet. Instead, you can take a look at the very comprehensive Jeff Erickson’s Algorithm website, full of very interesting lessons (I love the one of FFTs;-)

It is not exactly programming, but I want to mention “Streetfighting Mathematics” (free) by Sanjoy Mahajan would tackle many mathematical problems, easing the implementation in a computer.

Signal processing books :

“Analyse et traitement des signaux : Méthodes et applications au son et à l’image” by E. Tisserand is a very nice book, with very good explanations and useful applications, while “Traitement numérique du signal” by M. Bellanger is boring and has few ready-made uses.

Talking about filters and Fourier, I really liked reading Roddier’s “Distributions et transformation de Fourier : à l’usage des physiciens et des ingénieurs” (hard to find), or Bracewell’s “Fourier Transform & Its Applications” (you can have a somewhat equivalent here : pdf)

Sources :

http://net.tutsplus.com/tutorials/html-css-techniques/top-15-best-practices-for-writing-super-readable-code/
http://www.kmoser.com/articles/Good_Programming_Practices.php
http://www.homepages.ucl.ac.uk/~ucappgu/seminars/good-practice.pdf
http://msdn.microsoft.com/en-us/library/aa260844(v=vs.60).aspx
http://en.wikipedia.org/wiki/Best_Coding_Practices
http://arxiv.org/abs/1210.0530
http://www.joelonsoftware.com/articles/fog0000000069.html
http://www.joelonsoftware.com/articles/fog0000000043.html
http://www.nws.noaa.gov/oh/hrl/developers_docs/General_Software_Standards.pdf

Matlab ctrl+scroll, pixel registration