Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
check syntax errors in m file

Subject: check syntax errors in m file

From: Andrej S

Date: 10 Jul, 2009 17:23:01

Message: 1 of 24

hi,
how can I programmatically check (syntax) errors in the m file?
I was trying mlint, but there I can not distinguish between errors and warnings...

thanks,
a.

Subject: check syntax errors in m file

From: Mason Freed

Date: 17 Jun, 2010 21:46:04

Message: 2 of 24

Any updates on this question?? There MUST be some way to distinguish warnings from syntax errors using the mlint() function. The information is obviously there - the editor shows them in different colors.

Anybody?

Subject: check syntax errors in m file

From: Matt Fig

Date: 17 Jun, 2010 22:24:05

Message: 3 of 24

This seems to work, if I understand what you are after:

G = mlint('funcname')
strfind({G.message},'error') % Returns empties if no word 'error' is found'

Subject: check syntax errors in m file

From: Mason Freed

Date: 17 Jun, 2010 22:37:04

Message: 4 of 24

Thanks for the quick response Matt.

However, your suggestion unfortunately doesn't work. For example, if I write this function:

--------------------
function myFunc()

foo=2
for ii=1:10
    disp(ii);
bar=foo+3;
--------------------

In the editor, line 4 (the un-ended for-loop) shows up as a red error. However, running mlint doesn't return the word "error" at all:

>> mlint('myFunc.m')
L 3 (C 4): Terminate statement with semicolon to suppress output (in functions).
L 4 (C 1-3): An END might be missing, possibly matching FOR.
L 6 (C 1-3): The value assigned to variable 'bar' might be unused.

From the m-lint output, there's no way to tell that the 2nd message is an error, while #1 and #3 are warnings.

Any other thoughts?

Thanks,
Mason

Subject: check syntax errors in m file

From: Matt Fig

Date: 17 Jun, 2010 23:10:20

Message: 5 of 24

Ah, I see. It seems to me that to do what you want would be tedious, but possible. Here is one way I can see through to do it. Open up the preferences and then look at mlint. Copy the string down for every error type that you want to check for, then in your function compare the results of the call to MLINT with a string database. For example, here is a brief sketch. Note that some of the string manipulation could be optimized, this is just for illustration as to how one could approach the problem:

function tf = any_errors(fname)
% Returns logical true if MLint detectable errors are found in FNAME.
tf = 0;
G = mlint(fname);

if any(~cellfun(@isempty,strfind({G.message},'error')))
    return
end

DB = {'BREAK can only be used in';
      'Apparently a quoted string';
      'Apparently an END is missing'}; % Add as many as you want.

for ii = 1:length(DB)
    if any(~cellfun(@isempty,strfind({G.message},DB{ii})))
        tf = 1;
        return
    end
end

Subject: check syntax errors in m file

From: Steven Lord

Date: 18 Jun, 2010 13:59:17

Message: 6 of 24


"Mason Freed" <mfreedREMOVETHIS@mfreedREMOVETHIS.com> wrote in message
news:hve52s$1o9$1@fred.mathworks.com...
> Any updates on this question?? There MUST be some way to distinguish
> warnings from syntax errors using the mlint() function. The information is
> obviously there - the editor shows them in different colors.
>
> Anybody?

What do you intend to do with this information? Do you want simply to check
if the function _can_ run without actually running it? Or do you want to
get a list of errors so that you can tell someone specifically what
lines/sections to fix?

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: check syntax errors in m file

From: Yair Altman

Date: 19 Jun, 2010 21:29:04

Message: 7 of 24

"Steven Lord" <slord@mathworks.com> wrote in message <hvfu3l$cd0$1@fred.mathworks.com>...
>
> "Mason Freed" <mfreedREMOVETHIS@mfreedREMOVETHIS.com> wrote in message
> news:hve52s$1o9$1@fred.mathworks.com...
> > Any updates on this question?? There MUST be some way to distinguish
> > warnings from syntax errors using the mlint() function. The information is
> > obviously there - the editor shows them in different colors.
> >
> > Anybody?
>
> What do you intend to do with this information? Do you want simply to check
> if the function _can_ run without actually running it? Or do you want to
> get a list of errors so that you can tell someone specifically what
> lines/sections to fix?


