Pith. sign in

REVIEW 6 major objections 7 minor 25 references

Extract Method Refactoring by Successive Edge Contraction

T0 review · 6 major / 7 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read The paper claims that successive edge contraction on a Structure Dependence Graph identifies extract-method opportunities automatically, matching developer-marked splits on two of three open-source benchmarks.

desk verdict A concrete graph-contraction algorithm for extract method refactoring that beats JDeodorant on two benchmarks, but per-project parameter tuning limits the strength of the evaluation. read the letter →

arxiv 1908.04636 v1 pith:FHE6XTOJ submitted 2019-08-13 cs.SE

Omkarendra Tiwari , Rushikesh K. Joshi This is my paper · ORCID
classification cs.SE
keywords extractmethodrefactoringlongmethodsstructuredependencegraphsegmentIRedgecontractiondatacontrolsoftwarerestructuring
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

Segmentation treats a long method as a structure dependence graph and shrinks it by repeatedly contracting three kinds of edges: control edges of an internal block, exclusive data-supply edges from source vertices, and sequential data-dependence chains. The paper claims the resulting segments are cohesive, functionally distinct units that a developer would choose to extract as methods, and that two affinity metrics—lack of computational strength (LoCS) and parent affinity (PA)—decide which blocks to extract and which to merge with their parent. Because the source code is first translated into a small language-independent segment IR, the same graph machinery applies to C and to Java. On the three open-source case studies, segmentation matches developer-marked opportunities better than JDeodorant on JHotDraw and XData, and markedly better on methods over 150 lines; on JUnit, JDeodorant remains ahead.

What carries the argument

The load-bearing object is the Structure Dependence Graph (SDG), a directed graph whose vertices are segment-IR statements and whose labeled edges represent structural control dependence (hierarchical 'C' edges from a control statement to the statements it directly encloses) and data dependence ('D' edges from the statement that defines a variable to every statement that uses it). The segmentation algorithm shrinks this graph into a segment graph through three edge contractions: control edge contraction collapses a qualifying control block into one vertex; exclusive source contraction merges a source vertex whose single outgoing data edge feeds that block; and sequential data dependence contraction merges incoming and outgoing data chains that lie in the same control region. Two metrics drive the choices: lack of computational strength (LoCS), the ratio of relay vertices to the total count of data supplies reaching them, judged against a threshold of 0.41; and parent affinity (PA), the share of a parent block's producer vertices not directly tied to the contracted inner block, judged against a threshold of 0.34. The segment IR, which encodes only operation primitives, block sizes, and variable roles, is what keeps the pipeline language independent.

What would settle it

Construct a method with two developer-distinct functionalities inside a single if-block, where the first computes a value consumed only by the second, and run segmentation on it. Under the paper's definition the subgraph containing that same-region data edge is not data independent, so the algorithm should fail to propose the developer-marked split; finding such a method in a benchmark and observing that failure would settle the central claim.

Watch

Extended reading notes

Core claim

The paper's central claim is that distinct functionalities inside a method correspond to subgraphs of the Structure Dependence Graph (SDG) that are both control independent and data independent, and that such subgraphs can be found by successively contracting edges. A candidate block is kept as a separate function when its lack of computational strength falls below a learned threshold, and is merged into its parent when parent affinity falls below a second threshold; the remaining contractions absorb exclusive data sources and sequential chains. The algorithm reports the surviving vertices of the segment graph as extract method opportunities, ranks them, and lists alternative segment variants for a developer to override. The evaluation asserts that this reproduces the original methods in a synthetically unfolded implementation of the algorithm itself, and that on the open-source benchmarks it beats JDeodorant in precision and recall on JHotDraw and XData while remaining competitive on long methods.

Load-bearing premise

The whole approach rests on assuming that two statements exchanging data while sitting in the same control block always belong to the same functionality. If real code ever has same-block data flows that cross a natural functional boundary, the data-independence definition either merges unrelated statements or blocks a valid extraction, and the paper never validates this assumption on its own.

Editorial extensions

