Igor Programming Tool (IPT) for formatting and linting your code

Thank you for this nice tool, which I already tried out.

I don't know whether it is OK to post feedback here, but a couple comments for now:

- First, I would like to note that ANSI escape code parsing is apparently switched off by default on windows which makes the output from this tool near unreadable. It took me quite some head-scratching to get this to work, but I followed this guide in the end:

https://stackoverflow.com/questions/51680709/colored-text-output-in-pow…

It would help to have a short tutorial for different command-line tools and / or an option to switch off formatted output (sorry if this already exists, but I couldn't find it)

- During installation, there is an option to create a desktop shortcut, but this does nothing apparently. I don't know what this would be useful for in any case since it is a command-line tool.

- Apparently, ipt lint and ipt lint -i shows different output for my files (the latter showing MUCH more warnings). I guess this is intended, but I don't get it. Does the -i flag include a setting for a more limited set of checks?

> I don't know whether it is OK to post feedback here, but a couple comments for now

Totally fine for me.

> First, I would like to note that ANSI escape code parsing is apparently switched off by default on windows which makes the output
> from this tool near unreadable. It took me quite some head-scratching to get this to work, but I followed this guide in the end:
> https://stackoverflow.com/questions/51680709/colored-text-output-in-pow…
> It would help to have a short tutorial for different command-line tools and / or an option to switch off formatted output (sorry if this already exists, but I couldn't find it)

We don't do any autodetection if ANSI escape codes are supported. You can use the `--color=no` switch to turn it off. I've made a note to document that. `ipt --help` has all the documentation for the top-level switches and `ipt <cmd> --help` for cmd.

> During installation, there is an option to create a desktop shortcut, but this does nothing apparently. I don't know what this would be useful for in any case since it is a command-line tool.

I've made a note and will followup.

> - Apparently, ipt lint and ipt lint -i shows different output for my files (the latter showing MUCH more warnings). I guess this is intended, but I don't get it. Does the -i flag include a setting for a more limited set of checks?

I'm suprised to hear that `ipt lint -i` shows more warnings. I would have expected the opposite as `-i` implies `--fix` which fixes linting warnings/errors instead of only warning. Do you have an MWE?

Thank you for the quick reply. I meant that 'ipt lint -i' shows much less warnings than 'ipt lint'. But the file itself is never changed in either case, so I wonder what -i is for then. I'll attach a test file. With the latter command I get two warnings and with the former about 6 warnings as output. If I understand you correctly, some warnings do not appear because they are apparently fixed (without actually being fixed in my case). Note that the file is properly formatted and overwritten via ipt format -i.

Regarding the formatting, I personally am not so fond of (see also the testfile before formatting):

- inline comments getting 'unaligned'. I have usually an aligned column for comments with enough visual distance, which I find much easier to read than comments tacked directly behind code.

- tabs for panel control elements being replaced without aligning equal signs (pos={}, size={} etc.). I have panel code also heavily aligned to make the code easily readable.

- equal signs of #pragma not being aligned

The latter two I can 'fix' myself, e.g., by setting an IPT_FORMAT_OFF there. But I am not willing to go through all my hundred comments to realign them after formatting, so no use for this particular feature for me now. It would be great to have a switch for 'leave comment indentation alone'. (Yes, I am aware that this kind of commenting might be considered bad style, but I want comments to sit out of the way and not in-between actual code if I can avoid it).

> If I understand you correctly, some warnings do not appear because they are apparently fixed (without actually being fixed in my case).
 

That's definilty odd. We'll have a look.

> - inline comments getting 'unaligned'. I have usually an aligned column for comments with enough visual distance, which I find much easier to read than comments tacked directly behind code.

That's getting into the taste area. I actually prefer comments in their own lines instead of trailing comments. But that is not something ipt can fix. Now of course we could a flag to keep comments, but until now we tried very hard to not have any knobs for the formatter. The reason is that the complexity of testing and documentation explodes with knobs. A bad example is clang-format (formatter for C++) where you even have tools like https://clang-format-configurator.site/ to help with writing the config file.

> - tabs for panel control elements being replaced without aligning equal signs (pos={}, size={} etc.). I have panel code also heavily aligned to make the code easily readable.

We try to always use recreation macros where the macro code is stored in separate files. So I rarely look at GUI code like that. I'll make a note.

> - equal signs of #pragma not being aligned

I need to think about this one.

Hello, I am one of the developers of this tool. First of all, I appreciate your feedback.

> - Apparently, ipt lint and ipt lint -i shows different output for my files (the latter showing MUCH more warnings). I guess this is intended, but I don't get it. Does the -i flag include a setting for a more limited set of checks?

I looked into the details. Apparently, if we have at least one warning or error for that specific file, nothing changes. We always try to have no warnings in our code, so this bug went unnoticed until now.

> First, I would like to note that ANSI escape code parsing is apparently switched off by default on windows which makes the output from this tool near unreadable.

Interesting, because on my Windows it worked right out of the box, so I didn't think much about it. But I use the modern Windows Terminal and VS code all the time. We can update our documentation to highlight this problem. The solution is to add `--color=no` to your arguments.

Thank you for the follow-up. Regarding the ANSI support, it may be that you have set everything up a long time ago to work with the terminal. I can have a look at another PC, but it initially didn't work ... neither with the terminal nor with Powershell both in ver. 5.1 or 7.5. I just tested it, and color=no works under these circumstances at least.

Another small thing: When there is a warning about a switch statement, the parser seems to include either the \r or \n or something else in the output. See the attached image.

In case a line termination (\r, \n or \r\n) is part of the code with error, we print a replacement character ⏎ [1] to the output. This is only visible if Windows is setup to use Unicode, which is unfortunately not the default and requires administrative changes [2]. I'll create an internal issue, so we can fix this and add some documentation.

[1]: https://www.compart.com/en/unicode/U+23CE

[2]: https://superuser.com/a/1435645

We fixed the ipt lint -i part. It may report some errors that cannot be fixed automatically, but it will always write the changes to the output file.

We also aligned the #pragmas at the top of the file.

To get the new ipt, download the latest release from our website. There is no update on winget yet.

Thank you for the update. Two comments from my side:

- I wonder how the list of warnings for linting is sorted. It seems to be roughly based on line number but not completely (sometimes it shows errors on a much earlier line before increasing again)?

- The ReadabilityMissingParenthesis warning produces two lines of output, one of them only the word 'here'; see the attachment.

> I wonder how the list of warnings for linting is sorted. It seems to be roughly based on line number but not completely (sometimes it shows errors on a much earlier line before increasing again)?

This order depends on certain conditions but is always deterministic. It is primarily influenced by the line numbers, though each rule that creates these warnings can also affect it. We have not added any logic to sort them by line. (Maybe we will.)

> The ReadabilityMissingParenthesis warning produces two lines of output, one of them only the word 'here'; see the attachment.

That's an interesting regression and the output should be different. I will look into it tomorrow.

> The ReadabilityMissingParenthesis warning produces two lines of output, one of them only the word 'here'; see the attachment.

This has been fixed and the newest ipt version (only available at our website) will create a correct error log.

The order of the errors is kept, but if you think a special one is needed, just write to me. I can also add a longer description to the documentation that explains the order.

Thank you for the update. The linter seems to output identical messages multiple times in some cases. See the attached files. I also think I have seen a case where there is no line break in-between two warning outputs (i.e., the messages are directly stitched together and the alignment is all off), but I can't seem to reproduce it at the moment.

Otherwise it works fine for me and I have already updated all my code to produce no warnings with the linter (while switching off three rules I personally do not want to follow strictly).

> The linter seems to output identical messages multiple times in some cases. See the attached files. I also think I have seen a case where there is no line break in-between two warning outputs (i.e., the messages are directly stitched together and the alignment is all off), but I can't seem to reproduce it at the moment.

Max is already looking into that.

> Otherwise it works fine for me and I have already updated all my code to produce no warnings with the linter (while switching off three rules I personally do not want to follow strictly).

Nice to hear that the linter works for you. Out of curiosity can you share which linter rules you have disabled?

Sure, I disable:

• CodeStyleDefaultPragmas

While this is no error, I don't want to use rtFunctionErrors=1. I am working completely alone on about 10 projects, and already debugging the usual code is a monumental task. I simply cannot afford to look for all these edge cases. The manual is very vague anyway about which errors to expect here.

• ReadabilityOneLineVariableInitialization

While I see the point, I don't want to follow this rule after all. For one, I often initialize the variables upon creating them and think having this on separate lines is a waste of space:

variable var1 = 0, var2 = 0, var3 = 0
string str1 = "", str2 = "", str3 = ""

Maybe it could be an exception to the rule that there is no warning if a string is followed by [= ""] only and a variable is followed by [= 0]. This would not discourage such initialization of variables.

Also, there are occasions where combining statements is better for readability (imho):

variable rows = DimSize(  data,0), cols = DimSize(  data,1), layr = DimSize(  data,2)
variable xoff = DimOffset(data,0), yoff = DimOffset(data,1), zoff = DimOffset(data,2)
variable xdel = DimDelta( data,0), ydel = DimDelta( data,1), zdel = DimDelta( data,2)

Yes, I could also spend 9 rows for above code, and maybe I will do that some day. Who knows...

Initially, I also switched off BugproneMissingSwitchDefaultClause, but in the end I decided to follow the rule, even if that meant just inserting many empty 'default' statements into the code.

We are currently in the final stages before the next release, which will include a fix for the duplicate log lines that you reported.

This issue was caused by a minor bug in the rule's internal state machine, which caused the rule to match multiple times.