SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
Dart

Dart static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your DART code

  • All rules 126
  • Vulnerability4
  • Bug15
  • Security Hotspot8
  • Code Smell99
Filtered: 5 rules found
performance
    Impact
      Clean code attribute
        1. Literal constructors parameters of @immutable classes should be const

           Code Smell
        2. @immutable classes should only have const constructors

           Code Smell
        3. Unnecessary use of "toList" with spread operator

           Code Smell
        4. For elements should be preferred to Map.fromIterable

           Code Smell
        5. "static final" declarations should be "const" instead

           Code Smell

        Literal constructors parameters of @immutable classes should be const

        intentionality - efficient
        maintainability
        Code Smell
        • performance

        A literal used as an argument to a constructor of an @immutable class should be marked as const.

        Why is this an issue?

        How can I fix it?

        More Info

        The meta.dart package defines an @immutable annotation that can be used to mark classes that are immutable, meaning that all their instance variables, directly defined or inherited, have to be final, that is, once the instance is created, it cannot be modified.

        However, like any other annotation, the @immutable annotation only provides information to the developer using the class and to developer tools such as the analyzer package, and it does not enforce any constraint.

        Therefore, there is nothing that prevents a developer from

        • defining a non-const constructor of an @immutable class (named or unnamed)
        • passing non-const literals to such a constructor

        An example is shown in the code below:

        import 'package:meta/meta.dart';
        
        @immutable
        class MultiDimensionalPoint {
          final List<int> coordinates;
          MultiDimensionalPoint(this.coordinates); // Non-const constructor
        }
        
        void main() {
          var p = MultiDimensionalPoint([1, 2, 3]);
          p.coordinates[0] = 4; // This is allowed, and won't raise any error
          print(p.coordinates); // Will print [4, 2, 3]
        }
        

        This scenario can lead to confusion and bugs, since a developer might not realized the class is designed with immutability in mind, and may modify the instance after creation, as in the example above.

        Even when the immutability design constraint is respected, failing to specify the const constraint on a literal used as an argument to a constructor of an @immutable class will lead to subpar performance, as the Dart compiler will not create compile-time constants in a non-constant context.

        Exceptions

        Notice that the const constraint is not required when the literal is used in a const context, as the Dart compiler is already building a compile-time constant for a larger expression including the object, and a compile-time constant can only be built of other compile-time constants. See rule S7112 for further details about why it’s important to call const constructors with the const keyword or in a const context.

        Rule S7113 helps in this regard, by enforcing the const constraint on the constructor itself, which in turns will oblige all constructor parameters to be const, whether they are literals or not.

        import 'package:meta/meta.dart';
        
        @immutable
        class MultiDimensionalPoint {
          final List<int> coordinates;
          const MultiDimensionalPoint(this.coordinates); // Const constructor
        }
        
        void main() {
          const p1 = MultiDimensionalPoint([1, 2, 3]); // [1, 2, 3] will be const since it's used in a const context
          var p2 = const MultiDimensionalPoint([1, 2, 3]); // [1, 2, 3] will be const since it's used in a const context
        }
        
          Available In:
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          10.8

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use