If this is right

  • Extract-method suggestions can be produced from dependence structure alone, without asking the developer for seed statements or variables, leaving the human role as approving or overriding ranked segments.
  • The language-independent segment IR means the segmentation logic can be reused across languages by writing a front end that emits segment IR.
  • Thresholds tuned on one codebase transferred to JUnit, JHotDraw, and XData with only one per-project flag changed, suggesting the LoCS and PA metrics capture a general notion of functional cohesion.
  • On methods longer than 150 lines, segmentation matched developer-marked splits with recall above 50 percent while JDeodorant matched none, so the approach applies where manual restructuring is most costly.
  • Ranked segments with listed alternatives let the tool behave as an assistant that can present several refactoring options instead of committing to one extraction.

Reading between the lines

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

  • Editorial inference: the data-independence definition makes same-control-region data flows invisible to splitting, so a method in which two distinct features share a block and exchange a value inside that block could never be proposed as two separate methods; this is a testable limitation, not a result the paper reports.
  • Editorial inference: the threshold values 0.41 and 0.34 were tuned on a single C program and then applied to Java unchanged, so one would expect language idioms such as try-catch blocks and anonymous classes to shift the optimal settings; the paper itself notes anonymous inner classes were missed.
  • Editorial inference: the evaluation compares final segment suggestions with developer markings, not the intermediate segment graph, so a stronger test would ask developers whether each intermediate segment corresponds to a meaningful subtask.
  • Editorial inference: a direct extension suggested by the method is to treat call sites as virtual data flows and run the same contraction machinery interprocedurally, a direction the paper's conclusion lists as future work.
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

6 major / 7 minor

Summary. This paper proposes 'segmentation,' a successive-edge-contraction technique applied to a Structure Dependence Graph (SDG) to identify extract-method opportunities in long methods. The SDG is built from a language-independent intermediate representation (segment IR), and the algorithm reduces the SDG to a segment graph through three activities: control edge contraction (CEC), exclusive source contraction (ESC), and sequential data dependence contraction (SDDC). Two metrics, lack of computational strength (LoCS) and parent affinity (PA), gated by thresholds 0.41 and 0.34, decide which control blocks qualify for contraction; a flag NoRelayExtract modifies the treatment of blocks that lack relay vertices. The approach is evaluated on four case studies: a synthetic C program constructed by de-modularizing the authors' own implementation, and three open-source Java projects (JUnit, JHotDraw, XData). Suggested segmentations are compared against developer markings and against JDeodorant using precision, recall, and F-measure at match tolerances of one to three statements. The authors report that segmentation outperforms JDeodorant on JHotDraw and XData and on methods over 150 LOC, while JDeodorant performs better on JUnit.

Significance. If the empirical claims held under a fixed configuration, this would be a useful contribution to program refactoring. The segment-IR/SDG framework is language-independent; the contraction algorithm is deterministic and is illustrated with a fully worked example; the evaluation uses established public benchmarks (JUnit and JHotDraw as prepared by Silva et al.) and a comparison with the well-known JDeodorant tool; and the paper is transparent about its parameters and about the per-project flag adjustments. The most interesting claim, that the approach works on methods over 150 LOC where JDeodorant fails, would be valuable if substantiated. However, the evaluation's validity is currently compromised by post hoc parameter selection, and the data-independence premise underlying the segment model is never independently validated. The strength of the reported comparison is therefore conditional on additional analysis.

