Bug 35356 - Convert local variable to field refactoring proposes weird name
Summary: Convert local variable to field refactoring proposes weird name
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 3.0 M9   Edit
Assignee: David Audel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-20 07:56 EST by Oyvind Harboe CLA
Modified: 2004-05-18 11:01 EDT (History)
7 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Oyvind Harboe CLA 2003-03-20 07:56:49 EST 
- "Convert local variable to field" on "colorNames"
- The name proposed is "nameses"
- No exceptions in log
- Eclipse RC2


public class Foo
{
	public void bar()
	{
		String[] colorNames={"red","green", "blue"};
	}
}
Comment 1 Dirk Baeumer CLA 2003-03-20 09:36:33 EST 
Adam, do we use core functionality for name proposing in this case ?
Comment 2 Adam Kiezun CLA 2003-03-20 09:41:04 EST 
yes, seems like NamingConventions problem
Comment 3 Oyvind Harboe CLA 2003-03-21 06:52:19 EST 
I think this behaviour is new since RC2, I can't remember bumping into the 
problem earlier. 

Øyvind
Comment 4 Adam Kiezun CLA 2003-03-21 06:55:02 EST 
yes, we moved to using the NamingConventions class for M3 or a bit later
Comment 5 Ilja Preuss CLA 2003-07-11 03:52:43 EDT 
I don't understand why this refactoring doesn't just leave the variable name as 
it is...?
Comment 6 Adam Kiezun CLA 2003-07-11 04:59:16 EDT 
normally people have conventions for instance field names,
so their names would start with '_' or 'f' or something

so if you have a temp named colorNames, and your pref set to 'f' prefix for 
field names, the refactoring should suggest 'fColorNames' as the field name
Comment 7 David Corbin CLA 2003-11-25 18:55:55 EST 
some people have name convention for fields.  Some of us hate such standards and
avoid it like the plague. 

Regardless, changing the "launcherLabel" to "label" doesn't make sense.
Comment 8 David Audel CLA 2004-05-13 04:50:51 EDT 
New naming conventions.
If it is an array type
  which ends with "ss" then append "es"
  which ends with "y" then remove "y" and append "ies"
  which ends with "s" do nothing
  otherwise append "s"

Fixed end tests added
  NamingConventions#testSuggestFieldName017
  NamingConventions#testSuggestFieldName018
  NamingConventions#testSuggestFieldName019
  NamingConventions#testSuggestFieldName020
Comment 9 Ilja Preuss CLA 2004-05-13 05:04:06 EDT 
So, what does happen to colorNames, now? "names" or "colorNames"? In my humble 
opinion, the latter would make more sense...
Comment 10 David Audel CLA 2004-05-13 05:10:33 EDT 
NamingConventions propose "colorNames" and "names". Convert local variable to 
field refactoring must choose only one name and currently it is "colorNames".
Comment 11 Ilja Preuss CLA 2004-05-13 05:18:45 EDT 
Nice, thanks!
Comment 12 Nikolay Metchev CLA 2004-05-13 07:58:37 EDT 
Those rules are good but only if you are coding in english. Not that I am 
coding in any other language but just a thought.
Comment 13 Markus Keller CLA 2004-05-13 08:31:48 EDT 
Re comments 7, 9, and 10: those issues have been resolved with bug 54444.
Comment 14 Olivier Thomann CLA 2004-05-18 11:01:05 EDT 
Verified in 200405180816