From my own experience, when I was a beginner, I never understood these kind of messages or warnings and just ignored them. Later, when I learned more about programming and would be able to actually understand the messages, they usually didn’t show up because I wrote better code or if they showed up, in 95% of the cases they annoyed me because I knew what I was doing.

Maybe I’m the exception to the rule, but an easy way to configure mlint would definitely be very helpful. 100 checkboxes where the user can check or uncheck every single message is not the way to go, though!

We have registered the request to catch specific errors. I too think that would be a very nice feature, and, as you point out, help write concise code.

–Loren

doSomething ;
doMore ;

…in other words, code that is not embedded in any try/catch at all. I can’t imagine M-lint complaining here, as in “Warning: you have written code that uses the default MATLAB error/warning handler; this is a Really Bad Thing to do.”

I think that attempts to let M-lint distinguish between snippet #1 and #2 will probably devolve into trying to distinguish between #1 and #0, which will not be helpful.

A better approach at the try/catch error handing would be to allow catch to catch only specified errors. I have often written try/catch code, expecting one error, but had the catch find an error I didn’t want to be caught. I would rather just tell MATLAB to catch just the errors I want to catch, and let the default error handling process catch everything else. It would be a lot simpler to code that way.

For example, if I’m running an experiment on lots of sparse test matrices, I want to catch the out-of-memory condition, skip that matrix, and keep going with other test matrices. What I would really like to specify is something like this:

for k = 1:nmat
try
get the kth matrix
run an experiment on the kth matrix
catch ‘MATLAB:nomem’
oops, out of memory. Just keep going.
end
end

Then if I encounter an unexpected error, MATLAB will properly terminate my code. To do this with the current try/catch, I must use “catch ME” (sounds like a line from the movie “Enchanted”) and then check ME to see if it’s what I expected and then explicitly throw an error if it isn’t Hmm, did I expect ME or someone else ;-) ?. That’s tedious, and tweaking M-lint won’t be of much help, I think.

Part of the issue with GUIDE is that it isn’t generating “up-to-date” code. We know about that and have plans to fix the generated code so it doesn’t trigger M-Lint messages (though that’s NOT the reason for the rewrite — the reason is that we can generate what we think IS better code). Not sure what release this will show up in….

–Loren

–DA

What about a macro-type setting in the preference for how “aggressive” mlint should behave. A slider from “silent” to “teaching mode” and a few in between could satisfy how we each want to use code checking at different times. Each strictness level could have presets for the individual checks and messages being on or off.

Best,
Rob

As an example, see Nick Higham’s Matrix Computation Toolbox, or Cleve Moler’s NCM toolbox. Both are excellent codes, but get dinged in the File Metrics by an overly-aggressive M-lint. They were written before “||” and “&&” were added to the language. Nick’s code also uses the old-style warnings, but M-lint complains there, too.

So, M-lint is made more stringent, then I would recommend not making these settings the default … or at least exclude them from File Metrics posted on the File Exchange.

How about a check for an H1 line?

I did know about being able to turn off the warnings, but I’d never known I could do it via a right click. Neat.

John

Dan

Thanks for the comments so far.

Do you know you can turn messages off from the preferences panel or right-clicking on the message and choosing to have that topic not reported on? That way, even if mlint does have more “style” messages, you can still regulate your interaction with them.

As for performance, if we can identify some code patterns that would be more optimally done another way, we can add those to mlint. But it needs to be a pattern (even if complex). Any candidates?

–Loren