byte-physics / igor-pro-coding-conventions Goto Github PK

No need for a break after control flow statements return, continue, Abort, AbortOnValue.

Igor Pro allows code before the first case in a switch statement but this code is never executed.

switch(i)
	print "this would never be executed", i
	case 1:
		print "one"
		break
endswitch

Similarly to #35, I would get rid of such code as it only confuses the reader.

print !cmpstr("a"[1], "")

works without RTE and gives 1. But we don't want to exploit that as experience has shown that this can easily hide valid bugs.

It is pretty easy to choose the wrong wave type in IP as the default is FP32. Maybe it is worth always requiring that the wave type is specified? Think about that.

https://www.wavemetrics.com/forum/general/wavez-vs-zz

After some testing it turns out that the following way is working properly:

	variable err

	// for first loaded XOP -> xop error codes returned are in the range 10000+ upto max. 10999; error codes -1 to 9999 are Igor Pro error codes
	// for second+ loaded XOP -> xop error codes returned are offsetted by n x 0x10000 per XOP instead of 10000.
	// Therefore, returning the code through RTE and directly through V_flag (SetOperationReturnValue):
	err = err < 0xFFFF ? err : (err & 0xFFFF) + 10000
	// Note: Getting the error message through GetRTErrMessage, GetErrMessage(code) requires the original RTE code (does not work with directly return through  V_flag).

based partly on https://www.wavemetrics.com/forum/general/querying-xop-error-codes

Edited: Added (...) as + has higher precendence than &

Igor ignores all invalid code outside of functions and doesn't report this. I have seen many code examples of function or operation calls outside of functions like this:

Function Test(string a)
    print a
End

Test("this is never executed")
print "this is also never executed"

Function Test2()
End

I would suggest getting rid of such invalid code outside of functions, as it is ignored by Igor and only confuses the reader.

I think this is a known issue for WM, but they can't fix it because it would have a too big impact on their compiler.

• User data
• window hooks
• background functions
• ???

A switch statement should always handle the default case. Either with explicit code if that is expected or an Abort/Assertion if that is not expected.

Should there be a ws directly after the function keyword?

Function /S customFunction()

or

Function/S customFunction()

Mixing human edited programm code with machine generated one is difficult to understand and read.

Igor Pro allows omitting the comma at certain argument positions for operations and does allow extraneous commas before the first argument. For example:

// omitting a comma
printf "x=%d, y=%d" 1, 2
sprintf msg, "x=%d, y=%d" 1, 2
// extraneous comma
printf , "text"

I would consider this as bad coding style and propose that all arguments must be separated by exactly one comma and no commas are allowed before or after the argument list.

printf "x=%d, y=%d", 1, 2
sprintf msg, "x=%d, y=%d", 1, 2
printf "text"

Impact

There is a large code base with lots of these coding style errors, so I wouldn't suggest reporting this to WM and fixing their compiler. I couldn't find any case for which fixing the comma leads to a compile error in Igor Pro.

Window MMEdisplayWindow() : Graph

EndMacro

Function dostuff()

	string/g MMEdisplayWindow

	print exists("MMEdisplayWindow")
End

this does return 5 (macro) but if the macro is not present it returns 2 for the global string. Use the fainer grained functions instead.

If the function signature contains required and optional arguments, Igor Pro does allow the following four cases of comma placement:

Function Case1(string reqArg, [string optArg])

Function Case2(string reqArg[, string optArg])

Function Case3(string reqArg [string optArg])

Function Case4(string reqArg, [, string optArg])

I would allow only case 1 as good coding style and also looks cleaner.

Impact

I have seen case 2 and case 3 in many different repositories, so I wouldn't report this to WM for compatibility reasons.

See https://www.wavemetrics.com/comment/23620#comment-23620.

See http://info-igor.org/IgorMessages/2018/06/Info-Igor_2018-06_0019.html

Thomas requested this in byte-physics/igortest#327 (comment) but I need more clarification:

• Do we really want a function prefix for static functions as well? These are only accessible inside the module and therefore is no benefit using a function prefix. I support requiring a function prefix for global functions as they can clash with other user functions.
• How do we determine the name of the function prefix? There should be a rule.

Currently, function prefixes are only mentioned once in the coding convention and that is that they may be used before the name of a function.

pnt2x -> IndexToScale, numpnts -> DimSize, etc.