major comments (6)
  1. [Sections VII-B, VII-C; Tables VI-X] The headline comparison with JDeodorant is not a comparison of a fixed algorithm. The LoCS threshold 0.41 and the PA threshold 0.34 are selected on a single synthetic case study built from the authors' own segmentation implementation (Section VII-B), and the NoRelayExtract flag is then set to True for JUnit and JHotDraw and to False for XData, after the paper reports that the default setting extracts nothing for JUnit (Section VII-C). Table VIII shows how much this tuning matters: for JHotDraw at tolerance 1, recall drops from 19.64 to 5.35 when the flag is flipped. To make the outperformance claims load-bearing, the paper should report results under a single configuration chosen without knowledge of the test projects (or with an explicit train/test split) and should include a sensitivity analysis of the two thresholds and of the flag over a plausible range.
  2. [Section IV-B] The data-independence criterion forbids any subgraph boundary at which a data edge connects two vertices in the same control region, thereby equating same-control-region data exchange with shared functionality. This is a strong structural assumption: two extractable sub-computations in one control block that share a single data value can never be separated, and a cross-region supplier may be excluded from a segment even when it implements the same functionality. The paper provides no independent check of this premise; the evaluation compares only final suggestions against developer markings (Section VII-A), so a wrong intermediate model could in principle be masked by the tuned thresholds and flag. The paper should add a boundary-edge analysis on the three benchmarks: for each developer-marked extraction boundary, report the fraction of cut data edges whose endpoints share a control region. That test would either validate the premise or quantify how often it forces over-merging.
  3. [Section VI-A2; Procedure 2] The PA metric is defined as PA = 1 - IndependentNodes/ParentDataNodes, so larger PA corresponds to a parent whose data vertices are more connected to the inner block, i.e., higher affinity; yet the decision rule merges only when PA is below the threshold. In the Section VI-A2 example, a parent with three of five producer vertices independent of the inner block gets PA = 0.4 and the merger is declined because 0.4 > 0.34, which implies that a merger requires the parent to be at least about two-thirds independent. This direction conflicts with the metric's name and with cases (i) and (iii) of the same subsection, which merge blocks on close association. The paper should state whether PA measures affinity or independence and should make the formula, the threshold, and the example mutually consistent.
  4. [Section VI-C1 vs. Section III-E4] The contraction rules are internally inconsistent. Section III-E4 states that edge contraction is not permitted when the head and tail vertices of a data edge belong to different control regions, and Section VI-C describes truncating chains at control-region borders. Section VI-C1 then instructs that a unit outgoing chain such as edge <4,6> in Figure 7 be merged into the target block even though vertex 4 lies inside the loop (control region 2) and vertex 6 lies outside it (region -1). The paper should reconcile these statements, for example by specifying which cross-region contractions are behavior-preserving (such as merging sink statements) and by formulating the general rule precisely.
  5. [Section VII-C; Table XI] The claim that segmentation significantly outperforms JDeodorant on methods over 150 LOC is under-specified. Table XI reports NoRelayExtract=False, whereas the JUnit and JHotDraw comparisons in Tables VIII and X use True; the paper does not state which projects the long methods come from, how many methods were analyzed, or which match tolerance produced the reported numbers. Since JDeodorant is described as producing no matching suggestions at all in these cases, the comparison is currently trivial. The configuration and provenance of the long-methods subset need to be specified.
  6. [Section VII-C; Table IX] The XData gold standard was produced by a single developer who was given a description of the segmentation approach before marking the extract-method opportunities, and no inter-rater reliability measure is reported. The largest reported advantage over JDeodorant (Table IX) rests on this single-marker ground truth, and the paper also concedes that both tools suggested blocks larger than the marked ones that were not counted as matches. The paper should use multiple independent markers with an agreement statistic, or at minimum discuss how the pre-marking briefing could bias the markings and how the 'bigger blocks' phenomenon affects the two tools asymmetrically.
