IDE is suggesting that the command-line stub should be moved into main()

[tkirkland]

In my code, this is the code entry point:

However, if I moved this into main, then main would never get called. Further, it would cause an infinite recursion loop.

If this isn't related to BashSupport Pro, I apologize in advance.

[jansorg]

Thanks for reporting!

This message is shown because you enabled the use of the Google Shell Code Style.
Google's guide requires/recommends at https://google.github.io/styleguide/shellguide.html#main

The last non-comment line in the file should be a call to main:

That's why BashSupport Pro is currently not doing more extensive checks to hide the warning for cases like yours.
I'm considering to make a change for 5.x for less strict checking of the requirement.

What do you think?

[tkirkland]

I suspected it was the style guide. What I don't get is why it seems like the like the IDE is fighting with itself. See here:

In this particular code, these global vars are initialized at the beginning of the script (outside of main, because in my mind they are globals, so seems more logical than defining a global in a function) and as you can see, the IDE is unhappy. Yet, with these vars triggering the 'move to main' warning, the other warning:

is not no longer present. However, as soon as I attempt to address the first warning by relocating the vars, then the var warning disappears and the exec stub warning presents itself.

If both of these warnings are style guide related yet they cannot co-exist, that's perplexing. Or is it that the plugin will only show one of those types of warnings at a time? That's the part that had me going insane.

As far as

The last non-comment line in the file should be a call to main

this seems too literal, to be honest. I could see it if it said the last code block or similar, as there are valid cases where it makes more sense, is in my example, that it not be a literal single line, but a grouping that are handling one task, if that makes sense.

As far as having Bash Support be less stringent with its adherence to the style guide... Well, this is only my opinion, but if you start relaxing the rule sets, that seems counter-intuitive to having a guide in the first place. I suspect that in my specific case, it is my lack of the knowledge of the style guide that is the underlying issue.

Short answer: If the style guide is being a pain, let the user disable it. If they choose to use it, then they are agreeing to work within its constraints, that or live with the warnings... LOL. Don't degrade the functionality of a feature because of lack of knowledge on what the proper means to accomplish a task is. Again, just my opinion. Then, my OCD tendencies love structured environments.. hahah.

As I was tying this, I think I figured out the proper way:

Haha... Yes, I figured it out:

Moved global vars inside main, and reversed the stub logic. The only line outside of all functions:

So, indeed it was a lack of understanding of the style guide...

Personal opinion: That is seriously strict, possibly even overkill. It does align with my earlier statement:

If they choose to use it, then they are agreeing to work within its constraints

So it is a case of being a victim of my own choices... Hahaha.

not be a literal single line, but a grouping that are handling one task

I still stand by this, but that's a preference, and since I didn't write the style guide... :)

Thanks for replying! Feel free to close this after you read it.

[jansorg]

Thanks! I'll read this again later 🙂

The style guide is turned off by default. You must have turned it on in the code style settings of BashSupport Pro, as shown at https://www.bashsupport.com/manual/editor/formatter/ .

By default, the inspections related to the style guide only show warnings if the style guide setting is enabled.
If not, then it would be a serious bug.

Can you confirm that the setting is enabled in your settings?

[tkirkland]

I definitely enabled the linter—I fully support the idea of structured code layout. As I mentioned before, my main issue was not understanding what the linter expected, since that formatting style was unfamiliar to me. Interestingly, once I restructured my code accordingly, it made perfect sense. When you enable a linter, you're essentially agreeing to follow its coding standards—this was entirely my lack of knowledge..

The confusing part was the sequential nature of the warnings. When I moved a line to fix one warning, that warning would disappear, but then a new warning would appear elsewhere—almost as if fixing the first warning triggered the second one. In reality, both lines violated the style guide rules and should have shown warnings simultaneously.

What I expected was for all violations to be displayed at once, similar to how "variable could be local" warnings work—you see all of them together rather than discovering them one by one as you fix each issue.

Does this clarify what I'm trying to explain? I realize the nuance is difficult to convey in text, and potential language differences might make it even more challenging. I'll continue monitoring the thread if you need additional clarification. :)