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
  • GroovyGroovy
  • 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
Python

Python static code analysis

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

  • All rules 414
  • Vulnerability45
  • Bug104
  • Security Hotspot50
  • Code Smell215

  • Quick Fix 33
Filtered: 24 rules found
data-science
    Impact
      Clean code attribute
        1. "master" and "appName" should be set when constructing PySpark "SparkContext"s and "SparkSession"s

           Code Smell
        2. PySpark's "RDD.groupByKey", when used in conjunction with "RDD.mapValues" with a commutative and associative operation, should be replaced by "RDD.reduceByKey"

           Code Smell
        3. PySpark's "DataFrame" column names should be unique

           Code Smell
        4. PySpark "dropDuplicates" subset argument should not be provided with an empty list

           Code Smell
        5. Complex logic provided to PySpark "withColumn", "filter" and "when" methods should be refactored into separate expressions

           Code Smell
        6. PySpark lit(None) should be used when populating empty columns

           Code Smell
        7. PySpark DataFrame toPandas function should be avoided

           Code Smell
        8. The "how" parameter should be specified when joining two PySpark DataFrames

           Code Smell
        9. "withColumns" method should be preferred over "withColumn" when multiple columns are specified

           Code Smell
        10. PySpark DataFrames used multiple times should be cached or persisted

           Code Smell
        11. PySpark Pandas DataFrame columns should not use a reserved name

           Code Smell
        12. The "subset" argument should be provided when using PySpark DataFrame "dropDuplicates" method

           Code Smell
        13. PySpark Window functions should always specify a frame

           Code Smell
        14. pandas.pipe method should be preferred over long chains of instructions

           Code Smell
        15. The "pandas.DataFrame.to_numpy()" method should be preferred to the "pandas.DataFrame.values" attribute

           Code Smell
        16. 'dtype' parameter should be provided when using 'pandas.read_csv' or 'pandas.read_table'

           Code Smell
        17. When using pandas.merge or pandas.join, the parameters on, how and validate should be provided

           Code Smell
        18. inplace=True should not be used when modifying a Pandas DataFrame

           Code Smell
        19. Deprecated NumPy aliases of built-in types should not be used

           Code Smell
        20. np.nonzero should be preferred over np.where when only the condition parameter is set

           Code Smell
        21. Passing a list to np.array should be preferred over passing a generator

           Code Smell
        22. numpy.random.Generator should be preferred to numpy.random.RandomState

           Code Smell
        23. Results that depend on random number generation should be reproducible

           Code Smell
        24. Floating point numbers should not be tested for equality

           Bug

        inplace=True should not be used when modifying a Pandas DataFrame

        consistency - conventional
        maintainability
        reliability
        Code Smell
        • pandas
        • data-science

        This rule raises an issue when the inplace parameter is set to True when modifying a Pandas DataFrame.

        Why is this an issue?

        How can I fix it?

        More Info

        Using inplace=True when modifying a Pandas DataFrame means that the method will modify the DataFrame in place, rather than returning a new object:

        df.an_operation(inplace=True)
        

        When inplace is False (which is the default behavior), a new object is returned instead:

        df2 = df.an_operation(inplace=False)
        

        Generally speaking, the motivation for modifying an object in place is to improve efficiency by avoiding the creation of a copy of the original object. Unfortunately, many methods supporting the inplace keyword either cannot actually be done inplace, or make a copy as a consequence of the operations they perform, regardless of whether inplace is True or not. For example, the following methods can never operate in place:

        • drop (dropping rows)
        • dropna
        • drop_duplicates
        • sort_values
        • sort_index
        • eval
        • query

        Because of this, expecting efficiency gains through the use of inplace=True is not reliable.

        Additionally, using inplace=True may trigger a SettingWithCopyWarning and make the overall intention of the code unclear. In the following example, modifying df2 will not modify the original df dataframe, and a warning will be raised:

        df = pd.DataFrame({'a': [3, 2, 1], 'b': ['x', 'y', 'z']})
        
        df2 = df[df['a'] > 1]
        df2['b'].replace({'x': 'abc'}, inplace=True)
        # SettingWithCopyWarning:
        # A value is trying to be set on a copy of a slice from a DataFrame
        

        In general, side effects such as object mutation may be the source of subtle bugs and explicit reassignment is considered safer.

        When intermediate results are not needed, method chaining is a more explicit alternative to the inplace parameter. For instance, one may write:

        df.drop('City', axis=1, inplace=True)
        df.sort_values('Name', inplace=True)
        df.reset_index(drop=True, inplace=True)
        

        Through method chaining, this previous example may be rewritten as:

        result = df.drop('City', axis=1).sort_values('Name').reset_index(drop=True)
        

        For these reasons, it is therefore recommended to avoid using inplace=True in favor of more explicit and less error-prone alternatives.

          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube Community BuildAnalyze code in your
          on-premise CI
          Available Since
          10.3
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          10.3

        © 2026 SonarSource Sàrl. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use