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: 4 rules found
brain-overload
    Impact
      Clean code attribute
        1. Generic function type syntax should be preferred for parameters

           Code Smell
        2. Cognitive Complexity of functions should not be too high

           Code Smell
        3. Cyclomatic Complexity of functions should not be too high

           Code Smell
        4. Functions should not have too many parameters

           Code Smell

        Generic function type syntax should be preferred for parameters

        intentionality - clear
        maintainability
        Code Smell
        • brain-overload

        Function parameters of type "function" should be declared using generic function type syntax.

        Why is this an issue?

        How can I fix it?

        More Info

        There are two ways of defining a function or method parameter type, when such type is a flavor of Function that needs to be defined inline:

        • using the generic function syntax: void Function(int) parameterName
        • using the legacy function syntax: void parameterName(int)

        The first option should be preferred in all circumstances, for the following reasons:

        • readability
        • consistency

        Readability

        Unlike non-Function type, which always preceed the parameter name (e.g. int x, List<int> y, Map<String, double>? z, etc.), Function types expressed using the legacy syntax are intermingled with the parameter name. Specifically, part of the type, namely the return type of the Function, is placed before the parameter name, whereas the list of formal parameters of the Function is placed after.

        void aFunction(void parameterName(int functionParameterName)) {
            // ...
        }
        

        That makes the code harder to read and understand. For instance, it’s not easy to tell at a first glance that functionParameterName is not a parameter of aFunction, but a parameter of the Function parameter parameterName of aFunction.

        Consistency

        Pretty much like the function syntax, also the typedef syntax has two forms:

        • the generic typedef syntax: typedef void MyFunction(int);
        • the legacy typedef syntax: typedef MyFunction = void Function(int);

        The first option is more powerful and flexible, as explained in S5416.

        The generic typedef syntax matches syntactically the generic function syntax defined inline. Using syntaxes consistently allows easier code maintenance and refactoring.

        For example if an inline generic function syntax needs to be extracted into a generic typedef syntax, for its complexity, number of occurrences, or to be exposed outside the current library, the refactoring is easier and less error-prone, since the right-end side of the typedef is the same as the inline type definition.

        // Before extraction of typedef using generic syntax
        void aFunction(void Function(int functionParameterName) parameterName) {
            // ...
        }
        
        // After extraction of typedef using generic syntax
        typedef MyFunction = void Function(int functionParameterName);
        void aFunction(MyFunction parameterName) {
            // ...
        }
        

        The same is not true for the legacy syntax:

        // Before extraction of typedef using legacy syntax
        void aFunction(void parameterName(int functionParameterName)) {
            // ...
        }
        
        // After extraction of typedef using legacy syntax
        typedef void MyFunction(int functionParameterName);
        void aFunction(MyFunction parameterName) {
            // ...
        }
        
          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