Write Quality Comprehensions & Coroutines with SonarQube

Sonar Updates Discussions
1

Hi pythonistas,

We have just added a whopping 33 new rules for Python, expanding the depth and breadth of our analysis of comprehensions and asynchronous code usage. They are available now on SonarQube Cloud and will be available in the next SonarQube Server and SonarQube IDE releases.

Coroutines Rules:
Asynchronous programming with coroutines are great for building responsive and scalable applications. Our new rules target common pitfalls to help you write more robust, efficient and maintainable async code:

  • S7483: Asynchronous functions should not accept timeout parameters
  • S7484: Events should be used instead of sleep in asynchronous loops
  • S7486: Long sleep durations should use sleep_forever() instead of arbitrary intervals
  • S7487: Async functions should not contain synchronous subprocess calls
  • S7488: Use non-blocking sleep functions in asynchronous code
  • S7489: Async functions should not contain synchronous OS calls
  • S7490: Cancellation scopes should contain checkpoints
  • S7491: Checkpoints should be used instead of sleep(0)
  • S7493: Async functions should not contain synchronous file operations
  • S7497: Cancellation exceptions should be re-raised after cleanup
  • S7499: Async functions should not contain synchronous HTTP client calls
  • S7501: Async functions should not contain input() calls
  • S7502: Asyncio tasks should be saved to prevent premature garbage collection
  • S7503: Async functions should use async features
  • S7513: TaskGroup/Nursery should not be used for a single start call
  • S7514: Control flow statements should not be used inside TaskGroup or Nursery blocks
  • S7515: “async with” should be used for asynchronous resource management

We have also provided IDE quick-fixes for these rules:

  • S7486: Long sleep durations should use sleep_forever() instead of arbitrary intervals
  • S7489: Async functions should not contain synchronous OS calls
  • S7491: Checkpoints should be used instead of sleep(0)
  • S7501: Async functions should not contain input() calls

Comprehensions Rules:
We all love comprehensions for their conciseness and expressiveness, however they can often lead to less readable and inefficient code if not used thoughtfully and these rules should help you along:

  • S7492: List comprehensions should not be used with “any()” or “all()”
  • S7494: Comprehensions should be used instead of constructors around generator expressions
  • S7496: Creation of collections with literals or comprehensions should not be wrapped in type constructors
  • S7498: Literal syntax should be preferred when creating empty collections or dictionaries with keyword arguments
  • S7500: Comprehensions only used to copy should be replaced with the respective constructor calls
  • S7504: When iterating over an iterable object, using “list()” should be avoided
  • S7505: Generators and comprehensions should be preferred over the usage of “map” and “lambda” when creating collection
  • S7506: Dictionary comprehension should not use a static key
  • S7507: “defaultdict” should not be initialized with “default_factory” as a keyword argument
  • S7508: Redundant collection functions should be avoided
  • S7510: The “sorted” function call should not be passed to the “reversed” function as an argument
  • S7511: Passing a reversed iterable to “set()”, “sorted()”, or “reversed()” should be avoided
  • S7512: Using “.items()” to iterate over a dictionary should be avoided if possible.
  • S7516: “sorted” should not be wrapped directly inside “set”
  • S7517: Iteration over a dictionary key value pairs should be done with the items() method call
  • S7519: Populating a dictionary with a constant value should be done with dict.fromkeys() method call

We have also provided IDE quick-fixes for these rules:

  • S7498: Literal syntax should be preferred when creating empty collections or dictionaries with keyword arguments
  • S7500: Comprehensions only used to copy should be replaced with the respective constructor calls
  • S7504: When iterating over an iterable object, using “list()” should be avoided
  • S7508: Redundant collection functions should be avoided
  • S7517: Iteration over a dictionary key value pairs should be done with the items() method call

We hope you enjoy these rules, and we’d love your feedback - please add them below. You can also take a look at what’s coming next in our SonarQube Server and SonarQube Cloud roadmaps.

Jean