Add code inspection to verify that the top-level type/trigger name matches the name of the containing file

Issue #947 new
Eric Kintzer created an issue

IC 2.0.1.5 Rename a class Foo_Test to FooTest in situ - that is, by simply overtyping the class name in the editor. Then save.

So, much to my surprise, the org class was changed to FooTest but

  • of course, the file name (and tab) in the local project remained at Foo_Test.cls
  • yet curiously, the class name in the Project Navigator also remained at Foo_Test.

I realize I was supposed to use Refactor - Rename to do this operation but I naively thought IC would do magic simply by changing the class name in the editor.

In the Force.com IDE, if you attempt to change the name of a class that disagrees with the file name, you get a compile error but no such error in IC and things are left in an inconsistent state.

Comments (2)

  1. Scott Wells repo owner

    Yeah, I just reproduced this easily, both in IC and in Developer Console. This is due to the difference between the Tooling API and the Metadata API. When you deploy via the Metadata API, it actually adds a file named classes/Foo_Test.cls to the zip that it uploads, and then Salesforce sees that the file name and contained class name don't match and complains. When you do the same thing with the Tooling API it just adds the class body to the Tooling API's metadata container and commits the container. The end result is that the class is duplicated.

    This seems to be a bug on the Salesforce side, and the reason you probably didn't see it in the Eclipse plugin is because it was using the Metadata API.

    I think the right thing to do in IC is to add a code inspection that verifies that the top-level type name matches the containing file name (sans extension) and, if not, offers to either correct the type name or the file name.

  2. Log in to comment