In one of my applications I needed to enable the user to dynamically create executable Matlab code that would then be run interactively. This enabled users to create dynamic data analyses functions without actually needing to know Matlab or to code all the nuts-and-bolts of a regular Matlab function. For this I needed to display warnings and errors-on-the-fly and the OP's question goes directly to this need.

My solution was to use the undocumented internal function mlintmex, as follows:

          errMsgs = mlintmex('-m2', srcFileName);
          allMsgs = mlintmex('-m0', srcFileName);

          numErrors = length(strfind(regexprep(errMsgs,'\*\*\*.*',''),char(10)));
          numAllMsg = length(strfind(regexprep(allMsgs,'\*\*\*.*',''),char(10)));
          numWarns = numAllMsg - numErrors;

(and from the messages themselves I extracted the actual error/warning location)

Yair Altman
http://UndocumentedMatlab.com

Subject: check syntax errors in m file

From: Mason Freed

Date: 21 Jun, 2010 15:23:21

Message: 8 of 24

First, thanks Yair. Your suggestion works perfectly, in a handful of lines. How do you find all of your nifty undocumented stuff?

Matt, thanks for the suggestion, which I think would work, but Yair's is much easier to implement.

And finally, Steven, the reason for my request is that I'm building an automated unit test system. It will run over all of our Matlab code whenever the source control system (subversion) registers a new commit. I want one of the policies to be that committed code contain no syntax errors. So I want a quick way to identify only the "killer" syntax errors. I can't make the policy that mlint reports no warnings at all, because the other developers would kill me for it. (Much as I would like to enforce that as a constraint.)

Thanks,
Mason

Subject: check syntax errors in m file

From: Yair Altman

Date: 21 Jun, 2010 16:17:24

Message: 9 of 24

"Mason Freed" wrote in message ...
> First, thanks Yair. Your suggestion works perfectly, in a handful of lines. How do you find all of your nifty undocumented stuff?

There are two main sources: reading/searching this newsgroup and reading the internal code of Matlab's m-files. I make a habit of noting down new stuff which is undocumented - then when the need occurs (often years later), I have an immediate answer.

Here's another thread that documents mlintmex usage that you may find useful, which I posted a few years ago: http://www.mathworks.com/matlabcentral/newsreader/view_thread/145245

In this particular case, I think I learned about mlintmex from the indomitable Us (Urs) Schwartz, but I can't find the original reference now. He also posted the related utilities FDEP and FARG on the File Exchange that you may find useful (as are all of his utilities). In any case, Us posted the following humorous comment about the source of *his* knowledge some years ago: http://www.mathworks.com/matlabcentral/newsreader/view_thread/115423#292260

Yair Altman
http://UndocumentedMatlab.com

Subject: check syntax errors in m file

From: Mason Freed

Date: 21 Jun, 2010 17:06:22

Message: 10 of 24

"Yair Altman" <altmanyDEL@gmailDEL.comDEL> wrote in message <hvo3ak$aeb$1@fred.mathworks.com>...
> "Mason Freed" wrote in message ...
> There are two main sources: reading/searching this newsgroup and reading the internal code of Matlab's m-files. I make a habit of noting down new stuff which is undocumented - then when the need occurs (often years later), I have an immediate answer.
>
> Here's another thread that documents mlintmex usage that you may find useful, which I posted a few years ago: http://www.mathworks.com/matlabcentral/newsreader/view_thread/145245
>
> In this particular case, I think I learned about mlintmex from the indomitable Us (Urs) Schwartz, but I can't find the original reference now. He also posted the related utilities FDEP and FARG on the File Exchange that you may find useful (as are all of his utilities). In any case, Us posted the following humorous comment about the source of *his* knowledge some years ago: http://www.mathworks.com/matlabcentral/newsreader/view_thread/115423#292260
>
> Yair Altman
> http://UndocumentedMatlab.com

Interesting - thanks for the references Yair.

One note that I found, related to both mlint and mlintmex: they seem to choke on files with spaces in the filename. These give back "Filename {strangely modified path here} is not formed from a valid MATLAB identifier." I'm writing a quick util to copy filenames containing spaces to a temp file and run mlintmex there, but do you have any other magic suggestions to tackle this issue?

Thanks,
Mason

Subject: check syntax errors in m file

From: Yair Altman

Date: 21 Jun, 2010 17:24:08

Message: 11 of 24

"Mason Freed" <mfreedREMOVETHIS@mfreedREMOVETHIS.com> wrote in message <hvo66e$gfu$1@fred.mathworks.com>...

