Pith. sign in

REVIEW 3 major objections 7 minor 27 references

How Do Code Smells Affect Skill Growth in Scratch Novice Programmers?

T0 review · 3 major / 7 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper aims to produce the first large-scale, fine-grained map between computational-thinking dimensions and code smells in novice Scratch projects.

desk verdict A clearly written registered report with a serious statistical plan, but the load-bearing sampling assumption is unverified and the CT/smell measurement overlap needs a sharper defense. read the letter →

arxiv 2507.17314 v2 pith:EJPKK4PW submitted 2025-07-23 cs.SE

Ricardo Hidalgo Aragón , Jesús M. González-Barahona , Gregorio Robles This is my paper · ORCID
classification cs.SE
keywords codesmellscomputationalthinkingScratchblock-basedprogrammingnoviceprogrammerssoftwaremaintenancerepositoryminingcorrelationanalysis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This is a registered study protocol, not an empirical report. The authors argue that block-based Scratch repositories make it possible to ask, at scale, whether the design flaws known as code smells track the development of computational thinking. They plan to mine roughly two million randomly sampled public Scratch projects, score each with nine computational-thinking dimensions and forty code-smell indicators from two linters, and test whether higher thinking scores predict lower smell density, which thinking skills best predict which smell families, and whether coding challenges change those relationships. If the plan works, the payoff is the first fine-grained, statistically powered atlas of how early design habits and thinking skills align, useful for curricula and automated feedback tools.

What carries the argument

The machinery is the combination of two automated static-analysis tools run on each .sb3 project: a nine-dimension computational-thinking rubric (abstraction, parallelism, logic, synchronisation, flow control, user interactivity, data representation, math operators, motion operators) and a catalogue of forty code-smell indicators, merged with per-project metadata into rows with normalized smell counts per block. The analysis is then carried by Spearman correlations and robust regression for the aggregate question, permutation mutual information and generalized linear models for dimension-smell specificity, and GLM interaction terms for task-context moderation, with FDR-corrected p-values and 5-fold cross-validation.

What would settle it

A complete enumeration of public Scratch project IDs, obtained by crawling the site directly or via an independent snapshot, compared against the ID histogram of the API-offset sample: any systematic under- or over-representation of ID ranges would demonstrate non-uniform sampling and refute the external-validity premise. Alternatively, if an independent replication using a full crawl finds no negative Spearman correlation between total CT score and normalized smell density at N = 2 million, the root claim would be refuted.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that a correlation map between computational thinking and code smells is both attainable and informative: with about two million projects, correlations down to |rho| = 0.05 can be detected with high power, and specific CT dimensions (for example, abstraction, flow control) should show distinctive associations with specific smell families (for example, duplicated scripts, busy waiting). The authors also claim that task context, meaning whether a project is a generic creation or a known coding challenge, may moderate these associations, and that separating context-driven smells from skill-driven smells is necessary before interpreting the map pedagogically. The paper states no results; it establishes the design, hypotheses, and expected evidence for the map.

Load-bearing premise

The paper assumes that querying the Scratch API with random offsets gives every public project an equal chance of being included, and it offers no calibration check; if the API search index truncates, sorts, or deduplicates results, the entire sample is biased and all correlations inherit that bias.

Editorial extensions

If this is right

  • Educators would gain an evidence-based ranking of which computational-thinking skills most strongly predict which design flaws, allowing lessons and automated feedback to target the highest-yield pairs.
  • The study would supply effect-size benchmarks from roughly two million projects, giving later intervention studies a baseline for what counts as a meaningful improvement in design quality.
  • If moderation holds, instructors could distinguish smells caused by challenge difficulty from smells caused by learner misconceptions, avoiding false conclusions about skill from hard tasks.
  • The open pseudonymised dataset and reproducible pipeline could seed longitudinal studies of skill growth and serve as a benchmark for smell-detection models.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper's stated scope, the same cross-sectional dataset could be sliced by project creation date per author to approximate longitudinal trajectories, testing whether smell density falls as an individual produces more projects.
  • If the promised negative correlation fails to appear at scale, that would itself be informative: it would suggest CT scores and code-smell detectors measure largely separate constructs, which would complicate but not void the pedagogical value of either.
  • An editor's reading: the map's usefulness as a feedback signal depends on the sampling assumption, so a cheap validation against an independent snapshot of the Scratch corpus would greatly strengthen the eventual conclusions.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 7 minor

