2009-09-06 5 views
1

모든 변수 및 매개 변수 이름이 written_like_this 인 큰 C# 프로젝트를 상속 받았습니다.전체 프로젝트 변수 및 매개 변수 이름 리팩토링

10 마우스 클릭만으로 자동으로 이름을 바꾸는 데 사용할 수있는 쉬운 방법이 있습니까? 위의 예는 writtenLikeThis (즉, 낙타의 경우)이됩니다. 인스턴스 변수 _ writtenLikeThis.

또한 XMLDoc 주석도 업데이트해야합니다.

내가 바퀴를 다시 작성하지 않을 경우에만 Regex로 무언가를 노크 할 수 있습니다.

감사합니다.

+0

왜? 점은 무엇인가? 코드가 더 빠르거나 버그가 없습니까? 나는 당신이 지금 가지고있는 것과 당신이 원하는 것이 나에게 잘 어울리기 때문에 그것이 더 읽기 쉽다는 것을 의심한다. 당신이 그것을해서는 안된다는 말은 아닙니다. 동기 부여를 이해하지 마십시오. 버그 수정이나 기능 추가에 시간을 낭비하지 않으시겠습니까? – paxdiablo

+5

코드베이스의 작업을 더욱 즐겁게하고 회사의 명명 규칙을 준수하기 위해 예를 들어 나에게 훌륭한 목표를 느낀다. ReSharper가 "시행 규칙"배치 작업을했다면 좋을 것입니다.하지만 생각하지 않습니다. ... –

+2

@Pax : 최근에 인수 한 응용 프로그램의 코딩 스타일 지침 준수가 제 추측입니다. – JoshJordan

답변

1

아니요, Visual Studio의 리펙토링 도구는 이러한 종류의 세련미를 지원하지 않습니다.

수동으로해야합니다. 프로젝트 파일을 다시 작성하기 위해 유틸리티를 작성할 수는 있지만 의미 론적으로 분리 된 상태로 작동하며 변수 이름 이외의 다른 것을 선택할 수 있습니다. 이 원본 텍스트의 상단에 의미 론적 전망 때문에 VS 리팩토링 도구의 차이를 알고

string aGoodString = @"We need to rename the my_badly_named_string because 
         it looks ugly"; 

string my_badly_named_string = "Hi, there!"; 

: 사이

어떻게 예를 들어, 구별 것이다. 귀하의 유틸리티는 그렇지 않습니다.

솔직히 말해서, 그것은 타이탄의 작품이 될 것입니다. 더 많은 버그를 일으킬 위험이 있습니다. 그대로 두는 것이 좋습니다.

+0

나는 몰라, 나에게 몇 가지 정규식으로 처리하는 것이 꽤 간단하게 들린다. 사용자가 제공 한 예제는 실제로 내장 된 .NET 문자열 클래스를 사용하여 한 행에서 수행 할 수 있습니다. – JoshJordan

+0

Regexes는 파싱에 더 적합한 작업을하기 위해 정규식을 사용하기 시작할 때까지 항상 쉽습니다 :-) – paxdiablo

2

저는 NewInTown에 그대로 두어야한다는 것에 동의하지만, 이름을 변경하고 좋은 단위 테스트를 원한다면, 버그를 수정하기 위해 약간의 변경이 필요할 때, 기능을 변경 한 다음 새 스키마로 이름을 천천히 바꾸기 시작하십시오.

이렇게하면 자동화하고 많은 새로운 버그를 만들지 않으므로 응용 프로그램을 개선하지 않는 작업 코드를 변경하는 데 시간을 낭비하지 않습니다.

필자는 어쨌든 그 기능에있어 일부 리팩토링 또는 기본 최적화를 수행하는 기능을 수정하는 경향이 있습니다.

0

방금 ​​프로젝트를 상속 한 경우 작업을 시작하고 업데이트해야 할 때까지 프로젝트를 떠날 가치가 있습니다. 리팩토링 익스텐션이 완전히 다른 이름으로 바뀐 경우 다른 곳에서 보낸 시간이 더 좋아질 수 있습니다. 다양한 파트에서 작업하면서 이름을 변경하면 현재 위치를 시각적으로 보여줍니다.

정말로 변수 및 매개 변수 이름의 이름을 바꾸려면 코드 파일을 구문 분석하여 정규식 또는 알고있는 것에 따라 기본 문자열 조작을 사용하여 코드를 분석하는 프로세스를 빌드하고 싶습니다. 마음에 한 번만 변경 될 것입니다) 이것은 코드 리팩토링 도구를 평가하는 것보다 빠를 것입니다.

1

최근 resharper를 사용했습니다. Visual Studio에서 구운 유틸리티보다 훨씬 빠릅니다. 각 식별자로 가서 리팩터링/이름 바꾸기를해야했지만 모든 것이 올바르게 바뀌었기 때문에 안전합니다. 한 가지 중요한 점은 시작하기 전에 코드를 완전히 컴파일해야한다는 것입니다.상황이 양호한지를 확인하기 위해 가끔씩 다시 컴파일하는 것이 좋습니다. 소스를 보지 않고 일리노이 나 코드 솜 등을 사용합니다. 매우 큰 프로젝트의 경우 이것은 여전히 ​​시간이 걸리지 만 작동합니다.

BTW. 나는 언젠가 언더 스코어 (inderscore)로 시작한 상속 된 프로젝트에서 모든 로컬 바 (vars)를 변경하는 데 하루 종일 보냈습니다. 필자는 개인적으로 지나치게 많은 밑줄로 인해 오염 된 코드를 보려고 설 수 없습니다. 그러나 그것은 나뿐입니다. 모든 가게는 다릅니다.

관련 문제