Field Name Recommendation Based on Program-Specific Naming Conventions about eclipse.jdt.ui HOT 3 OPEN

@jjohnstn Please kindly have a look at the issue and the solution. Thanks.

from eclipse.jdt.ui.

Hi @DongChunHao I think this change is very specific to a scenario you experienced but I don't feel it adds functionality to Eclipse JDT that would be useful to general users. For example, hitting CTRL+1 on B1 using your change:

public class TestRenaming {
	
	public int A1;
	public int A2;
	public int B1;

}

it recommends renaming B1 to AB1. That doesn't really make any sense. This clearly isn't a case of a naming convention. It is just a coincidence that most fields start with A.

Each quick-fix/assist needs to do calculations to determine if it is relevant and if a change can be created and this takes resources that ultimately adds up. Thus, we want quick-fixes/assists to provide value to general users, not just for a one-off scenario. A project-specific naming convention is just that: project-specific and doesn't apply to other projects/users. If a particular project wants all fields to be prefixed with a special prefix it can add scripts to verify code check-ins (e.g. github actions) or the project could run verification scripts occasionally that are published to the development team. To infer a naming convention by looking at code is a leap and isn't really feasible using frequency as shown by my simple example above.

from eclipse.jdt.ui.

I could forsee a situation where a particular coding convention were set in a .settings file or property page, and then the quick fix only needs to check if this feature is enabled or not. This would certainly speed up the calculations for users who don't want to use the feature (a simple property check on the file) while allowing the logic to run for those who want it. A discussion on whether thats even advisable is at least worth something.

But I agree that in its current form it provides limited utility with a possible performance hit.

from eclipse.jdt.ui.