Trong Clean Code , tác giả đưa ra một ví dụ về

assertExpectedEqualsActual(expected, actual)

đấu với

assertEquals(expected, actual)

với cái trước được tuyên bố là rõ ràng hơn bởi vì nó loại bỏ sự cần thiết phải nhớ nơi tranh luận và sự lạm dụng tiềm năng đến từ đó. Tuy nhiên, tôi chưa bao giờ thấy một ví dụ về sơ đồ đặt tên trước trong bất kỳ mã nào và luôn luôn thấy cái sau. Tại sao các lập trình viên không chấp nhận cái trước nếu như, như tác giả khẳng định, rõ ràng hơn cái sau?

Bởi vì nó là nhiều hơn để gõ và nhiều hơn để đọc

Lý do đơn giản nhất là mọi người thích gõ ít hơn và mã hóa thông tin đó có nghĩa là gõ nhiều hơn. Khi đọc nó, mỗi khi tôi phải đọc toàn bộ ngay cả khi tôi đã quen với thứ tự của các đối số nên là gì. Ngay cả khi không quen thuộc với thứ tự lập luận ...

Nhiều nhà phát triển sử dụng IDE

IDE thường cung cấp một cơ chế để xem tài liệu cho một phương thức nhất định bằng cách di chuột hoặc qua một phím tắt. Bởi vì điều này, tên của các tham số luôn trong tầm tay.

Mã hóa các đối số giới thiệu trùng lặp và khớp nối

Tên của các tham số nên ghi lại chúng là gì. Bằng cách viết tên trong tên phương thức, chúng tôi cũng đang sao chép thông tin đó trong chữ ký phương thức. Chúng tôi cũng tạo ra một khớp nối giữa tên phương thức và các tham số. Nói expectedvà actualgây nhầm lẫn cho người dùng của chúng tôi. Đi từ assertEquals(expected, actual)đến assertEquals(planned, real)không yêu cầu thay đổi mã máy khách bằng cách sử dụng chức năng. Đi từ assertExpectedEqualsActual(expected, actual)đến assertPlannedEqualsReal(planned, real)có nghĩa là một sự thay đổi đột phá đối với API. Hoặc chúng ta không thay đổi tên phương thức, điều này nhanh chóng trở nên khó hiểu.

Sử dụng các loại thay vì các đối số mơ hồ

Vấn đề thực sự là chúng ta có những lý lẽ mơ hồ dễ dàng chuyển đổi vì chúng cùng loại. Thay vào đó, chúng ta có thể sử dụng hệ thống loại và trình biên dịch của mình để thực thi đúng thứ tự:

class Expected<T> {
    private T value;
    Expected(T value) { this.value = value; }
    static Expected<T> is(T value) { return new Expected<T>(value); }
}

class Actual<T> {
    private T value;
    Actual(T value) { this.value = value; }
    static Actual<T> is(T value) { return new Actual<T>(value); }
}

static assertEquals(Expected<T> expected, Actual<T> actual) { /* ... */ }

// How it is used
assertEquals(Expected.is(10), Actual.is(x));

Điều này sau đó có thể được thi hành ở cấp độ trình biên dịch và đảm bảo rằng bạn không thể đưa chúng ngược lại. Tiếp cận từ một góc độ khác, đây thực chất là những gì thư viện Hamcrest làm cho các bài kiểm tra.

Bạn hỏi về một cuộc tranh luận lâu dài trong lập trình. Bao nhiêu là dài dòng là tốt? Như một câu trả lời chung, các nhà phát triển đã nhận thấy rằng tính dài dòng thêm vào việc đặt tên cho các đối số là không xứng đáng.

Độ dài không phải lúc nào cũng có nghĩa là rõ ràng hơn. Xem xét

copyFromSourceStreamToDestinationStreamWithoutBlocking(fileStreamFromChoosePreferredOutputDialog, heuristicallyDecidedSourceFileHandle)

đấu với

copy(output, source)

