Victorien Elvinger

> The Perf group should be called Performance. Abbreviations should be avoided whenever possible. I am wondering if several rules should follow the same path: [noDupeArgs](https://docs.rome.tools/lint/rules/noDupeArgs) -> noDuplicatedFunctionParameters [noDupeKeys](https://docs.rome.tools/lint/rules/noDupeKeys) ->...

> Arguments and parameters are not the same thing Could you develop about that? `Arguments` could be confusing because of js implicit `arguments` variable. By the way, I assimilate arguments...

I could also suggest adding `Function` in the name, such as `noDuplicateFunctionParameters`, in order to distinguish them from generic parameters.

@MichaReiser > This rule has overlaps with the UseSingleCaseStatement. What's your recommendation on how these rules should (or should not) co-exist? I could suggest removing `useSingleCaseStatement` of the recommended rule...

> ```js > for (let a = 0; a < 10; a+= 5) {} > ``` Thanks for the suggestion! I will add this case. > ```js > const f...

@leops Thanks for the info, I did not notice this rule. I could suggest of removing `noConditionalAssignment` from the recommended rule set. And so waiting for potential user feedback of...

By the way, I could add the code action of `noConditionalAssignment`. EDIT: done.

@leops done :)

> As I understand it, having rules clearly identified as unstable would allow us to make important changes in the way those rules work without having to worry too much...

I updated the branch. I relaxed the rule for one more case: multiple initialization. The following code is now allowed: ```js let a, b; a = b = 1; ```