how to start writing a program ?

102 views (last 30 days)
Niki on 5 Sep 2011
I think it would be very nice if you could put some comment for a person who want to learn and or start to write a program.
1- what should he/she does at the first step to write a program?
2- which are the most useful commands in Matlab?
3- how can you check if your program works well or not?
4- altogether anything which is useful for a person who wants to write a program
Good writing conveys meaning. Great writing does the same, but uses fewer words.

Answers (6)

Andreas Goser
Andreas Goser on 6 Sep 2011
My 2 cents: It is all a matter of goals and skills. Engineers often like to start small and incrementally develop code. Downside is, sometimes it becomes big, slow and unreadable one day. Computer Science people often create a super master plan and structure, but it takes ages until the first piece of real code can be tested. MATLAB should support both strategies.
Last not least. Some people (like me) like to modify existing code.

Paulo Silva
Paulo Silva on 5 Sep 2011
  1. be familiar with MATLAB and read at least documentation Getting Started part
  2. know what functions are and how to create them (again read the documentation)
  3. Now for your specific program find exactly what you need to do
  4. Divide your code into functions so you can develop each part separately
  5. Every command is useful, there are no most useful commands
  6. To check if it works well or not give values to the functions arguments and see what happens.
  7. Finally you learn by doing it and reading the documentation not by doing crazy things with colors and graphics without first knowing how to do the basic and most important stuff, please read the documentation.

Fangjun Jiang
Fangjun Jiang on 5 Sep 2011
My two cents:
  1. Draw your programming flow chart on paper
  2. help or doc
  3. Use the debugging mode to run code step by step
  4. Start from small to big.

Daniel Shub
Daniel Shub on 5 Sep 2011
To me the most useful command is %. That's right comment everything you do. Do use silly end of the line comments. Big chunky blocks of well written clear text explaining in words and sometimes simple math what the code is doing (or at least supposed to be doing.
Some might say that eval, global and cell are the most powerful commands. If you think you need to use eval or a global variable, stop drop and roll. Go get a cup of coffee and think about ways around it. If the coffee doesn't help you get around it, come here and ask. Also be aware of cell arrays. In my opinion they have more legitimate uses then eval and global, but are often used inappropriately.
Finally, don't optimize until you have to. To start with just get your code running. If in the end it takes too long, then optimize with the help of the profiler.

Niki on 6 Sep 2011
Thanks to all of you, you are always ready and always try to help, all of you saw from different aspect , Thanks

Walter Roberson
Walter Roberson on 6 Sep 2011
Andreas is correct, there are different coding styles that suit different needs.
One of my early summer jobs involved helping program an Air Traffic Control System. As it was extremely important that everything be done correctly, years of work had been put in to building a very complete plan of what exactly the system was to do and how it was to do it; the tasks I was given already had their needs and interfaces documented, and I was responsible for following the existing plan and for testing the code strenuously. There are no acceptable "little surprises" when it comes to managing the safety of several 20000 people simultaneously.
The work I am doing now (many years later) involves inventing new mathematical techniques and investigating to see whether those techniques are useful for a particular purpose. The techniques we invent do not have to be perfect and there is good reason to believe that there is no possible "perfect" method for what we are doing.
Unfortunately, when it comes to the creation and testing of new mathematical ideas, it is not at all practical to create detailed plans. To be honest: we make things up as we go along, encountering flaws and coming up with variations. The ideas get polished over time as we "try it and see what happens". And sometimes we don't realize the flaws for several years. "Boss, remember that one-horned one-eyed flying purple people eater algorithm we did a couple of years ago? Well, I just realized that it can't work if the horn is the same purple as the skin." "D'oh!"

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!