Summary. This manuscript is a Stage-1 registered report for a large-scale repository-mining study. The proposed method is to sample approximately two million public Scratch projects through the Scratch REST API, analyze each project with DrScratch (nine computational-thinking dimensions, four smell indicators) and LitterBox (29 additional smell indicators), and then produce a statistical map of associations between computational-thinking (CT) competencies and code smells. The study is organized around three research questions: an aggregate association between overall CT score and overall smell density (RQ-1), dimension–smell specificity via mutual information and generalized linear models with FDR control and SHAP explanations (RQ-2), and task-context moderation by coding challenge vs. generic projects (RQ-3). The protocol also includes descriptive statistics, exploratory machine learning, a qualitative mini-case study, a power simulation, cross-validation claims, and an open replication package. No empirical results are presented; all claims about the study's contribution are prospective, and the scope note explicitly disclaims causal and longitudinal interpretation.

Significance. If the protocol executes as planned, the study would deliver a genuinely novel empirical artifact: a fine-grained, statistically powered map between nine CT dimensions and an extensive catalogue of design-level smell indicators in block-based novice code, together with effect-size benchmarks and an open pseudonymized dataset. Strengths of the manuscript include the explicit registered-report format with pre-stated hypotheses and a detailed analysis pipeline, a concrete power simulation justifying the target sample size, FDR control and cross-validation plans, the use of two independent linter families with version pinning, and a clear non-causal scope statement. The proposed moderation analysis (RQ-3) is a thoughtful way to separate learner-driven smells from task-induced patterns, and the replication package commitment is appropriate for this venue. However, the central external-validity premise—that random API offsets yield a uniform sample of the ~164M public projects—is asserted without calibration evidence, and the tooling design creates a circularity risk because DrScratch supplies both the CT scores and part of the smell counts.

major comments (3)
  1. [IV-B, V-C] The load-bearing sampling premise is unverified. The text states that 'Random API offsets guarantee an equal inclusion probability for each of the ≈164 M public projects,' but no evidence, reference, or calibration study is provided. Public search APIs commonly cap the maximum offset, apply implicit sort orders (e.g., by popularity or share date), truncate the index, or deduplicate results; any of these would silently reduce the effective sampling frame to a biased subset (e.g., recent or popular projects) and would propagate selection bias into every RQ-1/RQ-2 correlation and every RQ-3 moderation estimate. Section V-C merely reiterates the assumption ('we sample ~2M projects uniformly via API') rather than testing it. The protocol must add a verification step prior to acceptance: for example, (i) empirically probe the API for offset limits and check whether high offsets return results, (ii) compare the distribution of sampled project IDs and created_at timestamps against known population statistics from scratch.mit.edu/statistics, and (iii) specify a fallback sampling frame or a worst-case coverage bound. Without this, the headline claim of a 'random sample' cannot be accepted.
  2. [IV-C, V-A, Table II] Instrument overlap between the CT rubric and the smell detectors threatens RQ-1 and RQ-2 with mechanical correlation. DrScratch computes all nine CT scores and also detects four of the smell indicators (Duplicated Scripts, Dead code, Sprite naming, Backdrop naming), and several CT dimensions are defined over the same block features that LitterBox flags as smells (e.g., the Abstraction score reflects custom-block usage while LitterBox detects 'Unused Custom Block'; duplicated/identical blocks plausibly co-vary with the Abstraction and Data Representation sub-scores). If a CT dimension and a smell count share inputs by construction, a significant association is partially a property of the scoring tools rather than of novice skill. The planned mitigations—tool-version pinning, qualitative spot-checks, multi-tool triangulation—do not address this, because DrScratch is the only source of CT scores and the overlap is within that tool. The manuscript should enumerate for each of the nine CT dimensions which block features feed the score, list the smell–CT pairs that share those features, and pre-register a sensitivity analysis that excludes or adjusts for the mechanically overlapping pairs before interpreting the remaining associations as substantive evidence.
  3. [II (RQ-2), IV-E, IV-F] The statistical framing of RQ-2 makes its primary hypothesis trivially rejectable. The global null H0: I(d;s)=0 and β_d,s=0 for all 360 dimension–smell pairs will be rejected at N≈2M for effects of negligible practical size; the paper's own power analysis shows >99% power for |ρ|=0.05 at α=0.001, and far smaller per-pair effects will survive FDR correction at this sample size. As written, the test outcome is guaranteed to be 'significant' regardless of the data, which would make the promised fine-grained map uninterpretable as evidence for any specific CT–smell link. The protocol should pre-register a minimal practically relevant effect size or benchmark (e.g., a threshold on |β| or variance explained justified by educational relevance, or mutual information above the 95th percentile of its permutation null), and the deliverable should be framed as an effect-size atlas with confidence intervals rather than a significance list.