minor comments (7)
  1. [Section VI, Procedures 1-2] Procedure 1 uses the identifiers CA(v,G'), THRESHOLD, and PThreshold, which are never defined; the metric defined in Section VI-A1 is LoCS, and the thresholds 0.41 and 0.34 appear only in prose. The pseudocode should be made self-contained and consistent with the text.
  2. [Section VI-A1, equations] The set-difference expression for NonRelayShare contains a rendering typo ('P rocedure(bv, G)') and should read Producer(bv,G) minus AllRelayShare(bv,G); the paper should also state explicitly that #NonRelayShare counts the elements of this set.
  3. [Table III] Table III introduces the category 'Sink Nodes' = {14} without defining it in the text; define sink nodes or remove the row.
  4. [Figures 1(c) and 4(a)-(h)] The SDG figures are difficult to read: edge labels are illegible at the reproduced size, and vertex labels such as '14,15-18' and '19-22' are not explained anywhere in the text. A legend and a higher-resolution rendering would be necessary for reproducing the worked example.
  5. [Section VII-B, Table V] The tuning results are reported per function only; an aggregate precision/recall across the three functions (computable from the table as about 10/15 and 10/18) should be reported, since the claim that thresholds 0.41/0.34 provided the 'best results' is otherwise not directly checkable.
  6. [Section VII-C] The statement that the tuning results 'matched' the manually refactored version overstates Table V, which reports precision between 0.62 and 0.75 and recall between 0.54 and 1.0; the wording should be revised to reflect the actual agreement levels.
  7. [Section VI] The paper gives no correctness argument that applying the suggested contractions yields compilable, behavior-preserving extracted methods (e.g., with respect to parameters, return values, and I/O side effects). A brief structural argument for the three contraction activities would strengthen the central claim that segments are extractable.

Circularity Check

0 steps flagged · score 2.0 of 10

No derivation-level circularity; disclosed parameter tuning weakens the evaluation but is not a by-construction reduction.

full rationale

The derivation chain is a genuine graph transformation: source code is converted to segment IR, then to an SDG, and the SDG is reduced by successive edge contractions to a segment graph whose vertices are suggested extract-method opportunities. None of these steps re-inserts the output into the definitions that produced it, and there are no self-citations or imported uniqueness theorems. The data-independence criterion in Section IV-B is a substantive modeling assumption rather than a tautology: it asserts that same-control-region data flow indicates shared functionality, but the algorithm can fail against developer markings, as shown by JUnit's low recall of 4-8%. Thus the criterion is externally falsifiable rather than circular. The evaluation does involve fitted parameters: Section VII-B states that threshold values 0.41 and 0.34 'provided the best results for this case study' on the authors' own segmentation implementation, and Table VI shows the NoRelayExtract flag is set differently for JUnit, JHotDraw, and XData 'as per the need of the application.' This is transparently disclosed in-sample tuning, which weakens the strength of the comparison with JDeodorant and is a validity concern, but it is not a circular step by the paper's own equations: the thresholds and flag are not defined in terms of the developer markings they are evaluated against, and the reported suggestions are not a forced restatement of the fitted parameters. Under the requirement to exhibit a specific reduction or a fitted parameter renamed as prediction, no qualifying circular step is present, so the appropriate finding is low circularity with a note about evaluation tuning.

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

The paper introduces no new physical or mathematical entities. The SDG is a variant of the well-known program dependence graph, and the segment graph is a derived structure. The free parameters are the two thresholds and the per-project flag.

free parameters (3)
  • LoCS threshold = 0.41
    Tuned on a synthetic C case study in Section VII-B to yield the best precision and recall against a manually refactored version.
  • PA threshold = 0.34
    Tuned on the same synthetic C case study in Section VII-B.
  • NoRelayExtract flag = True for JUnit and JHotDraw, False for XData
    Per-project setting chosen based on observed results in Section VII-C. This is post hoc adjustment rather than a theoretically derived value.
assumptions (3)
  • domain assumption A subgraph that is both control independent and data independent corresponds to a distinct functionality (Section IV).
    The paper assumes that the graph-theoretic properties of control independence and data independence capture what developers consider cohesive functions. No independent evidence is provided for this correspondence.
  • domain assumption Structural control dependence as defined in Section III-A captures the relevant hierarchy of control in code.
    The SDG simplifies control dependence to structural blocks based on block lengths and nesting, which may not match behavioral control flow in all language constructs.
  • domain assumption Developer markings in the evaluation are correct ground truth for extract method opportunities.
    The precision and recall calculations treat manual markings, including markings by a developer who was briefed on the approach, as the gold standard.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Extract Method Refactoring by Successive Edge Contraction." pith.science (2026). https://pith.science/paper/FHE6XTOJ

@misc{pith2026190804636,
  author       = {Pith},
  title        = {Pith review of: Extract Method Refactoring by Successive Edge Contraction},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FHE6XTOJ}},
  note         = {Machine review of arXiv:1908.04636}
}
read the original abstract

