{"id":2638,"date":"2011-01-14T14:14:15","date_gmt":"2011-01-14T14:14:15","guid":{"rendered":"https:\/\/blogs.mathworks.com\/pick\/2011\/01\/14\/good-matlab-coding-practices\/"},"modified":"2016-11-16T15:12:42","modified_gmt":"2016-11-16T20:12:42","slug":"good-matlab-coding-practices","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/pick\/2011\/01\/14\/good-matlab-coding-practices\/","title":{"rendered":"Good MATLAB Coding Practices"},"content":{"rendered":"
\n

Brett<\/a>‘s Pick this week has three parts, and is really a tip of the hat to three authors who have taken the initiative to try to
\npromote and teach good MATLAB programming practices. In particular, I’d like to acknowledge Michael Robbins<\/a> for “Good MATLAB Programming Practices”<\/a>; Pascal Getreuer<\/a> for “Writing Fast MATLAB Code”<\/a>; and Nico Schl\u00f6mer<\/a> for “Guidelines for writing clean and fast code in MATLAB.”<\/a><\/p>\n

I recall fondly my first attempts at writing a bit of MATLAB code; I believe the year was 1996. I fumbled around, read a few
\n“Getting Started”<\/a> documents, and began writing code. I was amazed at how easily I could get MATLAB to do what I wanted it to do! MATLAB is
\na fourth-generation interpreted language, and it’s relatively forgiving; somehow even ugly code manages to work. Over the
\nyears, as I grew more confident (and competent) with the language, I learned just how poor my coding practices were. And in
\nsome cases, the difference between good code and bad code can be orders of magnitude difference in performance (as measured
\nby computation time). It behooves the user to spend some time building a greater mastery of the language; dividends will come
\nnot only in improved readability and maintainability, but in improved performance as well. Moments before writing this post,
\nI had the very unpleasant experience of looking back at my 15-year-old code; it could appear in a textbook of poor coding
\npractices!<\/p>\n

Fortunately, Michael provided two versions of his “Good Programming Practices” (2003); I had a font problem with one, but
\nwas able to read the second without difficulty. Michael’s document provides a solid page of useful gems. Among them, he advises
\nthat: “creative use of FIND, PROD, SUM, CUMSUM, NaN, REPMAT, RESHAPE, ONES and ZEROS can really help vectorize your code,
\nbut try not to make the code too cryptic. There is a tradeoff between execution time and readability. If your statement is
\ncryptic, either include an equivalent (but slow and easy to read) version in a comment or write a MEX file.” He also suggests
\nthat the user “use PROFILE to identify where you need to work on speed improvements.”<\/p>\n

Pascal’s “Writing Fast MATLAB Code” (2009) is more ambitious. In a beautifully formatted document, he lays out 12 chapters
\non the topic of better utilization of the MATLAB language:<\/p>\n

\n