Refactor>Rename support for Apex

[Scott Wells]

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.

[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.

[Scott Wells]

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.

[Justin Julicher]

Any update on this feature?

[Scott Wells]

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.

[Justin Julicher]

Hi Scott, thanks for the update. It's much appreciated!

[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.

[Scott Wells]

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

[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.

[Scott Wells]

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...

[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.

[Scott Wells]

FYI, here's a preview of rename refactoring which will be part of IC 2.0 along with other refactorings and intelligent source code evolution/management:

IC2 Preview - Rename Refactoring

[Matt Addy]

Wow! This is amazing. Thanks for sharing the preview, Scott.

[Willem Mulder]

Very useful!

[Phil W]

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.

[Scott Wells]

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.

[Scott Wells]

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.