Skip to content
AI Atlas
PaperActive

On the Relation between Code Quality and Machine Learning Performance: A Large-scale Empirical Study

arxiv.org/abs/2609.10610

quality89

Updated 2 h ago · first seen 11 Sept 2026

paper_01M294FPNZ5M82160GZS1R6H3C

Published
11 Sept 2026
T1 · 2 h ago
arXiv
2609.10610
T1 · 2 h ago
Category
cs.SE
T1 · 2 h ago

As of

Rewind the record: see this entity's attributes exactly as AI Atlas knew them on a given day.

Claim history

9 claims · 9 properties

Official pageofficial_url1

Claim history for Official page
ValueValid from → toStatusSourceConfidenceExtractor
https://arxiv.org/abs/2609.10610currentcurrentarXiv (Atom API + RSS)T1highdeterministic

Abstractabstract1

Claim history for Abstract
ValueValid from → toStatusSourceConfidenceExtractor
Context: Computational notebooks are the standard environment for machine learning (ML) development. Within the ML community, model performance is often the primary considered metric, and code quality is treated as a secondary concern. This prioritization relies on a largely untested assumption that code quality and ML performance are unrelated. Practitioners also reuse existing code that may come from notebooks selected through social signals (popularity, author expertise) whose reliability as quality proxies has never been assessed. Objective: We empirically investigated the relationship between code quality and ML performance in notebooks, and evaluated whether popularity and author expertise give indication on code quality or performance. Method: We conducted a large-scale empirical study of 265,363 Python notebooks submitted to Kaggle competitions. We assessed code quality with two static analysis tools: Pylint, capturing general Python code quality, and SonarQube, configured with a profile of 34 rules targeting data-science and ML-specific practices. Results: The relationship between code quality and performance depends on the notion of quality considered. General Python code quality is decoupled from ML performance, showing negligible or non-significant correlations across all observations. In contrast, ML-specific violations exhibit a consistent, small negative association with performance that persists across all observations. The popularity of a notebook does not give information on the code quality or performance. Code expertise provides no information on quality or performance, but competition expertise correlates with better performance, fewer ML-specific violations, and slightly more Python errors and refactoring violations.currentcurrentarXiv (Atom API + RSS)T1highdeterministic

Arxiv announce typearxiv_announce_type1

Claim history for Arxiv announce type
ValueValid from → toStatusSourceConfidenceExtractor
crosscurrentcurrentarXiv (Atom API + RSS)T1highdeterministic

arXiv idarxiv_id1

Claim history for arXiv id
ValueValid from → toStatusSourceConfidenceExtractor
2609.10610currentcurrentarXiv (Atom API + RSS)T1highdeterministic

Authorsauthors1

Claim history for Authors
ValueValid from → toStatusSourceConfidenceExtractor
Marius Mignard (CRIStAL), Steven Costiou (CRIStAL), Anne Etien (CRIStAL, EVREF)currentcurrentarXiv (Atom API + RSS)T1highdeterministic

Categoriescategories1

Claim history for Categories
ValueValid from → toStatusSourceConfidenceExtractor
cs.SE, cs.LGcurrentcurrentarXiv (Atom API + RSS)T1highdeterministic

PDFpdf_url1

Claim history for PDF
ValueValid from → toStatusSourceConfidenceExtractor
https://arxiv.org/pdf/2609.10610currentcurrentarXiv (Atom API + RSS)T1highdeterministic

Primary categoryprimary_category1

Claim history for Primary category
ValueValid from → toStatusSourceConfidenceExtractor
cs.SEcurrentcurrentarXiv (Atom API + RSS)T1highdeterministic

Publishedpublished_at1

Claim history for Published
ValueValid from → toStatusSourceConfidenceExtractor
11 Sept 2026currentcurrentarXiv (Atom API + RSS)T1highdeterministic

Claims are temporal and append-only: a new observation closes the previous claim (valid_to) instead of overwriting it. Conflicting claims from different sources are kept side by side and flagged — never averaged. Methodology →