Chỉ số mã Visual Studio và chỉ số bảo trì của trường hợp chuyển đổi

Question

Là một người thích thực hiện theo các phương pháp hay nhất,

Nếu tôi chạy chỉ số mã (nhấp chuột phải vào tên dự án trong trình khám phá giải pháp và chọn "Tính toán chỉ số mã" - Visual Studio 2010) vào lúc:

public static string GetFormFactor(int number) 
    { 
     string formFactor = string.Empty; 
     switch (number) 
     { 
      case 1: 
       formFactor = "Other"; 
       break; 

      case 2: 
       formFactor = "SIP"; 
       break; 

      case 3: 
       formFactor = "DIP"; 
       break; 

      case 4: 
       formFactor = "ZIP"; 
       break; 

      case 5: 
       formFactor = "SOJ"; 
       break; 
     } 

     return formFactor; 
    } 

nó mang lại cho tôi một chỉ số năng bảo trì của

(của khóa học này là không đáng kể nếu bạn chỉ có này, nhưng nếu bạn sử dụng một tiện ích như philos lớp whos ophy đang làm những việc như vậy, lớp tiện ích của bạn sẽ có chỉ số bảo trì kém nhất ..)

Giải pháp cho điều này là gì?

Answer 1

Trước hết: 61 được coi là mã có thể duy trì. Đối với chỉ số bảo trì, 100 là rất dễ dàng để duy trì mã, trong khi 0 là khó khăn để duy trì.

• 0-9 = khó để duy trì
• 10-19 = vừa phải để duy trì
• 20-100 = tốt để duy trì

khả năng bảo trì Index được dựa trên ba số liệu mã: Cụ thể Halstead Volumen, Độ phức tạp của Cyclomatic và các dòng mã và dựa trên số following formula:

MAX (0, (171 - 5.2 * ln (Halstead 0123)Volume) - 0,23 * (Cyclomatic phức tạp) - 16,2 * ln (Ngành, nghề Mã)) * 100/171)

Trong thực tế, trong ví dụ của bạn nguyên nhân gốc rễ cho giá trị thấp của Bảo trì Index là Độ phức tạp của Cyclomatic. Số liệu này được tính toán dựa trên các đường dẫn thực thi khác nhau trong mã. Thật không may, số liệu không nhất thiết phải phù hợp với "khả năng đọc của con người" của mã.

Ví dụ như mã của bạn dẫn đến giá trị chỉ số rất thấp (nhớ, thấp hơn có nghĩa là khó duy trì hơn) nhưng trên thực tế chúng rất dễ đọc. Điều này là phổ biến khi sử dụng Cyclomatic Complexity để đánh giá mã.

Hãy tưởng tượng mã có khối chuyển đổi trong ngày (Mon-Sun) cộng với khối chuyển đổi cho Tháng (tháng 1-tháng 12). Mã này sẽ rất dễ đọc và có thể duy trì được nhưng sẽ dẫn đến độ phức tạp Cyclomatic rất lớn và do đó trong Chỉ số bảo trì rất thấp trong Visual Studio 2010.

Đây là một thực tế nổi tiếng về số liệu và cần xem xét nếu mã được đánh giá dựa trên các số liệu. Thay vì xem xét số tuyệt đối, các số liệu phải được theo dõi qua thời gian để hiểu như là một chỉ số cho sự thay đổi của mã. Ví dụ. nếu chỉ số bảo trì luôn ở mức 100 và đột nhiên giảm xuống mức 10, bạn nên kiểm tra sự thay đổi đã gây ra điều này.

Answer 2

Hai điều mùa xuân trong tâm trí:

Sử dụng một enum cưới lên các mô tả và giá trị so

public enum FormFactor 
{ 
    Other = 1, 
    SIP = 2, 
    etc. 
} 

Sử dụng một lớp học hoặc struct để đại diện cho mỗi hình thức tố

public class FormFactor 
{ 
    public int Index { get; private set; } 
    public string Description { get; private set; } 

    public FormFactor(int index, string description) 
    { 
     // do validation and assign properties 
    } 
} 

Answer 3

Tôi không biết nó quan trọng như thế nào, nhưng sau đây nhận được 76:

