New Code Smell Suggestion: await inside loops

I would like to suggest a new code smell: the await inside a regular loop.

I believe that this could be refactor in several ways, both maintaining the (possibly) desired “relief of load” on the other end AND allowing parallel execution

Hi Leonardo,

Thank you for this suggestion. Do you see specific contexts in which this rule wouldn’t apply?
It seems to me that when the async operations are in batches (ex: for throttling) it can make sense to call await on each batch in a loop.

When we design a rule we need to make sure that it won’t raise too much noise, i.e. False Positives.

Cheers,
Nicolas

Hi Nicolas,
Sorry for the delay.

Someone will always come up with a scenario that “makes sense” but I strongly believe that you can refactor the await out of the loop. For the batch scenario, for example, I would use a stack for controlling the batches, and a recursive method triggered on the “ContinueWith”…

Looking around I actually came with another problem: there’s a rule that says that “myTask.Result” should be replaced with “await myTask”, even if you awaited for it before… how should this be handled?

Hi @Leonardo-Ferreira,

Looking around I actually came with another problem: there’s a rule that says that “myTask.Result” should be replaced with “await myTask”, even if you awaited for it before… how should this be handled?

which rule are you talking about and why? could you provide some code examples to demonstrate your ideas?

Does the rule you suggest correspond to https://eslint.org/docs/rules/no-await-in-loop?

Hello Elena,
Yes, the eslint rule you mentioned is exactly what I mean!

the other rule I was talking about is https://rules.sonarsource.com/csharp/RSPEC-3216. You see, “ConfigureAwait” makes no sense at all in .net core. It is there for the sole purpose of backward compatibility.

I don’t get, are we talking about TS or C# here? Let’s consider one thing at a time.

For no-await-in-loop I got your point.

FYI we currently migrating our SonarJS/SonarTS analyzers to be based on ESLint frontend. When we will be done, we will go through ESLint core rules to see if we want to have some of them in SQ.

my bad! I’m talking about C# here!

Could you create a new thread for C#?