Cả hai đều chứa cùng một lỗi, nhưng chúng ta có thực sự làm cho việc tìm lỗi đó dễ dàng hơn không? Theo nguyên tắc chung, điều dễ dàng nhất để gỡ lỗi là khi mọi thứ đều cực kỳ ngắn gọn, ngoại trừ một vài điều có lỗi và những điều đó đủ dài để nói cho bạn biết điều gì đã xảy ra.

Có một lịch sử lâu dài về việc thêm tính dài dòng. Ví dụ, có " ký hiệu Hungary " không phổ biến đã cho chúng ta những cái tên tuyệt vời như thế lpszName. Điều đó nói chung đã giảm bởi các bên trong cộng đồng lập trình viên nói chung. Tuy nhiên, việc thêm ký tự vào tên biến thành viên (như mNamehoặc m_Namehoặc name_) tiếp tục phổ biến trong một số vòng kết nối. Những người khác đã bỏ nó hoàn toàn. Tôi tình cờ làm việc trên một cơ sở mã mô phỏng vật lý có tài liệu kiểu mã hóa yêu cầu bất kỳ hàm nào trả về một vectơ phải chỉ định khung của vectơ trong lệnh gọi hàm ( getPositionECEF).

Bạn có thể quan tâm đến một số ngôn ngữ được Apple phổ biến. Objective-C bao gồm các tên đối số như là một phần của chữ ký hàm (Hàm [atm withdrawFundsFrom: account usingPin: userProvidedPin]được viết trong tài liệu là withdrawFundsFrom:usingPin:. Đó là tên của hàm). Swift đã đưa ra một tập hợp các quyết định tương tự, yêu cầu bạn đặt các tên đối số trong các lệnh gọi hàm ( greet(person: "Bob", day: "Tuesday")).

Tác giả của "Clean Code" chỉ ra một vấn đề hợp pháp, nhưng giải pháp được đề xuất của ông là không phù hợp. Thường có những cách tốt hơn để cải thiện tên phương thức không rõ ràng.

Anh ta đúng rằng assertEquals(từ các thư viện kiểm tra đơn vị kiểu xUnit) không làm rõ đối số nào là mong đợi và thực tế nào. Cái này cũng cắn tôi! Nhiều thư viện kiểm thử đơn vị đã lưu ý vấn đề và đã đưa ra các cú pháp thay thế, như:

actual.Should().Be(expected);

Hoặc tương tự. Mà chắc chắn là rõ ràng hơn nhiều assertEqualsnhưng cũng tốt hơn nhiều assertExpectedEqualsActual. Và nó cũng là nhiều composable hơn.

Bạn đang cố gắng điều khiển con đường của mình giữa Scylla và Charybdis trở nên rõ ràng, cố gắng tránh sự dài dòng vô dụng (còn được gọi là lan man vô mục đích) cũng như sự ngắn gọn quá mức (còn được gọi là sự khó hiểu về mật mã).

Vì vậy, chúng ta phải xem xét giao diện mà bạn muốn đánh giá, một cách để thực hiện các xác nhận gỡ lỗi rằng hai đối tượng bằng nhau.

1. Có bất kỳ chức năng nào khác mà nó có thể được xem xét arity và tên?
   Không, vì vậy tên của nó là đủ rõ ràng.
2. Là các loại có ý nghĩa?
   Không, vì vậy hãy bỏ qua chúng. Bạn đã làm điều đó chưa? Tốt
3. Là nó đối xứng trong các đối số của nó?
   Gần như, về lỗi, thông báo đặt mỗi đại diện đối số vào vị trí của riêng họ.

Vì vậy, hãy xem liệu sự khác biệt nhỏ đó có ý nghĩa gì không, và không được bao hàm bởi các quy ước mạnh mẽ hiện có.

Là khán giả dự định bất tiện nếu các đối số được trao đổi vô tình?
Không, các nhà phát triển cũng có được một stack-track và họ phải xem xét kỹ lưỡng mã nguồn để sửa lỗi.
Ngay cả khi không có dấu vết ngăn xếp đầy đủ, vị trí xác nhận sẽ giải quyết câu hỏi đó. Và nếu thậm chí còn thiếu và không rõ ràng từ thông điệp đó là gì, thì nhiều nhất nó sẽ nhân đôi khả năng.