> One note that I found, related to both mlint and mlintmex: they seem to choke on files with spaces in the filename. These give back "Filename {strangely modified path here} is not formed from a valid MATLAB identifier." I'm writing a quick util to copy filenames containing spaces to a temp file and run mlintmex there, but do you have any other magic suggestions to tackle this issue?


No magic suggestions for the simple reason that Matlab m-files should not have a space in their filenames... If you're doing check-in sanity checks as you wrote above then this would be one obvious source of reported error.

Yair Altman
http://UndocumentedMatlab.com

Subject: check syntax errors in m file

From: Mason Freed

Date: 21 Jun, 2010 17:34:22

Message: 12 of 24

"Yair Altman" <altmanyDEL@gmailDEL.comDEL> wrote in message <hvo77o$naj$1@fred.mathworks.com>...

> No magic suggestions for the simple reason that Matlab m-files should not have a space in their filenames... If you're doing check-in sanity checks as you wrote above then this would be one obvious source of reported error.
>
> Yair Altman
> http://UndocumentedMatlab.com

Thanks. I was under the impression originally that the issue occurred on PATHS with spaces in the name (e.g. "C:\Documents and settings") but you're exactly right. The only issue is with file NAMES that contain spaces. So no issue at all (and a good addition to the check!).

Thanks again for the quick responses Yair.

Mason

Subject: check syntax errors in m file

From: Walter Roberson

Date: 21 Jun, 2010 19:01:06

Message: 13 of 24

Mason Freed wrote:
> I can't make the policy that mlint reports no warnings at all,
> because the other developers would kill me for it. (Much as I would like
> to enforce that as a constraint.)

It isn't a reasonable constraint until at least 2009b:

[A, B, C] = SomeCall(D);

If it happens that the code only needs C and not A or B, then the author
should not be forced to do something like write A and B to an output file that
is then deleted just so that the values are "used" so as to avoid the warning.

The latest versions of Matlab allow

[~, ~, C] = SomeCall(D)

but then you are relying on a new feature and destroying backwards compatibility.


Likewise, it is not uncommon to write routines that follow a standard calling
procedure and have arguments passed in to them that that _particular_ routine
doesn't happen to use but where the routines are "black boxes" from outside.
For example if you are doing table-driven calls to an appropriate optimization
function then the calls have to pass in all the parameters that _any_ of the
optimization routines might need. There might, for example, be a tuning
parameter that only makes sense for one kind of optimization but because of
the common calling sequence has to be passed to all of them. You don't want to
force the author to somehow uselessly "use" the parameter just to avoid the
warning. (This too is solved with ~ in the very newest Matlabs, but again that
has costs.)

Subject: check syntax errors in m file

From: Mason Freed

Date: 21 Jun, 2010 20:42:24

Message: 14 of 24

Walter Roberson <roberson@hushmail.com> wrote in message <hvod1p$855$1@canopus.cc.umanitoba.ca>...
> Mason Freed wrote:

> It isn't a reasonable constraint until at least 2009b:

I would disagree - as far as I know, the '%#ok' construct has been around for as long as mlint has. So it can be reasonably used to explicitly suppress warnings for known cases (as your examples show). I always come down on the side of eliminating all warnings - it is just a safer way to do things, and doesn't add too much overhead to the programmer. Just my humble opinion, of course!

Thanks,
Mason

Subject: check syntax errors in m file

From: Walter Roberson

Date: 22 Jun, 2010 08:20:14

Message: 15 of 24

Mason Freed wrote:
> Walter Roberson <roberson@hushmail.com> wrote in message
> <hvod1p$855$1@canopus.cc.umanitoba.ca>...
>> Mason Freed wrote:
>
>> It isn't a reasonable constraint until at least 2009b:
>
> I would disagree - as far as I know, the '%#ok' construct has been
> around for as long as mlint has. So it can be reasonably used to
> explicitly suppress warnings for known cases (as your examples show). I
> always come down on the side of eliminating all warnings - it is just a
> safer way to do things, and doesn't add too much overhead to the
> programmer. Just my humble opinion, of course!

That policy will just lead to people routinely turning off "all
instances in file" of warnings without examination. The medicine will be
worse than the problem.

We turn off warnings only when we completely understand their causes and
know that the existing code is appropriate. Sometimes we don't
completely understand the code we have written or sometimes the warning
points out future work that should be done and turning off the warning
would hide that hint from us. As long as the warning is there it is
"nag-ware" prompting us to continue thinking about the issue.