Segmentation, a new approach based on successive edge contraction is introduced for extract method refactoring. It targets identification of distinct functionalities implemented within a method. Segmentation builds upon data and control dependencies among statements to extract functionalities from code by successive contraction of edges in the Structure Dependence Graph (SDG). Three edge contractions are explored, namely structural control edge contraction, exclusive data dependence edge contraction, and sequential data dependence edge contraction. The SDG is first constructed from the program, which is then collapsed into a segment graph that captures dependence between subtasks. An intermediate representation for data and control dependencies among statements keeps the technique language independent. The approach is evaluated on four case studies, including three from the open source domain, and the findings are reported.

Figures

Figures reproduced from arXiv: 1908.04636 by the authors.

Figure 1
Figure 1. Intermediate Representation of Fibonacci code and corresponding SDG [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Example graph for chains and Edge Contraction [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Control region example Before discussing the definition of control independence the following properties of SDG are noted: 1) A secondary control vertex can be direct predecessor of a control vertex only if they share at least one primary control vertex as a predecessor. 2) A secondary control vertex can have exactly one primary control vertex as direct predecessor. Let G = (VG, EG) be the SDG, and C = (VC , EC ) be… view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Structure Based Refactoring using Segmentation [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Fibonacci Prime source code and corresponding refactored code by segmentation [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 6
Figure 6. Figure 6: Architecture of segmentation based refactoring [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Non-contributing and Contributing Producers [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 8
Figure 8. Figure 8: A sample SDG with nested Control Blocks bv) in the form of parameters or return value. Example Use of LoCS for CEC: An example SDG is shown in [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

25 extracted references · 24 canonical work pages

  1. [1]

    Software restructuring,

    R. S. Arnold, “Software restructuring,” Proceedings of the IEEE, vol. 77, no. 4, pp. 607–617, 1989

    work page 1989

  2. [2]

    Automated assistance for program restructuring,

    W. G. Griswold and D. Notkin, “Automated assistance for program restructuring,” ACM Transactions on Software Engineering and Method- ology (TOSEM), vol. 2, no. 3, pp. 228–269, 1993

    work page 1993

  3. [3]

    Refactoring: A program restructuring aid in designing object-oriented application frameworks,

    W. F. Opdyke, “Refactoring: A program restructuring aid in designing object-oriented application frameworks,” Ph.D. dissertation, PhD thesis, University of Illinois at Urbana-Champaign, 1992

    work page 1992

  4. [4]

    A survey of software refactoring,

    T. Mens and T. Tourw ´e, “A survey of software refactoring,” IEEE Transactions on software engineering, vol. 30, no. 2, pp. 126–139, 2004

    work page 2004

  5. [5]

    Fowler, Refactoring: improving the design of existing code

    M. Fowler, Refactoring: improving the design of existing code. Pearson Education India, 2009

    work page 2009

  6. [6]

    A field study of refactoring challenges and benefits,

    M. Kim, T. Zimmermann, and N. Nagappan, “A field study of refactoring challenges and benefits,” in Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering . ACM, 2012, p. 50

    work page 2012

  7. [7]

    How we refactor, and how we know it,

    E. R. Murphy-Hill, C. Parnin, and A. P. Black, “How we refactor, and how we know it,” IEEE Trans. Software Eng. , vol. 38, no. 1, pp. 5–18,

    work page

  8. [8]

    Fine slicing,

    A. Abadi, R. Ettinger, and Y . A. Feldman, “Fine slicing,” inFundamental Approaches to Software Engineering . Springer, 2012, pp. 471–485

    work page 2012

Show all 25 references
  1. [9]

    Identifying extract method refactoring opportunities based on functional relevance,

    S. Charalampidou, A. Ampatzoglou, A. Chatzigeorgiou, A. Gkortzis, and P. Avgeriou, “Identifying extract method refactoring opportunities based on functional relevance,” IEEE Transactions on Software Engineering , vol. 43, no. 10, pp. 954–974, 2017

    2017

  2. [10]

    Identification of extract method refactoring opportunities for the decomposition of methods,

    N. Tsantalis and A. Chatzigeorgiou, “Identification of extract method refactoring opportunities for the decomposition of methods,” Journal of Systems and Software , vol. 84, no. 10, pp. 1757–1782, 2011

    2011

  3. [11]

    The program dependence graph in a software development environment,

    K. J. Ottenstein and L. M. Ottenstein, “The program dependence graph in a software development environment,” in ACM Sigplan Notices , vol. 19, no. 5. ACM, 1984, pp. 177–184

    1984

  4. [12]

    Recommending automated extract method refactorings,

    D. Silva, R. Terra, and M. T. Valente, “Recommending automated extract method refactorings,” in Proceedings of the 22nd International Conference on Program Comprehension . ACM, 2014, pp. 146–156

    2014

  5. [13]

    The xda-ta system for automated grading of sql query assignments,

    A. Bhangdiya, B. Chandra, B. Kar, B. Radhakrishnan, K. M. Reddy, S. Shah, and S. Sudarshan, “The xda-ta system for automated grading of sql query assignments,” in Data Engineering (ICDE), 2015 IEEE 31st International Conference on . IEEE, 2015, pp. 1468–1471

    2015

  6. [14]

    Program restruc- turing through clustering techniques,

    X. Xu, C.-H. Lung, M. Zaman, and A. Srinivasan, “Program restruc- turing through clustering techniques,” in Source Code Analysis and Manipulation, 2004. Fourth IEEE International Workshop on . IEEE, 2004, pp. 75–84

    2004

  7. [15]

    Software refactoring at the function level using new adaptive k-nearest neighbor algorithm,

    A. Alkhalid, M. Alshayeb, and S. Mahmoud, “Software refactoring at the function level using new adaptive k-nearest neighbor algorithm,” Advances in Engineering Software, vol. 41, no. 10, pp. 1160–1178, 2010

    2010

  8. [16]

    Restructuring programs by tucking state- ments into functions,

    A. Lakhotia and J.-C. Deprez, “Restructuring programs by tucking state- ments into functions,” Information and Software Technology , vol. 40, no. 11, pp. 677–689, 1998

    1998

  9. [17]

    Restructuring programs through program slicing,

    H. S. Kim, Y . R. Kwon, and I. S. Chung, “Restructuring programs through program slicing,” International Journal of Software Engineering and Knowledge Engineering , vol. 4, no. 03, pp. 349–368, 1994

    1994

  10. [18]

    Using clustering technique to restructure programs

    C.-H. Lung and M. Zaman, “Using clustering technique to restructure programs.” in Software Engineering Research and Practice , 2004, pp. 853–860

    2004

  11. [19]

    Program slicing,

    M. Weiser, “Program slicing,” in Proceedings of the 5th international conference on Software engineering . IEEE Press, 1981, pp. 439–449

    1981

  12. [20]

    Debugging with dynamic slicing and backtracking,

    H. Agrawal, R. A. DeMillo, and E. H. Spafford, “Debugging with dynamic slicing and backtracking,” Software: Practice and Experience , vol. 23, no. 6, pp. 589–616, 1993

    1993

  13. [21]

    Dynamic slicing object-oriented pro- grams for debugging,

    B. Xu, Z. Chen, and H. Yang, “Dynamic slicing object-oriented pro- grams for debugging,” in Source Code Analysis and Manipulation, 2002. Proceedings. Second IEEE International Workshop on . IEEE, 2002, pp. 115–122

    2002

  14. [22]

    Program slicing in understanding of large programs,

    B. Korel and J. Rilling, “Program slicing in understanding of large programs,” in Program Comprehension, 1998. IWPC’98. Proceedings., 6th International Workshop on . IEEE, 1998, pp. 145–152

    1998

  15. [23]

    Identifying fragments to be extracted from long methods,

    L. Yang, H. Liu, and Z. Niu, “Identifying fragments to be extracted from long methods,” in Software Engineering Conference, 2009. APSEC’09. Asia-Pacific. IEEE, 2009, pp. 43–49

    2009

  16. [24]

    Control flow analysis,

    F. E. Allen, “Control flow analysis,” in ACM Sigplan Notices , vol. 5, no. 7. ACM, 1970, pp. 1–19

    1970

  17. [2012]

    Available: https://doi.org/10.1109/TSE.2011.41

    [Online]. Available: https://doi.org/10.1109/TSE.2011.41

    2011 doi

Pith tools

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