Liệu các đối số có tuân theo quy ước?
Có vẻ là trường hợp. Mặc dù có vẻ như tốt nhất là một quy ước yếu.

Do đó, sự khác biệt trông khá không đáng kể và thứ tự đối số được bao phủ bởi quy ước đủ mạnh đến mức mọi nỗ lực để mã hóa nó vào tên hàm có tiện ích âm.

Thường thì nó không thêm bất kỳ sự rõ ràng logic nào.

So sánh "Thêm" với "AddFirstArgumentToSecondArgument".

Nếu bạn cần một sự quá tải đó, giả sử, thêm ba giá trị. Điều gì sẽ có ý nghĩa hơn?

Một "Thêm" với ba đối số?

hoặc là

"AddFirstAndSecondAndThirdArgument"?

Tên của phương thức nên truyền đạt ý nghĩa logic của nó. Nó sẽ nói những gì nó làm. Nói, ở cấp độ vi mô, những bước cần thực hiện không giúp người đọc dễ dàng hơn. Tên của các đối số sẽ cung cấp thêm chi tiết nếu cần. Nếu bạn cần thêm chi tiết, mã sẽ ở ngay đó cho bạn.

Tôi muốn thêm một cái gì đó được gợi ý bởi các câu trả lời khác, nhưng tôi không nghĩ đã được đề cập rõ ràng:

@puck nói "Vẫn không có gì đảm bảo đối số được đề cập đầu tiên trong tên hàm thực sự là tham số đầu tiên."

@cbojar nói "Sử dụng các loại thay vì các đối số mơ hồ"

Vấn đề là ngôn ngữ lập trình không hiểu tên: chúng chỉ được coi là biểu tượng nguyên tử mờ đục. Do đó, giống như với các nhận xét mã, không nhất thiết có bất kỳ mối tương quan nào giữa chức năng được đặt tên và cách thức hoạt động của nó.

So sánh assertExpectedEqualsActual(foo, bar)với một số lựa chọn thay thế (từ trang này và các nơi khác), như:

# Putting the arguments in a labelled structure
assertEquals({expected: foo, actual: bar})

# Using a keyword arguments language feature
assertEquals(expected=foo, actual=bar)

# Giving the arguments different types, forcing us to wrap them
assertEquals(Expected(foo), Actual(bar))

# Breaking the symmetry and attaching the code to one of the arguments
bar.Should().Be(foo)

Tất cả đều có cấu trúc nhiều hơn tên verbose, mang lại cho ngôn ngữ một cái gì đó không mờ đục để xem xét. Định nghĩa và cách sử dụng của hàm cũng phụ thuộc vào cấu trúc này, do đó, nó không thể không đồng bộ với những gì triển khai đang thực hiện (như tên hoặc bình luận có thể).

Khi tôi gặp phải hoặc thấy trước một vấn đề như thế này, trước khi tôi hét vào máy tính của mình trong sự thất vọng, trước tiên tôi dành một chút thời gian để hỏi liệu có công bằng không khi đổ lỗi cho máy. Nói cách khác, máy có được cung cấp đủ thông tin để phân biệt thứ tôi muốn với thứ tôi yêu cầu không?

Một cuộc gọi như assertEqual(expected, actual)có ý nghĩa nhiều như assertEqual(actual, expected)vậy, vì vậy chúng ta dễ dàng khiến chúng bị lẫn lộn và để máy cày trước và làm sai. Nếu chúng ta sử dụng assertExpectedEqualsActualthay thế, nó có thể khiến chúng ta ít mắc lỗi hơn, nhưng nó không cung cấp thêm thông tin cho máy (nó không thể hiểu tiếng Anh và việc chọn tên sẽ không ảnh hưởng đến ngữ nghĩa).

