Frontend
Code Lifespan Survival Analysis (CLSA): Predicting the Survival of Source Code Lines Using AST-Aware Mining
arXiv cs.SE0 views
arXiv:2606.04993v5 Announce Type: replace Abstract: Superseded by arXiv:2611.10530. Context: Predicting which source lines will be deleted - and when - matters for maintenance and review prioritization. Existing MSR approaches work at file or method granularity, masking individual-statement risk. Objective: We introduce Code Lifespan Survival Analysis (CLSA), the first framework to model individual-line deletion risk from covariates - where prior line-granularity work estimated lifespans but found no significant predictors. CLSA treats each line as a right-censored subject and estimates deletion risk from structural, contextual, and temporal covariates; its strongest predictors are computable statically from one file (AST structure plus line token count), without version history or bug data. Method: We mine 32.5 million line birth events from 120 open-source TypeScript repositories. A 5-stage matching pipeline separates true deletions from refactoring noise, preventing 8.3 million false deaths. We fit a Cox Proportional Hazards model with 15 covariates and check robustness via Weibull/Log-Logistic AFT, gamma frailty, and time-stratified landmark models. Results: The Kaplan-Meier median survival time is 1,335-1,352 days (about 3.7 years), verified on the full 32.5-million-line population and an independent resample; among deleted lines the median lifespan is 95.7 days. Line token count is a steady protective factor (HR=0.87) that stays essentially flat with age (HR 0.89-0.91 across regimes). Lines in conditional branches show no detectable effect at birth (HR=0.98, 0-90 days, not significant) but become a risk factor after 90 days (HR=1.23). Repository identity is the largest factor: a gamma frailty model (variance theta=1.451) raises concordance from 0.587 to 0.676. Conclusion: Line-level survival modeling is tractable, yielding interpretable risk signals and a calibration recipe for time-conditional scoring in IDEs and code review.
Source:https://arxiv.org/abs/2606.04993PreviousSACS: A Code Smell Dataset using Semi-automatic Generation ApproachNextWriting Bug Reports for Software Repair Agents: What Information Matters Most?
Related posts
Is Loop Engineering a New Technology, or Just Reheated Leftovers? Explained Through Training a Dog Classifier
0dev.to
UK AI Weekly: When AI Writes Faster Than Teams Can Think
0dev.to
Play the Sound in the Same Turn as the Tap: Pointer Events, AudioContext.resume and Why a click Listener Feels Late
0dev.to
Cognizant GenC Interview Questions for Freshers (2026): Test Pattern, SQL, Java, Coding and HR
0dev.to
Fail closed on captive Wi-Fi portals, Bluetooth pairing, and turn-by-turn navigation
0dev.to
TanCRAFT: Context-Reasoned Anticipatory Feedback for Assembly Tasks
0arXiv cs.RO