I said above that sometimes we don't completely understand the code we
have written, and that is true.

For example I wrote a section of code that represents projection of a 2D
set of points on to a line, and when I wrote it in accordance with all
the standard formula it produced provably wrong answers. When I reversed
the X and Y coordinate the result produced the expected answers. I
consulted over half a dozen different references and the theoretical
implementation is the right one but doesn't work. We have a vague notion
as to why exchanging X and Y might work, but it would take more time to
dig in to it and prove or disprove it than the matter is worth.

There are a number of other places where we don't know _why_ our code
works. We write experimental formula and test the formula against data;
we don't always understand the math behind the formula. There are lots
of different possible formula, and working out the theoretical math of
each of them could take decades *each*. That isn't meant to be an
exaggeration either: there are some formula in the field we are working
in that have been used since the 1960's and their implications are still
not fully understood. So we do a "Darwinian selection": we try formula
and only go deeper into the theory of the ones that work well for us (or
for the ones that really look like they should do well but turn out not
to: a good explanation for why something seemingly obvious fails can
provide very useful insights into what has to be taken into account by
something that works.)

If this all sounds sloppy... it's because we do applied *research*, and
research _commonly_ has a 90% failure rate for ideas, and only a 1% or
2% real success rate (with the other 8-9% being academically interesting
but not good enough to be worth pursuing for applied research.)

Subject: check syntax errors in m file

From: Mason Freed

Date: 22 Jun, 2010 15:38:22

Message: 16 of 24

Walter Roberson <roberson@hushmail.com> wrote in message <3n_Tn.2420$Yo5.136@newsfe01.iad>...
> That policy will just lead to people routinely turning off "all
> instances in file" of warnings without examination. The medicine will be
> worse than the problem.

That, as you point out, would be bad programming practice too. I would discourage that as much as I would discourage having warnings left over.

> We turn off warnings only when we completely understand their causes and
> know that the existing code is appropriate. Sometimes we don't
> completely understand the code we have written or sometimes the warning
> points out future work that should be done and turning off the warning
> would hide that hint from us. As long as the warning is there it is
> "nag-ware" prompting us to continue thinking about the issue.

See http://blogs.mathworks.com/desktop/2008/03/17/whats-on-my-todo-list for an alternative (perhaps better) method for keeping track of hacks and todo items.

As I said in the beginning, this is my opinion on how to do things. There are infinitely many others, and the best one likely depends on the particulars of each situation. To each, his own.

Thanks,
Mason

Subject: check syntax errors in m file

From: Steven Lord

Date: 22 Jun, 2010 19:12:28

Message: 17 of 24


"Mason Freed" <mfreedREMOVETHIS@mfreedREMOVETHIS.com> wrote in message
news:hvo7qt$2bh$1@fred.mathworks.com...
> "Yair Altman" <altmanyDEL@gmailDEL.comDEL> wrote in message
> <hvo77o$naj$1@fred.mathworks.com>...
>
>> No magic suggestions for the simple reason that Matlab m-files should not
>> have a space in their filenames... If you're doing check-in sanity checks
>> as you wrote above then this would be one obvious source of reported
>> error.
>>
>> Yair Altman http://UndocumentedMatlab.com
>
> Thanks. I was under the impression originally that the issue occurred on
> PATHS with spaces in the name (e.g. "C:\Documents and settings") but
> you're exactly right. The only issue is with file NAMES that contain
> spaces. So no issue at all (and a good addition to the check!).

For that check, you will want to use ISVARNAME. That will detect if the
name of your script or function file violates any of these rules:

1) Names must be NAMELENGTHMAX or fewer characters
2) Names must start with a letter
3) Names must contain only letters, numbers, and underscore
4) Names must not be a keyword (see ISKEYWORD)

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: check syntax errors in m file

From: dpb

Date: 22 Jun, 2010 19:21:27

Message: 18 of 24

Steven Lord wrote:
> "Mason Freed" <mfreedREMOVETHIS@mfreedREMOVETHIS.com> wrote in message
> news:hvo7qt$2bh$1@fred.mathworks.com...
...