minor comments (7)
  1. [Abstract, I, II, IV-C, Table II] The manuscript refers repeatedly to '40 code smell indicators,' but the specification in Section IV-C and the enumeration in Table II give 4 DrScratch smells plus 29 LitterBox smells, totaling 33. Please correct the count or the catalogue and verify that all downstream mentions (abstract, Section I, Section II, Table V) are consistent.
  2. [Title, II (Scope note)] The title promises a study of 'Skill Growth,' but the scope note states that the design is cross-sectional with no time-series data and that 'development refers to relative proficiency inferred from completed projects.' The title and introduction should be aligned with the actual design (e.g., 'skill attainment' or 'skill level') to avoid promising longitudinal evidence the study cannot deliver.
  3. [IV-E, V-A, VI] The quantitative-qualitative plan is inconsistent: Section IV-E commits to a grounded-theory mini-case study on 30 projects (10 per extreme quantile), while Section V-A and Section VI state that ~385 projects will be qualitatively reviewed (at 95% confidence). Please state the single commitment and reconcile the budgets.
  4. [IV-E] The RQ-3 interaction coefficient is written as 'γ textCT×textContext' in the text; the stray 'text' substrings should be removed and the coefficient should be defined consistently as γ_CT×Context.
  5. [IV-F] The power analysis reports >99% power for N=1,000,000, but the target sample is ~2M. State the power at the target sample size and clarify how the planned FDR correction across 360 tests was or was not incorporated into the simulation.
  6. [IV-B, IV-F] For reproducibility of the 'random offsets' design, specify the random-number generator, seed, and an audit trail of the offset sequence; also fix the typographical stray apostrophe in 'remixed’s info' and clarify whether only the latest revision per project is stored.
  7. [References] Reference [15] (Lodi and Martini) lacks the venue, volume, and page numbers; please complete the bibliographic entry.

Circularity Check

1 steps flagged · score 6.0 of 10

Planned CT–smell map is partly self-definitional: CT dimensions and code smells are scored from the same block features, so some expected correlations are definitionally forced.

  1. self definitional [Section IV-C (Automated Feature Extraction), Table II, and Section II (RQ-2 expected evidence).]
    "DrScratch provides a nine-dimension rubric scored automatically from project code blocks: Abstraction, Parallelism, Logic, Synchronisation, Flow Control, User Interactivity, Data Representation, Math Operators, and Motion Operators. ... DrScratch: Computes 9 CT dimensions (extended rubric, 0–4 scale) and detects 4 structural code smells. ... Unused Custom Block(2) Unused Variable(2). ... Expected evidence: A ranked matrix showing, for instance, that low Abstraction scores coincide with cloning-related CS, whereas weak Flow Control relates to busy-waiting."

    Both CT scores and smell indicators are computed from the same .sb3 files. Under DrScratch's rubric, Abstraction is evidenced by custom blocks and Data Representation by variables/lists; LitterBox's 'Unused Custom Block' and 'Unused Variable' are defined on exactly those block types. A project with an unused variable necessarily contains a variable block, so it cannot have the lowest Data Representation score; a project with an unused custom block necessarily contains a custom block, so its Abstraction score is nonzero. Therefore the planned RQ-2 tests between these CT dimensions and these smells have a built-in positive association: the H0 of zero mutual information/coefficient is false by construction for those cells.

full rationale

