How to temporarily turn off a rule?

[Philip_Colmer]

I’m using SonarLint with VS Code against Python code.

I’m hitting a situation where a rule is flagging up a warning on my code, specifically S107 - too many parameters. The problem I’ve got is that I’m writing a wrapper function before calling someone else’s code, and I need to pass a number of parameters to that secondary function … so I really can’t alter how many parameters I have in my own function.

Is there any mechanism that I can use to mark up that code so that SonarLint ignores S107 against that specific function?

Thanks.

[Nicolas_Harraudeau]

Hi @Philip_Colmer,

Sorry for the far too long reply. You can add a #NOSONAR comment in your code or, if you use SonarLint with SonarQube or SonarCloud, you can mark the issue as “Won’t Fix” and connect your SobarLint to SonarQube and SonarCloud.

By the way I am currently reviewing this rule to see if it raises False Positives and improve it. I know it was a long time ago but I have one question, why isn’t it possible to use keywords argument and unpacking. That way you don’t have to update your function every time the wrapped function adds or removes arguments.

[Philip_Colmer]

Hi @Nicolas_Harraudeau

Apologies for the late reply to your reply!

With regards to your question, first I should explain that I’m not the strongest Python programmer, so there may well be a better way of doing things, but this is how my code stands at the moment:

def register_task_with_maintenance_window(
       profile_name, region, window_id, targets,
       task_arn, service_role_arn, task_type,
       task_invocation_parameters, max_concurrency,
       max_errors, task_name):
   ssm = get_ssm_client(profile_name, region)
   ssm.register_task_with_maintenance_window(
       WindowId=window_id,
       Targets=targets,
       TaskArn=task_arn,
       ServiceRoleArn=service_role_arn,
       TaskType=task_type,
       TaskInvocationParameters=task_invocation_parameters,
       MaxConcurrency=max_concurrency,
       MaxErrors=max_errors,
       Name=task_name
   )

ssm.register_task_with_maintenance_window is a library call provided by AWS as part of their Boto library, so I have no control over that.

The reason for the function is because I’ve separated out all of the AWS calls in my code into a separate module, so the “parent” code has no direct AWS calls itself.

If there is a Pythonic way of safely reducing the number of parameters to the function without making it too hard to read and understand, I’d be up for learning

Thank you.

[Nicolas_Harraudeau]

Hi @Philip_Colmer,

The easiest solution would be to use *args and **kwargs but it would break your API because it renames the parameters to use those of register_task_with_maintenance_window .

def register_task_with_maintenance_window(
       profile_name, region, *args, **kwargs):
   ssm = get_ssm_client(profile_name, region)
   ssm.register_task_with_maintenance_window(*args, **kwargs)

You would have to pass arguments named WindowId instead of window_id. Breaking an API is not ideal, luckily there will soon be an alternative as I suggested a few modifications to rule S107.

Rule S107 raises many issues on well known python projects. In this case it would even raise on AWS boto. In python it is common for functions/methods to have many parameters, but most of them are optional. We can see this pattern with method register_task_with_maintenance_window. Only 6 parameters are mandatory, the rest are optional.

I recently created ticket SONARPY-719 to increase the default max number of total arguments and specified rule RSPEC-5878 which will raise when a function has too many mandatory parameters.
Once these changes are implemented you could simply add default values to optional parameters.

In the meantime I recommend to already increase the max number of parameters for rule S107.

Does this answer your question?

Nicolas

[Philip_Colmer]

Very helpful, @Nicolas_Harraudeau. Thank you.