RubyMine 2024.2 'Method could be private' quick-fix inserts visibility at nearest declaration in modules
0 reputation · 22 Oct 2023, 11:30 UTC
0 reputation · 22 Oct 2023, 11:30 UTC
RubyMine 2024.2 added a "Visibility" intention action (Alt+Enter) that can automatically insert private or protected above a method flagged by the "Method could be private" inspection. The implementation places the keyword at the nearest preceding visibility declaration.
In a module that is included by multiple classes, the inspection runs per-class rather than per-module. When the quick-fix is applied to a method in the module file and no explicit private section exists, the inserted keyword becomes the new nearest preceding declaration for all preceding methods in that file. This can unintentionally change the visibility of unrelated methods that were previously public.
How does the quick-fix determine the insertion point when a module contains multiple method definitions with no explicit visibility sections? Can the intention action be configured to require an existing private block before inserting, or to operate only on class files? What is the recommended workflow for safely applying visibility changes in shared modules without breaking callers in other including classes?
35775 reputation · 22 Oct 2023, 20:38 UTC
In RubyMine 2024.2, the "Method could be private" quick-fix determines the insertion point by placing the visibility keyword (private or protected) at the nearest preceding visibility declaration. If the module contains no explicit visibility sections, the IDE inserts the keyword directly above the flagged method. Because Ruby visibility modifiers apply to all subsequent method definitions in the file, this action effectively converts all methods defined after the insertion point to that visibility level.
Currently, there are no project-level settings or configuration options to:
private block before allowing the insertion.Because the inspection's call-graph analysis is performed per-class rather than per-module, a method may be flagged as "could be private" based on one including class, while remaining essential for public access in another. To avoid introducing NoMethodError or unintentionally hiding public methods, follow this workflow:
Alt+F7 (Find Usages) on the method to identify every class that includes the module and calls the method. Do not rely solely on the inspection flag.private section at the bottom of the module and move the method definition there.File > Invalidate Caches... to ensure the inspection is not operating on stale data.To confirm the impact of a quick-fix in your specific module structure, apply the fix to a test method and check the visibility of all methods defined below it using the RubyMine structure tool window (Alt+7 / Cmd+7).
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.