>> Thanks. I was under the impression originally that the issue occurred on
>> PATHS with spaces in the name (e.g. "C:\Documents and settings") but
>> you're exactly right. The only issue is with file NAMES that contain
>> spaces. So no issue at all (and a good addition to the check!).
>
> For that check, you will want to use ISVARNAME. That will detect if the
> name of your script or function file violates any of these rules:
>
> 1) Names must be NAMELENGTHMAX or fewer characters
> 2) Names must start with a letter
> 3) Names must contain only letters, numbers, and underscore
> 4) Names must not be a keyword (see ISKEYWORD)

Leaving only the issue of possible name collisions throughout a large
project, maybe...?

--

Subject: check syntax errors in m file

From: Yair Altman

Date: 23 Jun, 2010 09:33:04

Message: 19 of 24

> > > Any updates on this question?? There MUST be some way to distinguish
> > > warnings from syntax errors using the mlint() function. The information is
> > > obviously there - the editor shows them in different colors.
> > >
> > > Anybody?
> >
> > What do you intend to do with this information? Do you want simply to check
> > if the function _can_ run without actually running it? Or do you want to
> > get a list of errors so that you can tell someone specifically what
> > lines/sections to fix?

> My solution was to use the undocumented internal function mlintmex, as follows:
>
> errMsgs = mlintmex('-m2', srcFileName);
> allMsgs = mlintmex('-m0', srcFileName);
>
> numErrors = length(strfind(regexprep(errMsgs,'\*\*\*.*',''),char(10)));
> numAllMsg = length(strfind(regexprep(allMsgs,'\*\*\*.*',''),char(10)));
> numWarns = numAllMsg - numErrors;
>
> (and from the messages themselves I extracted the actual error/warning location)

Apparently, the built-in mlint function has an undocumented feature of accepting any mlintmex input argument. After all, all mlint's args are passed to mlintmex that actually does all the lint processing. This undocumented feature is even documented in an internal comment within the mlint.m file, although the actual extra args are not themselves documented.

So, in summary, you could simply do:
   errMsgs = mlint('-m2',srcFileNames); % m2 = errors only
   m1Msgs = mlint('-m1',srcFileNames); % m1 = errors and severe warnings only
   allMsgs = mlint('-m0',srcFileNames); % m0 = all errors and warnings

Note that mlint returns the data in struct format, while mlintmex returns a string that you must parse.

Yair Altman
http://UndocumentedMatlab.com

Subject: check syntax errors in m file

From: us

Date: 23 Jun, 2010 13:58:04

Message: 20 of 24

"Yair Altman" <altmanyDEL@gmailDEL.comDEL> wrote in message <hvo3ak$aeb$1@fred.mathworks.com>...
> "Mason Freed" wrote in message ...
> > First, thanks Yair. Your suggestion works perfectly, in a handful of lines. How do you find all of your nifty undocumented stuff?
>
> There are two main sources: reading/searching this newsgroup and reading the internal code of Matlab's m-files. I make a habit of noting down new stuff which is undocumented - then when the need occurs (often years later), I have an immediate answer.
>
> Here's another thread that documents mlintmex usage that you may find useful, which I posted a few years ago: http://www.mathworks.com/matlabcentral/newsreader/view_thread/145245
>
> In this particular case, I think I learned about mlintmex from the indomitable Us (Urs) Schwartz, but I can't find the original reference now. He also posted the related utilities FDEP and FARG on the File Exchange that you may find useful (as are all of his utilities). In any case, Us posted the following humorous comment about the source of *his* knowledge some years ago: http://www.mathworks.com/matlabcentral/newsreader/view_thread/115423#292260
>
> Yair Altman
> http://UndocumentedMatlab.com

just a note
the file below (please, use the ...view original format... to copy/paste!) runs through all currently known MLINT/MLINTMEX options (2010a) and collects each option in an output struct with respective fieldnames...
additional notes:
- some options (eg, -yacc, -ud) will take some time(!!!!!)...
- the copy may have wrapped the syntax falsly...

% example
     r=doli('unique');
     [r.call.message]

us
<<<<< FILE >>>>>

%DOLI MLINT a file with various options
%
%SYNTAX
%-------------------------------------------------------------------------------
% R = DOLI(FNAM);
% use MLINT
%
% R = DOLI(FNAM,1);
% use MLINTMEX
%
%OUTPUT
%-------------------------------------------------------------------------------
% R : output struct with fieldnames == MLINT option
% and content of output
% retrieve messages, eg,
% [R.calls.message]
%
% other help removed for posting

%-------------------------------------------------------------------------------
function r=doli(varargin)

