A lot of places online tell you about good MATLAB coding practice. In fact, if you ask five developers about their five best coding practices, you get five different answers, partly because everyone is different. The following list represents the best coding practices from a number of sources that have stood the test of time.
Get a second opinion: Many developers are afraid to admit that they make mistakes, so they keep looking at the same script or function until they’re bleary eyed, and usually end up making more mistakes as a result. Having someone else look at the problem could save you time and effort, and will most definitely help you discover new coding practices more quickly than if you go it alone.
Write applications for humans and not machines: As people spend more time writing code, they start to enjoy what they do and start engaging in writing code that looks really cool but is truly horrible to maintain. In addition, the code is buggy and not very friendly to the people using it. People use applications that help them get work done quickly and without a lot of fuss.
Test often/make small changes: A few people actually try to write an entire application without ever testing it, even once, and then they’re surprised when it doesn’t work. The best application developers work carefully and test often. Making small changes means that you can find errors faster and fix them faster still.
Don’t reinvent the wheel: Take the opportunity to use someone else’s fully tested and bug-free code whenever you can (as long as you don’t have to steal the code to do so). In fact, actively look for opportunities to reuse code. Using code that already works in another application saves you time writing your application.
Modularize your application: Writing and debugging a piece of coding takes time and effort. Maintaining that code takes even longer. If you have to make the same changes in a whole bunch of places every time you discover a problem with your code, you waste time and energy. Write the code just one time, place it in a function, and access that piece of code everywhere you need it.
Plan for mistakes: Make sure your code contains plenty of error trapping. It’s easier to catch a mistake and allow your application to fail gracefully than it is to have the application crash and lose data that you must recover at some later time.
When you do add error-trapping code, make sure to write it in such a manner to actually trap the sorts of errors that you expect, and then add some general-purpose error trapping for the mistakes you didn’t expect.
Create documentation for your application: Every application requires documentation. Even if you plan to use the application to meet just your own needs, you need documentation because all developers eventually forget how their code works. Professionals know from experience that good documentation is essential.
When you do create the documentation, make sure that you discuss why you designed the software in a certain manner, what you were trying to achieve by creating it, problems you encountered making the software work, and fixes you employed in the past. In some cases, you want to also document how something works, but keep the documentation of code mechanics (how it works) to a minimum.
Ensure that you include documentation within your application as comments: Comments within applications help at several different levels, the most important of which is jogging your memory when you try to figure out how the application works. However, it’s also important to remember that typing help('ApplicationName') and pressing Enter will display the comments as help information to people using your application.
Code for performance after you make the application work: Performance consists of three elements: reliability, security, and speed. A reliable application works consistently and checks for errors before committing changes to data. A secure application keeps data safe and ensures that user mistakes are caught. A fast application performs tasks quickly.
However, before you can do any of these things, the application has to work in the first place. (Remember that you can use the profile() command to measure application performance and determine whether changes you implement actually work as intended.)
Make the application invisible: If a user has to spend a lot of time acknowledging the presence of your application, your application will eventually end up collecting dust. For example, the most annoying application in the world is the one that displays those “Are you sure?” messages. If the user wasn’t sure, then there would be no reason to perform the act.
Instead, make a backup of the change automatically so that the user can reverse the change later. Users don’t even want to see your application — it should be invisible for the most part. When a user can focus on the task at hand, your application becomes a favorite tool and garners support for things like upgrades later.
Force the computer to do as much work as possible: Anytime you can make something easier for the user, you reduce the chance that the user will make a mistake that you hadn’t considered as part of the application design. Easy doesn’t mean fancy.
For example, applications that try to guess what the user is going to type next usually get it wrong and only end up annoying everyone. Let the user type whatever is needed, but then you can check the input for typos and ensure that the input won’t cause the application to fail. Rather than guessing what the user will type, create an interface that doesn’t actually require any typing.
For example, instead of asking the user to enter a city and state in a form, have the user type a zip code and obtain the city and state from the zip code information.