private static string[] _formFactors = new[] { null, "Other","SIP","DIP", "ZIP", "SOJ"}; 
public static string GetFormFactor2(int number) 
{ 
    if (number < 1 || number > _formFactors.Length) 
    { 
     throw new ArgumentOutOfRangeException("number"); 
    } 

    return _formFactors[number]; 
} 

Answer 4

tôi muốn làm điều đó theo cách này và quên đi những chỉ số năng bảo trì:

public static string GetFormFactor(int number) 
{ 
    switch (number) 
    { 
     case 1: return "Other"; 
     case 2: return "SIP"; 
     case 3: return "DIP"; 
     case 4: return "ZIP"; 
     case 5: return "SOJ"; 
    } 

    return number.ToString(); 
} 

IMHO dễ đọc và dễ dàng để thay đổi.

Answer 5

Rõ ràng đối với tôi, phương pháp Enum là phương thức duy trì nhất vì nó không liên quan đến chuỗi mã cứng, do đó không có lỗi chính tả và kiểm tra cú pháp biên dịch thời gian. Chỉ những hạn chế là quy tắc đặt tên.

Answer 6

Chỉ số bảo trì có thể cao hơn do thiếu khả năng mở rộng trong phương pháp bạn chọn cho giải pháp của mình.

Giải pháp chính xác (Mark Simpson được chạm ở trên) là giải pháp có thể được mở rộng để sử dụng hệ số dạng mới mà không có mã được xây dựng lại - báo cáo chuyển đổi/trường hợp trong mã luôn là dấu hiệu cho thấy thiết kế OO đã bị lãng quên và nên luôn luôn được xem như là một mùi mã xấu.

Cá nhân, tôi sẽ thực hiện ...

interface IFormFactor 
{ 
    // some methods 
} 

class SipFormFactor : IFormFactor... 

class DipFormFactor : IFormFactor... 

Etc. 

... và có những phương pháp trên giao diện cung cấp các chức năng mong muốn - bạn có thể nghĩ về nó [Tôi đoán] như là tương tự để GOF lệnh Mẫu.

Bằng cách này các phương pháp mức độ cao hơn của bạn chỉ có thể ...

MyMethod(IFormFactor factor) 
{ 
    // some logic... 

    factor.DoSomething(); 

    // some more logic... 
} 

... và bạn có thể đi cùng vào một ngày sau đó và đưa ra một yếu tố hình thức mới mà không cần phải thay đổi mã này như bạn sẽ với mệnh đề chuyển mã hóa cứng. Bạn cũng sẽ tìm thấy cách tiếp cận này cũng dễ dàng vay mượn TDD (bạn nên kết thúc với điều này nếu bạn đang làm TDD đúng cách) vì nó rất dễ dàng để chế giễu.

Answer 7

Tôi biết câu trả lời này là rất muộn, nhưng tôi đã quan tâm đến việc chưa có ai đưa ra giải pháp từ điển. Tôi đã thấy rằng khi giao dịch với các câu lệnh chuyển đổi lớn có định hướng dữ liệu như thế này, nó thường dễ đọc hơn để thu gọn trường hợp chuyển đổi thành một từ điển.

public static readonly IDictionary<int, string> Factors = new Dictionary<int, string> { 
    { 1, "Other" }, 
    { 2, "SIP" }, 
    { 3, "DIP" }, 
    { 4, "ZIP" }, 
    { 5, "SOJ" } 
}; 

public static string GetFormFactor2(int number) 
{ 
    string formFactor = string.Empty; 
    if (Factors.ContainsKey(number)) formFactor = Factors[number]; 
    return formFactor; 
} 

này mang đến cho bạn một chỉ số năng bảo trì của 74 - thấp hơn so với các giải pháp mảng vì lớp ghép để một cuốn từ điển một chút, nhưng tôi cảm thấy đó là tổng quát hơn bởi vì nó làm việc cho bất kỳ số lượng các loại bạn thường sẽ bật. Giống như giải pháp mảng, nó phân chia rất tốt và loại bỏ rất nhiều mã lặp đi lặp lại.

Nói chung, sử dụng cách tiếp cận theo hướng dữ liệu có thể giúp mã của bạn rõ ràng hơn, vì nó phân tách các phần quan trọng (trong trường hợp này, điều kiện và kết quả) từ tàu tuần dương (trong trường hợp này, trường hợp chuyển đổi)).