This paper is a Stage-1 registered report, so there are no fitted parameters whose outputs are statistically forced by a fit. The §IV-B sampling premise (random API offsets give equal inclusion probability) is unverified but is a correctness/external-validity risk, not a circularity. The one circular element is the instrumental overlap between the independent and dependent measures: the nine DrScratch CT dimensions and the 40 smell indicators are extracted from the same project blocks, and for several pairs the constructs are coupled by definition (an 'Unused Variable' or 'Unused Custom Block' smell requires the corresponding block to exist, while DrScratch's Data Representation/Abstraction dimensions are awarded for use of those same block types). Consequently the planned RQ-2 correlation/mutual-information matrix will contain cells whose association is partly entailed by the rubrics rather than discovered, and the H0 of independence is not cleanly testable for those cells. This does not invalidate the entire study: most of the 40 smells (29 from LitterBox) are not definitionally coupled to CT dimensions, and the RQ-3 moderation analysis retains independent content, so the circularity is partial rather than total. The self-citations to the authors' prior DrScratch work ([3], [16], [20]) are used as tool motivation rather than as an unverified uniqueness theorem, and DrScratch is also supported by external validation [18], so those citations are not load-bearing circularity.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The ledger is a design audit: the paper introduces no new entities and fits no parameters, but its planned results depend on five domain assumptions, chiefly the validity of DrScratch scores, uniform API sampling, linter accuracy, regex challenge labels, and Scratch-as-novice proxy.

assumptions (5)
  • domain assumption DrScratch produces valid, reliable nine-dimensional computational-thinking scores.
    The study's main construct, CT, is operationalized entirely by DrScratch scores (Sections III-B and IV-C); validation cited in [18] shows only moderate agreement with expert ratings.
  • domain assumption The Scratch REST API search index can be uniformly randomly sampled via random offsets.
    Section IV-B claims random API offsets guarantee equal inclusion probability for each of approximately 164M public projects, but no evidence or API documentation is provided; search-index behavior may introduce selection bias.
  • domain assumption LitterBox and DrScratch smell detectors are sufficiently accurate for large-scale automated mining.
    Section V-E acknowledges tools may evolve or err and plans a manual audit of 385 projects, so detection accuracy is an unproved premise for the smell counts.
  • domain assumption Coding challenge labels (Arkanoid-like, Pac-Man-like) can be reliably identified by regex patterns and manual validation.
    Section IV-E and Table III plan context labels via regex plus manual validation; such labeling may be noisy and affects RQ3 moderation tests.
  • domain assumption Scratch usage is an acceptable proxy for novice-programmer status.
    Section I defines novices by Scratch's educational positioning because age metadata are unavailable; the paper acknowledges experienced developers also use Scratch.

how reviews work

0 comments
Cite this review

Pith. "Pith review of How Do Code Smells Affect Skill Growth in Scratch Novice Programmers?." pith.science (2026). https://pith.science/paper/EJPKK4PW

@misc{pith2026250717314,
  author       = {Pith},
  title        = {Pith review of: How Do Code Smells Affect Skill Growth in Scratch Novice Programmers?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EJPKK4PW}},
  note         = {Machine review of arXiv:2507.17314}
}
read the original abstract

Context. Code smells, which are recurring anomalies in design or style, have been extensively researched in professional code. However, their significance in block-based projects created by novices is still largely unknown. Block-based environments such as Scratch offer a unique, data-rich setting to examine how emergent design problems intersect with the cultivation of computational-thinking (CT) skills. Objective. This research explores the connection between CT proficiency and design-level code smells--issues that may hinder software maintenance and evolution--in programs created by Scratch developers. We seek to identify which CT dimensions align most strongly with which code smells and whether task context moderates those associations. Method. A random sample of aprox. 2 million public Scratch projects is mined. Using open-source linters, we extract nine CT scores and 40 code smell indicators from these projects. After rigorous pre-processing, we apply descriptive analytics, robust correlation tests, stratified cross-validation, and exploratory machine-learning models; qualitative spot-checks contextualize quantitative patterns. Impact. The study will deliver the first large-scale, fine-grained map linking specific CT competencies to concrete design flaws and antipatterns. Results are poised to (i) inform evidence-based curricula and automated feedback systems, (ii) provide effect-size benchmarks for future educational interventions, and (iii) supply an open, pseudonymized dataset and reproducible analysis pipeline for the research community. By clarifying how programming habits influence early skill acquisition, the work advances both computing-education theory and practical tooling for sustainable software maintenance and evolution.

