약 20 개의 프로젝트 (.csproj)와 3 년 된 솔루션 (.sln)이 있습니다. FxCop 및/또는 StyleCop을 사용하는 것이 합리적입니까? 어쩌면 우리는 몇 가지 작은 프로젝트를 먼저 사용해야하지만 전체 솔루션을 위해 사용해야하지 않을까요?성숙한 프로젝트에서 FxCop 및/또는 StyleCop을 사용해야합니까?
몇 가지 경험있는 답변을 확인하는 것이 좋습니다.
감사합니다.
편집 : 우리는 지속적인 통합을위한 인 TeamCity를 사용하는. 그리고 우리는 ReSharper를 사용할 수 없습니다. :(CodeRushXpress 만.
예, 당신이해야하지만, 천천히.
이 StyleCop를 설치하고 ReSharper에서 플러그인에 대한 StyleCop을 얻을, 사용하려는 규칙 설정을 ReSharper에서의 사본을 가져 와서에서 당신이 열어 놓은 모든 파일들은 불규칙한 파란 선들로 가득 차서 어떤 것이 나쁜지를 알려줍니다.
한 번에 하나의 파일 만 고치면 끝내지 않고 깨끗한 프로젝트가 끝납니다. 필요하면 3 주 충전식 시간에 발생 아무것도하지 않고 프로젝트를 겪고 보낼 수 있도록 당신의 상사를 설득!
가져 오기 당신이 시도하고 한 번에 전체 프로젝트를 통해 그것을 할 경우 팅 깨끗한 코드는에 의해보고 된 문제를 해결 만든 방법의 통합에 따라 (고정 피클 :
에 끝날거야, 리팩토링과 같다 이러한 도구)에는 많은 시간이 걸릴 수 있으므로 프로젝트를 하나씩 통합하는 것이 여러분이 가야 할 길입니다.
편집는 :
에드 우드 콕의 대답에 추가 : 당신은 SyleCop을 구성 할 수 있습니다 (그리고 난의 FxCop이 너무 내기) 자동 빌드 VS 각시 수표를 실행합니다. 이 기능을 사용하면 정기적으로 개발하는 동안 모든 프로젝트의 점검을 하나씩 켤 수 있으며 모든 경고를 수정할 수 있습니다 (오류를 생성하도록 이러한 도구를 구성 할 수도 있음).
TeamCity는 지속적인 통합을 위해 마련되었습니다. 아마 나는 내 질문에 언급해야한다. –
방금 개인 프로젝트에서 StyleCop을 사용하기 시작했으며 "문제"를 해결하기 위해 약간의 시간이 걸립니다.
변경 사항을 적용하기 전에 파일 샘플을 실행하고 결과를 분석하기 전에 StyleCop을 실행하는 것이 좋습니다.
예를 들어, 기본적으로 StyleCop은 모든 메소드 (공개 및 비공개)에 대한 메소드 문서가 누락되었다고 불평합니다. 자, 저는 이것을 대답 할 수는 없지만 개인적인 방법으로 완전한 문서화가 필요한지 아닌지 결정할 필요가 있습니다. 그러나 당신은 한 가지 방법이나 다른 방법을 결정할 필요가 있습니다. 6 개월 동안 변경을 원한다면 원하는 것이 아니라고 결정할 수 있습니다. 그것은 불필요한 변화를 가져 오거나 완료했다고 생각한 코드를 재 방문해야하는 것입니다.
당신은 StyleCop의 설정에 필요한 조정을 한 다음 코드베이스에 그것을 풀어 일단 - 한 번에 하나 개의 프로젝트.
전체 프로젝트가 아니라 전체 프로젝트에서 StyleCop을 사용하는 방법이 있다고 생각합니다. 감사. –
@Vasiliy - 파일을 마우스 오른쪽 버튼으로 클릭하고 컨텍스트 메뉴에서 해당 파일에 대해 StyleCop을 실행할 수 있다는 것을 알고 있습니다. 프로젝트를 마우스 오른쪽 버튼으로 클릭하여 동일한 작업을 수행 할 수 있습니까? (나는이 PC에 StyleCop을 설치하지 않았다.) – ChrisF
방금 StyleCop을 설치했습니다. 예, 파일 또는 프로젝트에서 실행할 수 있습니다. –
FxCop과 관련하여 예, 여러분이 새 프로젝트에 있든 기존 프로젝트에 있든이 도구를 사용하는 것이 좋습니다. StyleCop과 마찬가지로 도구를 실행하고 출력을 검토 할 수 있습니다. StyleCop과 달리 FxCop은 소스가 아닌 컴파일 된 코드에서 작동합니다.
아마 처음에는 압도적입니다.모든 규칙 그룹을 해제하고 도구를 다시 실행하여 빈 슬레이트를 얻는 것이 좋습니다. 하나의 그룹을 한 번에 하나씩 사용 가능하게 설정하거나 표시되는 메시지를 해결하거나 해당 그룹의 특정 규칙이 적용되지 않는 경우 해당 규칙을 사용하지 않도록 설정합니다 (기본 규칙은 전체적으로 매우 넓기 때문에 모든 규칙이 적용되지는 않습니다. 귀하의 필요에 맞는 룰 세트).
결국 적절한 수정 프로그램을 구현하거나 관계없는 규칙을 선택적으로 사용 중지하여 모든 메시지를 해결할 수 있습니다.
기본적으로 보안 및 성능 그룹의 우선 순위는 좋지 않습니다. 이름 지정 규칙은 주관적이고 자신의 규칙과 충돌 할 수 있습니다. 만약에 그렇다면 그들을 끄십시오. 이동성과 세계화는 또한 주관적이고 필요에 따라 다릅니다. 나머지는 글쎄, 당신은 자신의 결론을 내릴 수 있습니다!
정말 도움이되는 대답입니다. 감사. –
FxCop/StyleCop의 대안 또는 좋은 보완 도구는 상용 도구 NDepend을 사용하는 것입니다. 이 도구를 사용하면 코드 규칙을 LINQ 쿼리를 통해(namely CQLinq)에 쓸 수 있습니다. 면책 조항 : 나는, 이러한 디자인, 아키텍처, 코드 품질, 코드의 진화, 명명 규칙을 포함, 기본적으로 제안 200 code rules 이상 도구
의 개발자 중 하나입니다 CQLinq 코드 규칙이 될 수 쓰기에 전념
죽은 코드, .NET FX는 사용 ... verified live in Visual Studio 또는 verified during build process and reported in an HTML/javascript report 일 수 있습니다.
의 FxCop 또는 StyleCop 이상 CQLinq의 힘은,이 코드 규칙을 작성하고 즉시 결과를 얻을 수 있도록 간단 것입니다. 일치하는 코드 요소를 찾아보기위한 기능이 제안됩니다. 구체적으로이처럼 보이는 : 그것은 의존
: 그것의 이익을 위해 노력하고 코드를 변경의 값이없는
나는 그것이 아래로 검사 도구를 전달하는 코드 기반을 얻기의 비용에 비해 현재의 코드 기반을 유지하는 비용의 수 감소에 온다 생각합니다.보다 일관성있는 코드 기반은 유지 관리 비용이 낮지 만 코드베이스를 많이 변경하는 경우이 값은 입니다.
이 코드는 작업 코드가 좋은 코드라는 잘못된 사실을 전달합니다. 좋은 코드에는 엄청난 가치가 있습니다. 유지 보수에 85 %의 시간이 소요되므로 유지 관리가 향상됩니다. 코드를 변경하는 데는 큰 가치가 있으며, 그렇지 않은 코드는 더 많습니다. 작동중인 코드는 오랜 시간 동안 방치 될 수 있으므로 문서화되고 문서화되어야합니다. 앞으로 나아갈 계획 인 스타일과 디자인에 대한 일련의 표준을 따라야하며, 향후 프로그래머가 쉽게 이해할 수있는 다른 코드도 있어야합니다. –
전적으로 동의합니다. – Steven
그래, 그들을 추가하면 얼마 동안 당신을 죽일거야 - 그것은 문제의 톤을 표시합니다. – TomTom
ReSharper를 사용할 수 없습니다. (StyleCop을 사용하는 다른 방법은? FxCop은 무엇입니까? –