Implementing Refactorings in IntelliJ IDEA

  • 2,897 views
Uploaded on

Presentation on Second ACM Workshop on Refactoring Tools https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/

Presentation on Second ACM Workshop on Refactoring Tools https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,897
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Implementing Refactorings in IntelliJ IDEA Dmit ry Jemerov Development Lead JetBrains, Inc. ht tp://www.jetbrains.com/
  • 2. Agenda
    • Demo of new refactoring features
    • Refactoring building blocks
    • Structural search and replace
    • Problems and future directions
  • 3. Agenda
    • Demo of new refactoring features
    • Refactoring building blocks
    • Structural search and replace
    • Problems and future directions
  • 4. Building Blocks
    • Not a set of Lego bricks
    • A workflow framework into which you can plug your code
    • And a set of utility functions and classes to implement the essence of refactoring
    • Every refactoring is somewhat different
  • 5. Lexing and Parsing
    • Lexer converts text into stream of lexems
    • Recursive-descent parser builds PSI (Program Structure Interface) tree
      • Contains all tokens including whitespace
      • Error markers at places of syntax errors
      • Supports high-level semantic operations
      • Supports write operations (add, replace, delete)
  • 6.  
  • 7. References
    • Usages of an element declared elsewhere
    • Can cross languages (e.g. XML to Java)
    • Key operations:
      • Resolve (get declaration by usage)
      • Callbacks on move/rename of target
  • 8. General Refactoring Workflow
    • Show UI for entering options
    • Find usages of target element
    • Check for conflicts (accessibility etc.)
    • Show list of affected usages, allow user to exclude some
    • Modify target element and each usage as appropriate
  • 9. Find Usages
    • Finds all references to PSI element
    • Based on inverted index of all identifiers
    • All words that look like a reference are checked if they indeed resolve to target
  • 10. Code Modification
    • Stub of new element created from text
    • Targets of references in fragment to be moved are remembered
    • Stub contents is replaced with fragment to be moved
    • Modifiers etc. are updated via PSI
    • References are updated so that they point to the same targets
    • Updated fragment is reformatted
  • 11. Formatter
    • Defines a set of constraints on layout of pairs of elements
      • Minimum spacing / line breaks
      • Indentation
      • Alignment
    • Whitespace not violating constraints is preserved
  • 12. Agenda
    • Demo of new refactoring features
    • Refactoring building blocks
    • Structural search and replace
    • Problems and future directions
  • 13. Structural Search
    • QBE interface for navigating and modifying Java and XML/HTML code
      • Code fragment with some variables
      • Constraints for variables
      • Replacement pattern specifying how occurrences should be changed (optional)
    • Allows to perform custom refactoring operations
  • 14. Structural Search Template
  • 15.  
  • 16. Structural Search Problems
    • Very hard to use by non-expert users
    • Patterns are written in a non-obvious way
    • Unintuitive UI
    • Doesn’t cover all operations
    • No façade around internal API for writing scripts
  • 17. Agenda
    • Demo of new refactoring features
    • Refactoring building blocks
    • Structural search and replace
    • Problems and future directions
  • 18. Context Dependence in Java
    • Java language is not uniform
    • Many contexts in which only certain code is allowed
      • Constructors, super constructor calls
      • Enum constants
      • Anonymous classes
      • Initializer blocks
    • Lots of special-case code needed to handle weird context changes
  • 19. Refactoring Quality
    • Users typically don’t review the results of applying an automated refactoring
    • Expect their tool to be 100% correct
    • Solutions which provide 90% correctness with simple implementation aren’t acceptable
    • No way to escape hand-coding corner cases
  • 20.  
  • 21. DSL for Code Transformations
    • If the complexity can’t be avoided, maybe it can be compressed?
    • Desire to replace verbose Java code with a domain-specific language
      • Internal DSL
      • Groovy/Ruby
      • JetBrains MPS
  • 22. Patterns
    • Internal DSL for matching AST fragments
  • 23. Language Independent Refactorings
    • Currently only the basic refactorings (Rename and Move) are mostly language-agnostic
    • All other refactorings are reimplemented from scratch for every new language
    • Desire to extract language-independent essence to common part
  • 24. Summary
    • Refactorings in IntelliJ IDEA involve a lot of complex code with limited reuse
    • Complexity caused by large number of concepts in Java language
    • Necessity of 100% correctness means that complexity is essential
    • Main hope for improvement is building powerful code transformation DSLs
  • 25. Q&A Dmitry Jemerov [email_address]
  • 26. Implementing Refactorings in IntelliJ IDEA Dmit ry Jemerov Development Lead JetBrains, Inc. ht tp://www.jetbrains.com/