% created:
% us 12-Feb-2001 us@neurol.unizh.ch
% modified:
% us 23-Jun-2010 15:43:22
%
% localid: us@USZ|ws-nos-36362|x86|Windows XP|7.10.0.499.R2010a

opt={
% option remarks
% -------------------------------
'-all'
'-allmsg'
'-amb'
'-body'
'-callops'
'-calls'
'-com'
'-cyc'
% '-db' % == -set + -ud + -tab
'-dty'
'-edit'
'-en' % messages in english
'-id'
'-ja' % messages in japanese
'-lex'
'-m0' % + other opt
'-m1' % + other opt
'-m2' % + other opt
'-m3' % + other opt
'-mess'
'-msg'
'-notok'
'-pf'
'-set'
'-spmd'
'-stmt'
'-tab'
'-tmtree'
'-tmw' % not valid anymore
'-toks'
'-tree'
'-ty'
'-ud'
'-yacc' % ONLY: !mlint FILE -yacc -...

% default behavior of DOLI
% '-struct' % output -> struct
};

r.o=opt;
if ~nargin
help(mfilename);
return;
end
if nargin > 1
eng=@mlint;
else
eng=@mlintmex;
end
fnam=which(varargin{1});
if isempty(fnam)
disp(sprintf('DOLI> file not found %s',varargin{1}));
return;
end

fmt=max(cellfun('length',opt(:,1)));
fmt=sprintf('%%-6s> %%-%d.%ds %%d',fmt,fmt);

disp(sprintf('%s > %s','MLINT',fnam))
for i=1:size(opt,1);
copt=opt{i,1};
sopt=copt(2:end);
if strcmp(sopt,'yacc')
[tmp,tmp]=system(sprintf('mlint %s -yacc -m3',fnam)); %#ok
else
tmp=eng(fnam,copt,'-struct');
end
if iscell(tmp)
tmp=tmp{:};
end
disp(sprintf(fmt,'OPTION',copt,numel(tmp)));
r.(sopt)=tmp;
end
end
%-------------------------------------------------------------------------------

Subject: check syntax errors in m file

From: us

Date: 23 Jun, 2010 14:55:21

Message: 21 of 24

"us "
> % example
> r=doli('unique');
> [r.call.message]

must read

     [r.calls.message]

sorry for confusion
us

Subject: check syntax errors in m file

From: Mason Freed

Date: 23 Jun, 2010 15:34:04

Message: 22 of 24

Thanks Yair and us - both interesting additions. I'll start using mlint with the -m2 option directly - nicer output format.

There's a lot of information in the doli() output. Interesting. (Not too much use for me right now, but I'll keep it in the back of my head for later projects...)

Thanks,
Mason

Subject: check syntax errors in m file

From: Mason Freed

Date: 23 Jun, 2010 16:02:21

Message: 23 of 24

"Steven Lord" <slord@mathworks.com> wrote in message <hvr1us$n9v$1@fred.mathworks.com>...
>
> For that check, you will want to use ISVARNAME. That will detect if the
> name of your script or function file violates any of these rules:
>
> 1) Names must be NAMELENGTHMAX or fewer characters
> 2) Names must start with a letter
> 3) Names must contain only letters, numbers, and underscore
> 4) Names must not be a keyword (see ISKEYWORD)

Great tip - thanks Steve.

Subject: check syntax errors in m file

From: Mason Freed

Date: 23 Jun, 2010 17:12:05

Message: 24 of 24

"Mason Freed" <mfreedREMOVETHIS@mfreedREMOVETHIS.com> wrote in message <hvtb6d$lqn$1@fred.mathworks.com>...
> "Steven Lord" <slord@mathworks.com> wrote in message <hvr1us$n9v$1@fred.mathworks.com>...
> >
> > For that check, you will want to use ISVARNAME. That will detect if the
> > name of your script or function file violates any of these rules:
> >
> > 1) Names must be NAMELENGTHMAX or fewer characters
> > 2) Names must start with a letter
> > 3) Names must contain only letters, numbers, and underscore
> > 4) Names must not be a keyword (see ISKEYWORD)
>
> Great tip - thanks Steve.

Actually, I found a flaw in this idea: isvarname('end') is 0. However, in a class folder, end.m is a valid overload for the end function.

I think I'm just going to implement #1-#3 above, and leave out #4.

Thanks,
Mason

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us