6 New rules to help C# developers write Azure Functions

[Tom_Howlett]

Hi .NET folks

Azure Functions are the most popular way for .NET developers to build scalable cloud applications. Our research shows that while they are fast to create, there are some traps that can make them difficult to maintain and scale efficiently, so we’ve created some rules that help you write clean Azure Functions, based on the Microsoft guidelines, that avoid those pitfalls from the outset.

The new rules are:

• Azure Functions should log all failures
• Calls to “async” methods should not be blocking in Azure Functions
• Azure Functions should use Structured Error Handling
• Reuse client instances rather than creating new ones with each Azure Function invocation
• Azure Functions should be stateless
• Azure Functions: Restrictions on entity interfaces

There are also some general improvements, bug fixes and improved support for the new C#10 deconstruction syntax. This update is available in SonarCloud now and in the forthcoming SonarQube 9.6 release.

We’d love to hear your feedback on these rules and anything else that could help you when creating Azure Functions.

Tom

[tiwahu (Timothy Huber)]

@Tom_Howlett

We’d love to hear your feedback on these rules…

The Compliant Solution example for Azure Functions should log all failures should have the exception as the first parameter (see ILogger overloads), otherwise it’s a parameter to the message template. (Ohhhh…you could have a rule for that, too! It happens too often in code I see.)

Something like this instead:

	catch (Exception ex)
	{
		log.LogError(ex, "Give details that will help investigations");
	}

[Tom_Howlett]

Hi Timothy

Welcome to the community and thank you for raising this. We’ll correct the docs soon. We also like your suggestions for an ILogger rule and will try and add something.

Thanks again

Tom