Mục đích của phân tích mã là gì và khi nào tôi cần sử dụng nó?


26

Tôi đã nghe về phân tích Mã của Visual Studio nhưng chưa bao giờ sử dụng. Tôi đã đọc MSDN , nhưng vẫn không hiểu cách sử dụng phân tích Mã thực sự.

Nó không giống như StyleCop sao?

Ở đâu đó, FxCop cũng được đề cập. Sự khác biệt với phân tích mã là gì?

Tôi có cần sử dụng phân tích mã cho mọi dự án không? Là đánh giá mã được thực hiện bởi các đồng nghiệp của tôi không đủ?

Câu trả lời:


36

Phân tích mã là gì?

Phân tích mã (trước đây là FxCop) là một công cụ phân tích tĩnh tìm kiếm các mẫu phổ biến có thể chỉ ra rằng có gì đó không đúng trong mã nguồn. Ví dụ: nếu một thể hiện của một lớp thực hiện IDisposablekhông được xử lý đúng cách, phân tích mã sẽ phát ra một cảnh báo:

private void DoSomething()
{
    var connection = new SqlConnection(...);
    this.ChangeSomeData(connection);
}

Đây là cách thực hiện đúng của đoạn mã trước:

private void DoSomething()
{
    using (var connection = new SqlConnection(...))
    {
        this.ChangeSomeData(connection);
    }
}

Như bất kỳ công cụ phân tích tĩnh nào, phân tích mã được dự định để tìm các mẫu rườm rà (hoặc đơn giản là nhàm chán) để tìm thủ công. Ví dụ, trong ví dụ trước, nhà phát triển có thể khá nhàm chán khi kiểm tra xem có lớp nào anh ta sử dụng thực hiện không IDisposable(hoặc để nhớ tất cả các lớp .NET Framework thực hiện nó).

Những dự án đủ điều kiện?

Mặc dù nó có thể là dương tính giả, như bất kỳ công cụ phân tích tĩnh nào, thường có lợi khi nhắm mục tiêu cảnh báo bằng không cho mã quan trọng trong kinh doanh mà không sử dụng các triệt tiêu . Trong Visual Studio, phân tích mã có thể được cấu hình để chạy ở thời gian biên dịch; nếu cài đặt dự án cũng xác định rằng các cảnh báo phải được coi là lỗi, vi phạm quy tắc phân tích Mã sẽ không được chú ý.

Vì phân tích tĩnh có thể mất một thời gian cho các dự án trung bình hoặc lớn, nên thường chuyển nó từ các máy của nhà phát triển sang máy chủ xây dựng TFS. Mặc dù chạy phân tích Mã trong quá trình xác nhận trước không phải là một ý tưởng hay (không giống như StyleCop), nó vẫn có thể chạy trên bản dựng và thất bại nếu tìm thấy cảnh báo.

Đối với mã không quan trọng cho doanh nghiệp, phân tích mã có thể được chạy thủ công từ Visual Studio hoặc dòng lệnh. Các kiểm tra và cảnh báo có thể được xử lý chi tiết trong các thuộc tính của dự án để phù hợp với nhu cầu của bạn. Ví dụ, cảnh báo toàn cầu hóa có thể bị tắt nếu dự án của bạn không có ý định địa phương hóa.

Như với StyleCop, điều cần thiết là quyết định xem dự án có nhắm mục tiêu cảnh báo bằng không từ phân tích Mã từ khi bắt đầu dự án hay không. Giới thiệu nó trong một dự án tồn tại có thể quá đau đớn.

Có khác với StyleCop không?

Lưu ý rằng phân tích mã không giống với StyleCop . Sự khác biệt đầu tiên là phân tích Code hoạt động với phần được biên dịch, trong khi StyleCop hoạt động với chính nguồn đó. Sự khác biệt thứ hai (và quan trọng nhất) là phân tích mã tìm kiếm các patters có thể chỉ ra lỗi, trong khi StyleCop chỉ đơn giản là thực thi các quy tắc kiểu cách một quy ước đơn giản được sử dụng bởi nhóm của bạn.

Phân tích mã cũng đặc biệt hữu ích cho những người mới bắt đầu không biết nhiều về ngôn ngữ , vì nó thường có thể dẫn đến "Aha!" khoảnh khắc. Ví dụ : CA2105: Không nên đọc các trường mảng chỉ có thể dẫn ai đó đến một khám phá rằng ngay cả khi một mảng được đánh dấu là chỉ đọc, nó không làm cho nó bất biến, vì không có gì cấm thay đổi các thành phần trong mảng. StyleCop không dẫn đến những khám phá: không có gì thú vị khi biết rằng các trường bắt đầu bằng một chữ cái viết thường hoặc các cuộc gọi cục bộ nên được bắt đầu bằng this.

Ngay cả khi một số quy tắc được thi hành bởi cả Phân tích mã và StyleCop (chẳng hạn như CA1707: Mã định danh không được chứa dấu gạch dưới so với SA1310: Tên trường không được chứa dấu gạch dưới ), hai công cụ này là bổ sung và thường được sử dụng cạnh nhau.

Chúng tôi đã có mã đánh giá

Sự hiện diện của các đánh giá mã không phải là một lý do để tránh phân tích Mã. Cả Phân tích mã và StyleCop đều xuất sắc trong việc tìm kiếm mọi thứ tự động trước khi xem xét mã. Không có gì tệ hơn là dành một bài đánh giá mã xác định các vấn đề về kiểu hoặc các mẫu có vấn đề có thể được tìm thấy tự động. Giữ mã đánh giá cho những thứ thú vị.

Một khía cạnh khác là các nhà đánh giá của con người không nhất thiết phải phát hiện ra các vấn đề được tìm thấy bởi phân tích Code. Ví dụ, một thể hiện của một lớp triển khai IDisposablecó thể được tạo ở một vị trí, và sau đó được xử lý ở một vị trí khác. Sẽ mất một chút thời gian để người đánh giá tìm thấy nó, trong khi chỉ mất vài mili giây cho một công cụ phân tích tĩnh để khám phá nó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.