Refactor>Rename support for Apex

Issue #21 resolved
Scott Wells repo owner created an issue

Add rename refactoring support for Apex symbols. For local variables and non-global type members this is pretty straightforward, though to be 100% complete it may need to wait until I add references to Visualforce controller properties/methods so that those are updated as well. For global type members the refactoring should offer to leave a stub in place with the @Deprecated annotation to help those creating managed packages where the renamed symbol may already have been included in a release package. The same consideration is necessary for top-level types, but for those it'll also need to perform a first-class rename in the organization and rename associated files such as the meta.xml file and other external references.

Comments (19)

  1. Diego Núñez Silva

    Any idea when will you release this feature? I am trying to move from Sublime with Mavensmate to IlluminatedCloud but sublime has this multiselection/rename feature that I use quite frequently and having the rename support will alleviate the pain. Hope you can prioritize it.

  2. Scott Wells reporter

    Diego, this will be the first refactoring that I implement as it's easily the most desired one. My current queue places it after first-class Lightning support which I plan to attack in the next month or so. My best guess on this will be two or three months out before its implemented, so it won't be a long time, but it won't be in the next few weeks either.

  3. Scott Wells reporter

    Justin, this will be one of the very first features added in the 2.0 release which I hope to get out during the first half of this year alongside other refactorings, client-side code inspections and intentions, and smart code generation.

  4. Scott Posey

    Rename is the killer feature for IntelliJ. This is the one of two issues that blocks my company from company-wide deployment (about 100 devs).

    As an aside, most everyone here uses MavensMate, which can be tricky to configure but is lightening-fast.

  5. Scott Wells reporter

    Scott, rename (and refactoring in general) for Apex is coming, but likely as a 2.0 feature (hopefully) around mid-year.

  6. Scott Posey

    Thanks for the quick response, Scott. Missing that feature is like fighting with one hand tied behind my back. Is there any chance it could be released sooner? I'd trade that for everything else on your list above in a heartbeat.

  7. Scott Wells reporter

    I certainly understand. Trust me, I'm missing it as well when I write Apex code!

    Refactoring, client-side code inspections and intentions, and smart code generation (override/implement methods, generate constructors/accessors, etc.) are going to be the key features of 2.0. I'm currently finishing up a few things I wanted in the 1.x release and then will be turning my full attention to 2.0. The absolute first refactoring I plan to implement is a REALLY smart rename that knows how identifiers are used not just within Apex but also across other referencing metadata. Hopefully it won't be too long before I can get that out...

  8. Tom Fuda

    Great to hear Scott. I appreciate that this is a much more complicated problem than simple Java refactoring. Just because IntelliJ supports refactoring doesn't mean Apex refactoring comes cheaply. If that were the case, Salesforce would have offered it in the Force.com IDE years ago. ;) Understanding how to unwind all of the references to a particular Apex class, method and/or variable so that it can be renamed sounds like a tricky problem. Looking forward to seeing what you come up with.

  9. Phil Weighill-Smith

    Hi Scott,

    Did you know that if you mark a method as deprecated it is not possible to modify any of the code in that method (e.g. to fix a bug)? This is a constraint applied by Salesforce and means deprecation is a mechanism that should only be used very cautiously.

  10. Scott Wells reporter

    That's surprising, Phil. I could swear in my previous ISV life (as opposed to my current-but-different ISV life) we would gut the bodies of @Deprecated Apex methods after a period of time and make them throw the equivalent of an UnsupportedOperationException. I wonder if this is a semi-recent change, or perhaps my memory is failing me and we just gutted them at the original time of deprecation.

  11. Scott Wells reporter

    Delivered in 2.0. Will open additional issues/stories for enhancements to the feature such as offering to rename related identifiers with the same stem name, e.g., accessor methods for fields, similarly-named base/derived classes, associated test classes, etc.

  12. Log in to comment