Điều làm cho các cách tiếp cận "có cấu trúc" được ưa thích hơn, như đối số từ khóa, trường được gắn nhãn, loại khác biệt, v.v. là thông tin bổ sung cũng có thể đọc được bằng máy , vì vậy chúng ta có thể phát hiện ra cách sử dụng máy không chính xác và giúp chúng ta làm đúng. Các assertEqualtrường hợp không phải là quá xấu, vì vấn đề duy nhất là thông điệp không chính xác. Một ví dụ độc ác hơn có thể là String replace(String old, String new, String content), dễ nhầm lẫn với String replace(String content, String old, String new)nó có một ý nghĩa rất khác nhau. Một biện pháp khắc phục đơn giản là lấy một cặp [old, new], điều này sẽ gây ra lỗi gây ra lỗi ngay lập tức (ngay cả khi không có loại).

Lưu ý rằng ngay cả với các loại, chúng tôi có thể thấy mình không 'nói với máy những gì chúng tôi muốn'. Ví dụ, mô hình chống được gọi là "lập trình gõ chuỗi" coi tất cả dữ liệu là chuỗi, giúp dễ dàng có được các đối số lẫn lộn (như trường hợp này), để quên thực hiện một số bước (ví dụ: thoát), để vô tình phá vỡ bất biến (ví dụ: làm cho JSON không thể nhìn thấy), v.v.

Điều này cũng liên quan đến "mù boolean", trong đó chúng tôi tính toán một loạt các booleans (hoặc số, v.v.) trong một phần của mã, nhưng khi cố gắng sử dụng chúng trong một phần khác, chúng không rõ chúng thực sự đại diện cho cái gì chúng tôi đã có họ trộn lên, vv Hãy so sánh này để ví dụ như sự đếm riêng biệt có tên mô tả (ví dụ LOGGING_DISABLEDchứ không phải false) và gây một thông báo lỗi nếu chúng tôi nhận được chúng lẫn lộn.

bởi vì nó loại bỏ sự cần thiết phải nhớ nơi các đối số đi

Có thật không? Vẫn không có gì đảm bảo đối số được đề cập đầu tiên trong tên hàm thực sự là tham số đầu tiên. Vì vậy, tốt hơn nên tìm kiếm nó (hoặc để IDE của bạn làm điều đó) và ở lại với tên hợp lý hơn là mù quáng dựa vào một cái tên khá ngớ ngẩn.

Nếu bạn đọc mã, bạn sẽ dễ dàng thấy điều gì xảy ra khi các tham số được đặt tên như mong muốn. copy(source, destination)là dễ hiểu hơn nhiều so với những thứ như vậy copyFromTheFirstLocationToTheSecondLocation(placeA, placeB).

Tại sao các lập trình viên không chấp nhận cái trước nếu như, như tác giả khẳng định, rõ ràng hơn cái sau?

Bởi vì có nhiều quan điểm khác nhau về các phong cách khác nhau và bạn có thể tìm thấy x tác giả của các bài viết khác nói ngược lại. Bạn sẽ phát điên khi cố gắng làm theo mọi thứ mà ai đó viết ở đâu đó ;-)

Tôi đồng ý rằng mã hóa tên tham số thành tên hàm làm cho việc viết và sử dụng các hàm trực quan hơn.

copyFromSourceToDestination( // "...ahh yes, the source directory goes first"

Thật dễ dàng để quên thứ tự của các đối số trong các hàm và các lệnh shell và nhiều lập trình viên dựa vào các tính năng IDE hoặc tham chiếu hàm vì lý do này. Có các đối số được mô tả trong tên sẽ là một giải pháp hùng hồn cho sự phụ thuộc này.

Tuy nhiên, một khi được viết, việc mô tả các đối số sẽ trở thành lỗi cho người lập trình tiếp theo phải đọc câu lệnh, vì trong hầu hết các trường hợp, các biến được đặt tên sẽ được sử dụng.

copy(sourceDir, destinationDir); // "...makes sense"

Sự căng thẳng của điều này sẽ chiến thắng hầu hết các lập trình viên và cá nhân tôi thấy nó dễ đọc hơn.

EDIT: Như @Blrfl đã chỉ ra, các tham số mã hóa không phải là 'trực quan' vì bạn cần phải nhớ tên của hàm ở vị trí đầu tiên. Điều này đòi hỏi phải tra cứu các tham chiếu chức năng hoặc nhận trợ giúp từ IDE có khả năng sẽ cung cấp thông tin đặt hàng tham số.