Figures

Figures reproduced from arXiv: 2507.17314 by the authors.

Figure 1
Figure 1. End-to-end data-collection and analysis pipeline used in this [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

27 extracted references · 24 canonical work pages

  1. [1]

    The evolution and impact of code smells: A case study of two open source systems,

    S. Olbrich, D. S. Cruzes, V. Basili, and N. Zazworka, “The evolution and impact of code smells: A case study of two open source systems,” in2009 3rd International Symposium on Empirical Software Engineering and Measurement, 2009, pp. 390–400

    work page 2009

  2. [2]

    Currentresearchtrendsofscratchblockbasedprogram- ming for k-12: A systematic review,

    B. Batni, S. N. Junaini, J. Sidi, W. A. Mustafa, and Z. I. A. Ismail,“Currentresearchtrendsofscratchblockbasedprogram- ming for k-12: A systematic review,”Journal of Advanced Re- search in Applied Sciences and Engineering Technology, vol. 51, no. 2, pp. 138–152, 2025

    work page 2025

  3. [3]

    Bad smells in scratch projects: Prel. analysis,

    Á. Vargas-Alba, G. M. Troiano, Q. Chen, C. Harteveld, and G. Robles, “Bad smells in scratch projects: Prel. analysis,” in TACKLE@ EC-TEL, 2019

    work page 2019

  4. [4]

    Litterbox: A linter for scratch programs,

    G. Fraser, U. Heuer, N. Körber, F. Obermüller, and E. Was- meier, “Litterbox: A linter for scratch programs,” in2021 IEEE/ACM 43rd International Conference on Software Engi- neering: Software Engineering Ed. and Training (ICSE-SEET), 2021, pp. 183–188

    work page 2021

  5. [5]

    Scratch: programming for all,

    M. Resnick, J. Maloney, A. Monroy-Hernández, N. Rusk, E. Eastmond, K. Brennan, A. Millner, E. Rosenbaum, J. Silver, B. Silvermanet al., “Scratch: programming for all,”Communi- cations of the ACM, vol. 52, no. 11, pp. 60–67, 2009

    work page 2009

  6. [6]

    Remixing as a pathway to computational thinking,

    S. Dasgupta, W. Hale, A. Monroy-Hernández, and B. M. Hill, “Remixing as a pathway to computational thinking,” inPro- ceedings of the 19th ACM conference on computer-supported cooperative work & social computing, 2016, pp. 1438–1449

    work page 2016

  7. [7]

    Teaching Soft- ware Maintenance,

    K. Gallagher, M. Fioravanti, and S. Kozaitis, “Teaching Soft- ware Maintenance,” in2019 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 353–362

    work page

  8. [8]

    Smells in block- based programming languages,

    F. Hermans, K. T. Stolee, and D. Hoepelman, “Smells in block- based programming languages,” in2016 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC). IEEE, 2016, pp. 68–72

    work page 2016

