Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated Name Recommendation For The Extract Local Variable Refactoring #602

Conversation

Michaelll123
Copy link
Contributor

@Michaelll123 Michaelll123 commented May 29, 2023

What it does

see issue cited.

How to test

Run test153, and test154 in ExtractTempTests.

Author checklist

package org.eclipse.jdt.internal.core.manipulation;
/**
* This utility class for English words is taken from a blog on CSDN, and we modify it to adapt for the cases of multiply word.
* The original blog can be found in https://blog.csdn.net/weixin_44258855/article/details/123201283
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, this can't be merged into eclipse.org codebase as it refers to a source without clear licensing information, doesnt represent your own code and the snippet itself seem to be largely inadequate to address the problem you are trying to fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I will try to solve this problem soon.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iloveeclipse how did you determine the source of code ? i.e if its devs own or not ? Is there some tool for it ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are third-party APIs allowed to merge into eclipse.org codebase?

See https://www.eclipse.org/projects/handbook/#ip

TL;DR: content added to the jdt.ui bundle must be licensed under EPL license.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iloveeclipse how did you determine the source of code ? i.e if its devs own or not ? Is there some tool for it ?

I would name it BDA "brain driven analysis". Of course as every tool that might fail too.
In this concrete context I just assume the "using code posted by someone on some blog page" is most likely description of the code not written by PR author and so it is highly questionable if that is allowed to be merged here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like there is no existing open-source tool written in Java to support the convertion between plural words and singular words. I will implement my own version soon.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Michaelll123 FWIW: a lot of English words are unnecessary to handle (e.g. geese to goose is unlikely to show up in code and not worth the time to look for it). There was a pared down version of finding a singular in ConvertLoopOperation.modifyBaseName() which gets a variable name for an enhanced-for-loop (e.g. for (String name : names)). It handled a number of common usages (e.g. children vs child) and then identified odd English plural suffixes to avoid attempting removing the "s" in which case it defaulted to "element". You could base off of that and add more direct conversion cases if you want. Pure plural support is over-kill IMO.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jjohnstn Thanks for the insightful advice! It is indeed a tricky problem to cover all the conversion cases in English, and I will start with ConvertLoopOperation.modifyBaseName().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all your valuable advice, and I have finished the requested changes. Please kindly review the latest pull request.

@Michaelll123 Michaelll123 requested a review from iloveeclipse June 1, 2023 03:05
Copy link
Contributor

@jjohnstn jjohnstn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, the logic is fine and additions to the loop name logic are useful. The logic can be moved into another method in StubUtility and cleaned up a bit.

MethodInvocation methodInvocation= (MethodInvocation)assignedExpression;
Expression receiver= methodInvocation.getExpression();
String methodName= methodInvocation.getName().toString();
if(receiver != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should be checking for next() being called before bothering with receiver. I also think this logic could be put into getBaseNameFromExpression() as it is only used by the getVariableNameSuggestions() methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review, and I have put my code snippets into getBaseNameFromExpression.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@Michaelll123 Michaelll123 requested a review from jjohnstn June 3, 2023 08:38
@Michaelll123
Copy link
Contributor Author

Thanks for all your valuable advice, and I have finished the requested changes. Please kindly review the latest pull request.

Copy link
Contributor

@jjohnstn jjohnstn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Just a formatting issue with casting adding a blank. Fix that and it is ready to go.

} else if (assignedExpression instanceof SuperMethodInvocation) {
name= ((SuperMethodInvocation)assignedExpression).getName().getIdentifier();
name= ((SuperMethodInvocation) assignedExpression).getName().getIdentifier();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something in your format profile is adding a blank between casts and their element to cast. This should not be changed as part of this patch. Other than that, the code looks good. If you want me to fix it with my own formatting, I can do so.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot! I will fix that immediately.

@Michaelll123 Michaelll123 requested a review from jjohnstn June 6, 2023 07:23
@Michaelll123
Copy link
Contributor Author

The format issues have been addressed. Looking forward to being merged.

@jjohnstn jjohnstn added this to the 4.29 M1 milestone Jun 6, 2023
@jjohnstn jjohnstn added the enhancement New feature or request label Jun 6, 2023
@jjohnstn jjohnstn self-assigned this Jun 6, 2023
@jjohnstn jjohnstn dismissed iloveeclipse’s stale review June 6, 2023 17:19

Code that was in question has been replaced by existing code in for loop cleanup.

Copy link
Contributor

@jjohnstn jjohnstn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Michaelll123 The patch is fine but please recreate the patch in your branch so it is rebased on master and submit via --force push. You have been merging master into your branch which is disallowed. You should always rebase your patches on top of master as opposed to merging master into your branch.

@Michaelll123 Michaelll123 force-pushed the recommend-name-for-extract-local-variables branch 3 times, most recently from de74dbe to 03951e9 Compare June 7, 2023 01:24
@Michaelll123 Michaelll123 force-pushed the recommend-name-for-extract-local-variables branch from 03951e9 to c5f4aa6 Compare June 7, 2023 01:44
@Michaelll123 Michaelll123 reopened this Jun 7, 2023
@Michaelll123 Michaelll123 force-pushed the recommend-name-for-extract-local-variables branch from 54df185 to 5e741f5 Compare June 7, 2023 07:49
@Michaelll123
Copy link
Contributor Author

Thanks for the review. I think the latest patch is based on master, and there are no commits merging master into recommend-name-for-extract-local-variables. Please check again, thanks!

@Michaelll123 Michaelll123 requested a review from jjohnstn June 7, 2023 08:19
@jjohnstn
Copy link
Contributor

jjohnstn commented Jun 7, 2023

Hi @Michaelll123 Looks good. Just need to wait until master opens for 4.29 M1

@Michaelll123
Copy link
Contributor Author

Thanks! Have a good one!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Automated Name Recommendation For The Extract Local Variable Refactoring
4 participants