Tại điểm nào là ngắn gọn không còn là một đức tính?

Một bản sửa lỗi gần đây yêu cầu tôi chuyển qua mã được viết bởi các thành viên khác trong nhóm, nơi tôi đã tìm thấy mã này (đó là C #):

return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0;

Bây giờ, cho phép có một lý do chính đáng cho tất cả các diễn viên đó, điều này dường như vẫn rất khó theo dõi. Có một lỗi nhỏ trong tính toán và tôi đã phải gỡ rối nó để khắc phục vấn đề.

Tôi biết phong cách mã hóa của người này từ đánh giá mã, và cách tiếp cận của anh ta là ngắn hơn hầu như luôn luôn tốt hơn. Và tất nhiên có giá trị ở đó: tất cả chúng ta đã thấy các chuỗi logic có điều kiện phức tạp không cần thiết có thể được làm sạch với một vài toán tử được đặt tốt. Nhưng rõ ràng anh ta lão luyện hơn tôi khi theo các chuỗi nhà điều hành nhồi nhét vào một tuyên bố duy nhất.

Tất nhiên, đây là vấn đề của phong cách. Nhưng có bất cứ điều gì đã được viết hoặc nghiên cứu để nhận ra điểm mà việc phấn đấu cho mã ngắn không còn hữu ích và trở thành rào cản đối với sự hiểu biết?

_{Lý do cho các diễn viên là Entity Framework. Các db cần lưu trữ chúng dưới dạng nullable. Số thập phân? không tương đương với số thập phân trong C # và cần được bỏ.}

Để trả lời câu hỏi của bạn về nghiên cứu còn tồn tại

Nhưng có bất cứ điều gì đã được viết hoặc nghiên cứu để nhận ra điểm mà việc phấn đấu cho mã ngắn không còn hữu ích và trở thành rào cản đối với sự hiểu biết?

Vâng, đã có công việc trong lĩnh vực này.

Để hiểu được công cụ này, bạn phải tìm cách tính toán một số liệu để có thể so sánh trên cơ sở định lượng (thay vì chỉ thực hiện so sánh dựa trên trí thông minh và trực giác, như các câu trả lời khác làm). Một số liệu tiềm năng đã được xem xét là

Độ phức tạp theo chu kỳ Các dòng mã nguồn ( SLOC )

Trong ví dụ mã của bạn, tỷ lệ này rất cao, vì mọi thứ đã được nén trên một dòng.

SATC đã tìm thấy sự đánh giá hiệu quả nhất là sự kết hợp giữa kích thước và độ phức tạp [Cyclomatic]. Các mô-đun với cả độ phức tạp cao và kích thước lớn thường có độ tin cậy thấp nhất. Các mô-đun với kích thước thấp và độ phức tạp cao cũng là một rủi ro về độ tin cậy bởi vì chúng có xu hướng rất mã, rất khó thay đổi hoặc sửa đổi.

Liên kết

Dưới đây là một vài tài liệu tham khảo nếu bạn quan tâm:

McCabe, T. và A. Watson (1994), Độ phức tạp phần mềm (CrossTalk: Tạp chí Kỹ thuật phần mềm quốc phòng).

Watson, AH, & McCabe, TJ (1996). Kiểm tra có cấu trúc: Một phương pháp thử nghiệm sử dụng thước đo độ phức tạp theo chu kỳ (Ấn phẩm đặc biệt NIST 500-235). Truy cập ngày 14 tháng 5 năm 2011, từ trang web của McCabe Software: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

Rosenberg, L., Búa, T., Shaw, J. (1998). Số liệu và độ tin cậy của phần mềm (Kỷ yếu của Hội thảo quốc tế về kỹ thuật độ tin cậy của phần mềm). Truy cập ngày 14 tháng 5 năm 2011, từ trang web của Đại học bang Pennsylvania: http://citeseerx.ist.psu.edu/viewdoc/doad?doi=10.1.1.104.4041&rep=rep1&type=pdf

Ý kiến ​​và giải pháp của tôi

Cá nhân, tôi chưa bao giờ coi trọng sự ngắn gọn, chỉ có thể đọc được. Đôi khi sự ngắn gọn giúp dễ đọc, đôi khi không. Điều quan trọng hơn là bạn đang viết Mã thực sự rõ ràng (ROC) thay vì Mã chỉ viết (WOC).

Để cho vui, đây là cách tôi sẽ viết nó và yêu cầu các thành viên trong nhóm của tôi viết nó:

if ((costIn <= 0) || (costOut <= 0)) return 0;
decimal changeAmount = costOut - costIn;
decimal changePercent = changeAmount / costOut * 100;
return changePercent;

Cũng lưu ý rằng việc giới thiệu các biến làm việc có tác dụng phụ hạnh phúc là kích hoạt số học điểm cố định thay vì số học số nguyên, do đó, cần phải decimalloại bỏ tất cả các phôi đó .

Brevity là tốt khi nó làm giảm sự lộn xộn xung quanh những thứ quan trọng, nhưng khi nó trở nên ngắn gọn , việc đóng gói quá nhiều dữ liệu liên quan quá dày đặc để dễ dàng theo dõi, thì dữ liệu liên quan sẽ trở nên lộn xộn và bạn gặp vấn đề.

Trong trường hợp cụ thể này, các diễn viên decimalsẽ được lặp đi lặp lại nhiều lần; có lẽ sẽ tốt hơn nếu viết lại nó như một cái gì đó như:

var decIn = (decimal)CostIn;
var decOut = (decimal)CostOut;
return decIn > 0 && CostOut > 0 ? (decOut - decIn ) / decOut * 100 : 0;
//                  ^ as in the question

Đột nhiên, dòng chứa logic ngắn hơn rất nhiều và nằm trên một đường ngang, do đó bạn có thể nhìn thấy mọi thứ mà không cần phải cuộn, và ý nghĩa dễ thấy hơn nhiều.

Mặc dù tôi không thể trích dẫn bất kỳ nghiên cứu cụ thể nào về chủ đề này, tôi sẽ đề nghị rằng tất cả các diễn viên trong mã của bạn đều vi phạm nguyên tắc Đừng lặp lại chính mình. Những gì mã của bạn dường như đang cố gắng làm là chuyển đổi costInvà costOutnhập Decimal, sau đó thực hiện một số kiểm tra độ tỉnh táo đối với kết quả của các chuyển đổi đó và thực hiện các thao tác bổ sung trên các giá trị được chuyển đổi đó nếu kiểm tra vượt qua. Trong thực tế, mã của bạn thực hiện một trong những kiểm tra độ tỉnh táo đối với giá trị chưa được chuyển đổi, làm tăng khả năng costOut có thể giữ giá trị lớn hơn 0, nhưng nhỏ hơn một nửa so với giá trị nhỏ nhất Decimalcó thể biểu thị. Mã sẽ rõ ràng hơn nhiều nếu nó xác định các biến loại Decimalđể giữ các giá trị được chuyển đổi, và sau đó hành động theo các giá trị đó.

Có vẻ như tò mò rằng bạn sẽ quan tâm nhiều hơn đến tỷ lệ của các Decimalđại diện costInvà costOuthơn tỷ lệ của các giá trị thực tế costInvà costOut, trừ khi mã cũng sẽ sử dụng các biểu diễn thập phân cho một số mục đích khác. Nếu mã sẽ sử dụng thêm các biểu diễn đó, thì đó sẽ là đối số tiếp theo để tạo các biến để giữ các biểu diễn đó, thay vì có một chuỗi các diễn viên tiếp tục trong suốt mã.

Tôi nhìn vào mã đó và hỏi "làm thế nào chi phí có thể bằng 0 (hoặc ít hơn)?". Trường hợp đặc biệt nào chỉ ra? Mã phải

bool BothCostsAreValidProducts = (CostIn > 0) && (CostOut > 0);
if (!BothCostsAreValidProducts)
  return NO_PROFIT;
else {
   // that calculation here...
}

Tôi đoán là đặt tên ở đây: thay đổi BothCostsAreValidProductsvà NO_PROFITphù hợp.

Brevity ngừng là một đức tính khi chúng ta quên nó có nghĩa là kết thúc chứ không phải là một đức tính trong chính nó. Chúng tôi thích sự ngắn gọn vì nó tương quan với sự đơn giản và chúng tôi thích sự đơn giản vì mã đơn giản dễ hiểu hơn và dễ sửa đổi hơn và chứa ít lỗi hơn. Cuối cùng, chúng tôi muốn mã để đạt được các mục tiêu này:

1. Hoàn thành các yêu cầu kinh doanh với số lượng công việc ít nhất

2. Tránh lỗi

3. Cho phép chúng tôi thực hiện các thay đổi trong tương lai tiếp tục thực hiện 1 và 2

Đây là những mục tiêu. Bất kỳ nguyên tắc hoặc phương pháp thiết kế nào (có thể là KISS, YAGNI, TDD, RẮN, bằng chứng, hệ thống loại, siêu lập trình động, v.v.) chỉ có đạo đức trong phạm vi chúng giúp chúng ta đạt được những mục tiêu này.

Các dòng trong câu hỏi dường như đã bỏ lỡ tầm nhìn của mục tiêu cuối cùng. Trong khi nó ngắn, nó không đơn giản. Nó thực sự chứa sự dư thừa không cần thiết bằng cách lặp lại cùng một thao tác đúc nhiều lần. Lặp lại mã làm tăng sự phức tạp và khả năng xảy ra lỗi. Kết hợp việc đúc với tính toán thực tế cũng làm cho mã khó theo dõi.

Dòng này có ba mối quan tâm: Bảo vệ (vỏ đặc biệt 0), loại đúc và tính toán. Mỗi mối quan tâm là khá đơn giản khi được thực hiện trong sự cô lập, nhưng vì tất cả đã được xen kẽ trong cùng một biểu thức, nó trở nên khó theo dõi.

Không rõ tại sao CostOutlần đầu tiên nó không được sử dụng CostIn. Có thể có một lý do chính đáng, nhưng ý định không rõ ràng (ít nhất là không có ngữ cảnh), điều đó có nghĩa là một người bảo trì sẽ cảnh giác khi thay đổi mã này bởi vì có thể có một số giả định ẩn. Và đây là sự vô cảm đối với khả năng duy trì.

Vì CostInđược truyền trước khi so sánh với 0 nên tôi giả sử đó là giá trị dấu phẩy động. (Nếu đó là một int thì sẽ không có lý do để phân vai). Nhưng nếu CostOutlà số float thì mã có thể ẩn một lỗi chia nhỏ không rõ ràng, vì giá trị dấu phẩy động có thể nhỏ nhưng khác không, nhưng bằng 0 khi chuyển thành số thập phân (ít nhất tôi tin rằng điều này có thể xảy ra.)

Vì vậy, vấn đề không phải là ngắn gọn hay thiếu nó, vấn đề là logic lặp đi lặp lại và sự kết hợp các mối quan tâm dẫn đến mã khó duy trì.

Việc đưa ra các biến để giữ các giá trị được đúc có thể sẽ tăng kích thước mã được tính theo số lượng mã thông báo, nhưng sẽ làm giảm độ phức tạp, các mối quan tâm riêng biệt và cải thiện độ rõ ràng, giúp chúng ta đến gần hơn với mục tiêu mã dễ hiểu và duy trì hơn.

Brevity không phải là một đức tính ở tất cả. Dễ đọc là đức hạnh.

Brevity có thể là một công cụ để đạt được đức tính, hoặc, như trong ví dụ của bạn, có thể là một công cụ để đạt được điều gì đó hoàn toàn ngược lại. Bằng cách này hay cách khác, nó hầu như không có giá trị của riêng nó. Quy tắc rằng mã phải "càng ngắn càng tốt" có thể được thay thế bằng "càng tục tĩu càng tốt" - tất cả đều vô nghĩa và có khả năng gây hại nếu chúng không phục vụ mục đích lớn hơn.

Ngoài ra, mã bạn đã đăng thậm chí không tuân theo quy tắc ngắn gọn. Các hằng số đã được khai báo với M hậu tố, hầu hết các kinh khủng (decimal)phôi có thể tránh được, như trình biên dịch sẽ thúc đẩy còn lại intđể decimal. Tôi tin rằng người mà bạn mô tả chỉ đơn thuần là sử dụng sự ngắn gọn như một cái cớ. Nhiều khả năng không cố tình, nhưng vẫn còn.

Trong những năm kinh nghiệm của mình, tôi tin rằng sự ngắn gọn cuối cùng là thời gian - thời gian chi phối mọi thứ khác. Điều đó bao gồm cả thời gian thực hiện - một chương trình mất bao lâu để thực hiện một công việc - và thời gian bảo trì - mất bao lâu để thêm các tính năng hoặc sửa lỗi. (Việc bạn cân bằng hai yếu tố này như thế nào tùy thuộc vào tần suất mã được đề cập so với cải thiện - hãy nhớ rằng tối ưu hóa sớm vẫn là gốc rễ của mọi tội lỗi .) Lực hấp dẫn của mã là để cải thiện sự ngắn gọn của cả hai; mã ngắn hơn thường chạy nhanh hơn, và thường dễ hiểu hơn và do đó duy trì. Nếu nó không làm gì, thì đó là một mạng âm.

Trong trường hợp được hiển thị ở đây, tôi nghĩ rằng sự ngắn gọn của văn bản đã bị hiểu sai là sự ngắn gọn của số lượng dòng, với chi phí dễ đọc, có thể làm tăng thời gian bảo trì. (Cũng có thể mất nhiều thời gian hơn để thực hiện, tùy thuộc vào cách thực hiện quá trình truyền, nhưng trừ khi dòng trên được chạy hàng triệu lần, điều đó có thể không đáng lo ngại.) Trong trường hợp này, các dấu thập phân lặp đi lặp lại làm mất khả năng đọc, vì nó khó hơn xem tính toán quan trọng nhất là gì Tôi đã có thể viết như sau:

decimal dIn = (decimal)CostIn;
decimal dOut = (decimal)CostOut;
return dIn > 0 && CostOut > 0 ? ((dOut - dIn) / dOut) * 100 : 0;

(Chỉnh sửa: đây là mã giống như câu trả lời khác, vì vậy bạn đi.)

Tôi là một fan hâm mộ của nhà điều hành ternary ? :, vì vậy tôi sẽ để nó ở đó.

Giống như hầu hết tất cả các câu trả lời trên dễ đọc nên luôn luôn là mục tiêu chính của bạn. Tuy nhiên tôi cũng nghĩ định dạng có thể là một cách hiệu quả hơn để đạt được điều này qua việc tạo các biến và các dòng mới.

return ((decimal)CostIn > 0 && CostOut > 0) ?
       100 * ( (decimal)CostOut - (decimal)CostIn ) / (decimal)CostOut:
       0;

Tôi đồng ý mạnh mẽ với đối số phức tạp chu kỳ trong hầu hết các trường hợp, tuy nhiên chức năng của bạn có vẻ nhỏ và đủ đơn giản để giải quyết tốt hơn với trường hợp kiểm tra tốt. Vì tò mò tại sao cần phải đúc thành thập phân?

Đối với tôi, có vẻ như một vấn đề lớn với khả năng đọc ở đây nằm ở việc thiếu định dạng hoàn toàn.

Tôi sẽ viết nó như thế này:

return (decimal)CostIn > 0 && CostOut > 0 
            ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 
            : 0;

Tùy thuộc vào loại CostInvà CostOutlà loại dấu phẩy động hay loại tích phân, một số phôi cũng có thể không cần thiết. Không giống như floatvà double, các giá trị tích phân được ngầm phát huy decimal.

Mã có thể được viết vội vàng, nhưng mã trên trong thế giới của tôi nên được viết với tên biến tốt hơn nhiều.

Và nếu tôi đọc mã chính xác thì nó đang cố gắng thực hiện phép tính Grossmargin.

var totalSales = CostOut;
var totalCost = CostIn;
var profit = (decimal)(CostOut - CostIn);
var grossMargin = 0m; //profit expressed as percentage of totalSales

if(profit > 0)
{
    grossMargin = profit/totalSales*100
}

Tôi giả sử CostIn * CostOut là số nguyên
Đây là cách tôi sẽ viết nó
M (Tiền) là số thập phân

return CostIn > 0 && CostOut > 0 ? 100M * (CostOut - CostIn) / CostOut : 0M;

Mã được viết để được mọi người hiểu; sự ngắn gọn trong trường hợp này không mua nhiều và làm tăng gánh nặng cho người bảo trì. Đối với sự ngắn gọn này, bạn tuyệt đối nên mở rộng điều đó bằng cách làm cho mã tự ghi lại nhiều hơn (tên biến tốt hơn) hoặc thêm nhiều bình luận giải thích lý do tại sao nó hoạt động theo cách này.

Khi bạn viết mã để giải quyết vấn đề hôm nay, mã đó có thể là vấn đề vào ngày mai khi yêu cầu thay đổi. Bảo trì luôn phải được tính đến và cải thiện tính dễ hiểu của mã là điều cần thiết.

Brevity không còn là một đức tính khi

• Có Bộ phận mà không có kiểm tra trước cho số không.
• Không có kiểm tra cho null.
• Không có dọn dẹp.
• TRY CATCH so với ném lên chuỗi thức ăn nơi có thể xử lý lỗi.
• Giả định được thực hiện về thứ tự hoàn thành các nhiệm vụ không đồng bộ
• Nhiệm vụ sử dụng độ trễ thay vì lên lịch lại trong tương lai
• Không cần IO được sử dụng
• Không sử dụng cập nhật lạc quan

Nếu điều này đã vượt qua các thử nghiệm đơn vị xác nhận, thì nó sẽ ổn, nếu một thông số mới được thêm vào, một thử nghiệm mới hoặc một triển khai nâng cao được yêu cầu và nó được yêu cầu "gỡ rối" độ căng của mã, đó là khi vấn đề sẽ phát sinh.

Rõ ràng là một lỗi trong mã cho thấy rằng có một vấn đề khác với Q / A là một sự giám sát, vì vậy thực tế là có một lỗi không bị bắt là nguyên nhân gây lo ngại.

Khi xử lý các yêu cầu phi chức năng như "khả năng đọc" của mã, nó cần được xác định bởi người quản lý phát triển và được quản lý bởi nhà phát triển chính và được các nhà phát triển tôn trọng để đảm bảo triển khai đúng.

Cố gắng đảm bảo triển khai mã được chuẩn hóa (các tiêu chuẩn và quy ước) để đảm bảo "khả năng đọc" và dễ "bảo trì". Nhưng nếu các thuộc tính chất lượng này không được xác định và thi hành, thì bạn sẽ kết thúc bằng mã như ví dụ trên.

Nếu bạn không muốn xem loại mã này, thì hãy cố gắng để nhóm đồng ý về các tiêu chuẩn và quy ước thực hiện và viết nó xuống và thực hiện đánh giá mã ngẫu nhiên hoặc kiểm tra tại chỗ để xác thực quy ước đang được tôn trọng.