Show all 27 references
  1. [9]

    Do code smells hamper novice programming? a controlled experiment on scratch programs,

    F. Hermans and E. Aivaloglou, “Do code smells hamper novice programming? a controlled experiment on scratch programs,” in2016 IEEE 24th International Conference on Program Com- prehension (ICPC). IEEE, 2016, pp. 1–10

    2016

  2. [10]

    A systematic mapping study of code quality in education–with complete bibliography,

    H. Keuning, J. Jeuring, and B. Heeren, “A systematic mapping study of code quality in education–with complete bibliography,” arXiv preprint arXiv:2304.13451, 2023

    2023 arXiv

  3. [11]

    Improving feedback in the automated assessment of programming assignments using students’ past solutions,

    J. C. C. Paiva, “Improving feedback in the automated assessment of programming assignments using students’ past solutions,” PhD thesis, University of Porto, 2025. [Online]. Available: https://repositorio-aberto.up.pt/bitstream/10216/ 165474/2/711241.pdf

    2025

  4. [12]

    Enhancing tertiary students’ program- ming skills with an expl. educational data mining approach,

    M.R.Islam,A.M.Nitu,M.A.Marjan,M.P.Uddin,M.I.Afjal, and M. A. A. Mamun, “Enhancing tertiary students’ program- ming skills with an expl. educational data mining approach,” PloS one, vol. 19, no. 9, p. e0307536, 2024

    2024

  5. [13]

    Block-based programming in computer science education,

    D. Weintrop, “Block-based programming in computer science education,”Communications of the ACM, vol. 62, no. 8, pp. 22–25, 2019

    2019

  6. [14]

    Analyzing computational thinking studies in scratch programming: A review of elementary edu- cation literature,

    W. Stewart and K. Baek, “Analyzing computational thinking studies in scratch programming: A review of elementary edu- cation literature,”International Journal of Computer Science Education in Schools, vol. 6, no. 1, pp. 35–58, 2023

    2023

  7. [15]

    Computational thinking, between papert and wing,

    M. Lodi and S. Martini, “Computational thinking, between papert and wing,” vol. 30, no. 4, pp. 883–908

  8. [16]

    Román-González, J

    M. Román-González, J. Moreno-León, and G. Robles,Com- bining Assessment Tools for a Comprehensive Evaluation of Computational Thinking Interventions. Springer, 2019, pp. 79– 100

    2019

  9. [17]

    Development and validation of a computational thinking test for lower primary school students,

    S. Zhang and G. K. W. Wong, “Development and validation of a computational thinking test for lower primary school students,” Educational Technology Research and Development, 2023

    2023

  10. [18]

    Ap- proaches to assess computational thinking competences based on code analysis in k-12 education: A systematic mapping study,

    N. D. C. Alves, C. G. Von Wangenheim, and J. C. Hauck, “Ap- proaches to assess computational thinking competences based on code analysis in k-12 education: A systematic mapping study,”Informatics in Education, vol. 18, no. 1, p. 17, 2019

    2019

  11. [19]

    Fowler,Refactoring: improving the design of existing code

    M. Fowler,Refactoring: improving the design of existing code. Addison-Wesley Professional, 2018

    2018

  12. [20]

    Automaticdetectionofbadprogram- ming habits in scratch: A preliminary study,

    J.MorenoandG.Robles,“Automaticdetectionofbadprogram- ming habits in scratch: A preliminary study,” in2014 IEEE Frontiers in Education Conference (FIE) Proceedings. IEEE, 2014, pp. 1–4

    2014

  13. [21]

    Unraveling the impact of code smell agglomerations on code stability,

    A. Santana, E. Figueiredo, and J. A. Pereira, “Unraveling the impact of code smell agglomerations on code stability,” in2024 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2024, pp. 461–473

    2024

  14. [22]

    Mining metrics to predict component failures,

    N. Nagappan, T. Ball, and A. Zeller, “Mining metrics to predict component failures,” inProceedings of the 28th international conference on Software engineering, 2006, pp. 452–461

    2006

  15. [23]

    Workflow analysis of data science code in public GitHub repos- itories,

    D. Ramasamy, C. Sarasua, A. Bacchelli, and A. Bernstein, “Workflow analysis of data science code in public GitHub repos- itories,”Empirical Software Engineering, vol. 28, no. 1, p. 7

  16. [24]

    Robust pairwise learning with huber loss,

    S. Huang and Q. Wu, “Robust pairwise learning with huber loss,”Journal of Complexity, vol. 66, p. 101570, Oct. 2021

    2021

  17. [25]

    Cohen,Statistical power analysis for the behavioral sciences

    J. Cohen,Statistical power analysis for the behavioral sciences. routledge, 2013

    2013

  18. [26]

    An introduction to the boot- strap,

    R. J. Tibshirani and B. Efron, “An introduction to the boot- strap,”Monographs on statistics and applied probability, vol. 57, no. 1, pp. 1–436, 1993

    1993

  19. [27]

    [Online]

    Empirical Standards - Repository Mining. [Online]. Available: https://www2.sigsoft.org/EmpiricalStandards/docs/standards

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.