Quantcast
Channel: YouTrackReSharper (RSRP) - Bug and Issue Tracker
Viewing all articles
Browse latest Browse all 106942

RSRP-287548: Rename parameters to overloaded methods isn't intuitive

$
0
0
Reporter Greg Law (lothan) Greg Law (lothan)
Created Jan 2, 2012 10:11:56 PM
Updated Feb 20, 2012 12:06:32 AM
Priority Major
Type Usability Problem
Fix versions No Fix versions
State Open
Assignee Sergey Shkredov (serjic.shkredov)
Subsystem Refactoring
Affected versions 6.1
Fixed in build No Fixed in build
If you have overloaded constructors or methods that don't contain the same parameters in the same order, ReSharper seems to "randomly" pick which parameter in an overload to rename and may not rename any parameters in the overloaded methods at all. I don't like code structured this way, but imagine you have a set of overloaded methods something like this:

public void CreatePost(string strUserName, string strSubject, string strBody)
{
}

public void CreatePost(string strUserName, DateTime dtPostDate, string strSubject, string strBody)
{
}

public void CreatePost(string strUserName, string strSubject, string strBody, DateTime dtPostDate, string strCategory)
{
}

If you rename strUserName to userName, ReSharper appropriately renames strUserName to userName in all three methods.

If you rename strSubject to subject, ReSharper renames strSubject to subject only in the first and third overloads.

If you rename strBody to body, ReSharper renames strBody to body in the first and third overloads and prompts to rename strSubject to subject in the second overload.

I don't know if this is entirely true, but it looks as if ReSharper is picking out the parameters to rename based on the position and data type instead of by name. In other words, the first rename works because strUserName is always the first parameter and is always type string. The second rename doesn't work correctly because the second overload has a DateTime as the second parameter so the types don't match. The third rename works a bit odd because the third parameter is of type string so the types match.

If the fix is too complicated, you might close this as won't fix. The bigger issue in my mind that the parameters aren't in the correct order so it makes the code confusing and overly complex.

Viewing all articles
Browse latest Browse all 106942

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>