Là xác định một biến để đặt tên cho một đối số phương thức là một thực tiễn tốt?

Để dễ đọc, tôi thường thấy mình xác định các biến tạm thời trong khi gọi các hàm, chẳng hạn như đoạn mã sau

var preventUndo = true;
doSomething(preventUndo);

Phiên bản ngắn hơn của điều này sẽ là,

doSomething(true);

Nhưng khi tôi quay lại mã tôi thường tự hỏi những gì trueđề cập đến. Có một quy ước cho loại câu hỏi hóc búa này không?

Giải thích các biến

Trường hợp của bạn là một ví dụ về giới thiệu giải thích tái cấu trúc biến . Nói tóm lại, một biến giải thích là một biến không thực sự cần thiết, nhưng cho phép bạn đặt tên rõ ràng cho một cái gì đó, với mục đích tăng khả năng đọc.

Mã chất lượng tốt truyền đạt ý định đến người đọc; và như một nhà phát triển chuyên nghiệp khả năng đọc và bảo trì là mục tiêu số 1 của bạn.

Như vậy, quy tắc ngón tay cái tôi muốn giới thiệu là: nếu mục đích của tham số của bạn không rõ ràng ngay lập tức, hãy sử dụng một biến để đặt cho nó một cái tên hay. Tôi nghĩ rằng đây là một thực hành tốt nói chung (trừ khi lạm dụng). Đây là một ví dụ nhanh chóng, dễ hiểu - xem xét:

editButton.Enabled = (_grid.SelectedRow != null && ((Person)_grid.SelectedRow).Status == PersonStatus.Active);

so với hơi dài hơn, nhưng rõ ràng hơn:

bool personIsSelected = (_grid.SelectedRow != null);
bool selectedPersonIsEditable = (personIsSelected && ((Person)_grid.SelectedRow).Status == PersonStatus.Active)
editButton.Enabled = (personIsSelected && selectedPersonIsEditable);

Thông số Boolean

Ví dụ của bạn thực sự nêu bật lý do tại sao các booleans trong API thường là một ý tưởng tồi - về phía gọi, họ không làm gì để giải thích những gì đang xảy ra. Xem xét:

ParseFolder(true, false);

Bạn sẽ phải tìm hiểu ý nghĩa của các tham số đó; nếu chúng là enum, nó sẽ rõ ràng hơn nhiều:

ParseFolder(ParseBehaviour.Recursive, CompatibilityOption.Strict);

Biên tập:

Đã thêm các tiêu đề và hoán đổi thứ tự của hai đoạn chính, vì có quá nhiều người đang tập trung vào phần tham số boolean (công bằng mà nói, đó là đoạn đầu tiên ban đầu). Cũng đã thêm một ví dụ cho phần đầu tiên.

Đừng viết mã bạn không cần.

Nếu bạn thấy doSomething(true)khó hiểu, bạn nên thêm một bình luận:

// Do something and prevent the undo.
doSomething(true);

hoặc, nếu ngôn ngữ hỗ trợ nó, hãy thêm tên tham số:

doSomething(preventUndo: true);

Mặt khác, dựa vào IDE của bạn để cung cấp cho bạn chữ ký của phương thức được gọi:

Những trường hợp hữu ích

Đặt một biến bổ sung có thể hữu ích:

1. Đối với mục đích gỡ lỗi:

   var productId = this.Data.GetLastProductId();
   this.Data.AddToCart(productId);
   

   Mã tương tự có thể được viết trong một dòng, nhưng nếu bạn muốn đặt một điểm dừng trước khi thêm sản phẩm vào giỏ hàng để xem id sản phẩm có chính xác hay không, viết hai dòng thay vì một dòng là một ý tưởng hay.

2. Nếu bạn có một phương thức với nhiều tham số và mỗi tham số sẽ đi từ một đánh giá. Trong một dòng, điều này có thể trở nên hoàn toàn không thể đọc được.

   // Even with indentation, this is unreadable.
   var doSomething(
       isSomethingElse ? 0 : this.getAValue(),
       this.getAnotherOne() ?? this.default,
       (a + b + c + d + e) * f,
       this.hello ? this.world : (this.hello2 ? this.world2 : -1));
   

3. Nếu việc đánh giá một tham số quá phức tạp. Một ví dụ về mã tôi đã thấy:

   // Wouldn't it be easier to have several if/else's (maybe even in a separate method)?
   do(something ? (hello ? world : -1) : (programmers ? stackexchange : (com ? -1 : 0)));
   

Tại sao không trong các trường hợp khác?

Tại sao bạn không nên tạo các biến bổ sung trong các trường hợp đơn giản?

1. Không phải vì tác động hiệu suất. Đây sẽ là một giả định rất sai lầm của một nhà phát triển mới bắt đầu tối ưu hóa vi mô cho ứng dụng của mình. Không có tác động hiệu suất trong hầu hết các ngôn ngữ, vì trình biên dịch sẽ nội tuyến biến. Trong những ngôn ngữ mà trình biên dịch không làm điều đó, bạn có thể đạt được một vài micro giây bằng cách đặt nó bằng tay, điều này không đáng. Đừng làm vậy.

2. Nhưng vì nguy cơ phân tách tên bạn đặt cho biến với tên của tham số.

   Thí dụ:

   Giả sử mã gốc là:

   void doSomething(bool preventUndo)
   {
       // Does something very interesting.
       undoHistory.removeLast();
   }
   
   // Later in code:
   var preventUndo = true;
   doSomething(preventUndo);
   

   Sau đó, một nhà phát triển làm việc trên các doSomethingthông báo rằng gần đây, lịch sử hoàn tác đã giới thiệu hai phương pháp mới:

   undoHistory.clearAll() { ... }
   undoHistory.disable() { ... }
   

   Bây giờ, preventUndodường như không rõ ràng lắm. Có nghĩa là chỉ hành động cuối cùng sẽ được ngăn chặn? Hoặc có lẽ điều đó có nghĩa là người dùng sẽ không thể sử dụng tính năng hoàn tác nữa? Hoặc lịch sử hoàn tác sẽ bị xóa? Tên rõ ràng hơn sẽ là:

   doSomething(bool hideLastUndo) { ... }
   doSomething(bool removeAllUndo) { ... }
   doSomething(bool disableUndoFeature) { ... }
   

   Vì vậy, bây giờ bạn có:

   void doSomething(bool hideLastUndo)
   {
       // Does something very interesting.
       undoHistory.removeLast();
   }
   
   // Later in code, very error prone, while the signature of the method is clear:
   var preventUndo = true;
   doSomething(preventUndo);
   

Thế còn enum?

Một số người khác đề nghị sử dụng enums. Trong khi nó giải quyết vấn đề trước mắt, nó tạo ra một vấn đề lớn hơn. Hãy xem:

enum undoPrevention
{
    keepInHistory,
    prevent,
}

void doSomething(undoPrevention preventUndo)
{
    doTheJob();
    if (preventUndo == undoPrevention.prevent)
    {
        this.undoHistory.discardLastEntry();
    }
}

doSomething(undoPrevention.prevent);

Vấn đề với điều đó:

1. Đó là quá nhiều mã. if (preventUndo == undoPrevention.prevent)? Nghiêm túc?! Tôi không muốn viết như vậy ifmỗi lần.

2. Thêm một yếu tố vào enum sẽ rất hấp dẫn sau này, nếu tôi đang sử dụng cùng một enum ở một nơi khác. Điều gì xảy ra nếu tôi sửa đổi nó như thế này:

   enum undoPrevention
   {
       keepInHistory,
       prevent,
       keepButDisable, // Keeps the entry in the history, but makes it disabled.
   }
   

   Chuyện gì xảy ra bây giờ? doSomethingPhương pháp sẽ làm việc như mong đợi? Để ngăn chặn điều này, nó sẽ yêu cầu viết phương pháp này ngay từ đầu:

   void doSomething(undoPrevention preventUndo)
   {
       if (![undoPrevention.keepInHistory, undoPrevention.prevent].contains(preventUndo))
       {
           throw new ArgumentException('preventUndo');
       }
   
       doTheJob();
       if (preventUndo == undoPrevention.prevent)
       {
           this.undoHistory.discardLastEntry();
       }
   }
   

   Các biến thể sử dụng booleans bắt đầu trông rất đẹp!

   void doSomething(bool preventUndo)
   {
       doTheJob();
       if (preventUndo)
       {
           this.undoHistory.discardLastEntry();
       }
   }
   

Không, bạn không nên viết phương thức với cờ boolean.

Để trích dẫn Robert C. Martin nói trong cuốn sách Clean Code của mình (ISBN-13 978-0-13-235088-4), "Chuyển một boolean vào một chức năng là một thực tế thực sự khủng khiếp."

Để diễn giải anh ta, lý do là việc bạn có một công tắc đúng / sai có nghĩa là phương pháp của bạn rất có thể làm hai việc khác nhau (nghĩa là "Làm gì đó với hoàn tác" và "Làm gì đó mà không hoàn tác"), và do đó nên chia thành hai phương thức khác nhau (có thể gọi bên trong cùng một thứ).

DoSomething()
{...

DoSomethingUndoable()
{....

Khi bạn nhìn vào hai lớp để xem chúng được ghép như thế nào, một trong các loại là khớp dữ liệu , trong đó đề cập đến mã trong một phương thức gọi lớp của một lớp khác và chỉ truyền dữ liệu, như tháng bạn muốn báo cáo và một loại khác thể loại là khớp nối điều khiển , gọi các phương thức và truyền vào một cái gì đó điều khiển hành vi của phương thức. Ví dụ tôi sử dụng trong lớp là verbosecờ hoặc reportTypecờ, nhưng preventUndocũng là một ví dụ tuyệt vời. Như bạn vừa trình bày, khớp nối điều khiển làm cho việc đọc mã gọi và hiểu những gì đang xảy ra thật khó khăn. Nó cũng làm cho mã cuộc gọi dễ bị tổn thương trước những thay đổi trong doSomething()đó sử dụng cùng một cờ để kiểm soát cả hoàn tác và lưu trữ hoặc thêm một tham số khác vàodoSomething() để kiểm soát việc lưu trữ, do đó phá mã của bạn, v.v.

Vấn đề là mã được ghép quá chặt chẽ. Vượt qua một bool để kiểm soát hành vi, theo tôi, là một dấu hiệu của một API xấu. Nếu bạn sở hữu API, hãy thay đổi nó. Hai phương pháp, doSomething()và doSomethingWithUndo(), sẽ tốt hơn. nếu bạn không sở hữu nó, hãy tự viết hai phương thức trình bao bọc theo mã bạn sở hữu và yêu cầu một trong số chúng gọi doSomething(true)và cuộc gọi khác doSomething(false).

Nó không phải là vai trò của người gọi để xác định vai trò của các đối số. Tôi luôn dùng phiên bản nội tuyến và kiểm tra chữ ký của hàm được gọi nếu tôi có nghi ngờ.

Biến nên được đặt tên theo vai trò của chúng trong phạm vi hiện tại. Không phải phạm vi mà chúng được gửi.

Những gì tôi sẽ làm trong JavaScript là hàm có một đối tượng làm tham số duy nhất giống như thế này:

function doSomething(settings) {
    var preventUndo = settings.hasOwnProperty('preventUndo') ? settings.preventUndo : false;
    // Deal with preventUndo in the normal way.
}

Sau đó gọi nó bằng:

doSomething({preventUndo: true});

Tôi thích tận dụng các tính năng ngôn ngữ để giúp bản thân rõ ràng hơn. Ví dụ trong C #, bạn có thể chỉ định tham số theo tên:

 CallSomething(name: "So and so", age: 12, description: "A random person.");

Trong JavaScript, tôi thường thích sử dụng một đối tượng tùy chọn làm đối số cho lý do này:

function doSomething(args) { /*...*/ }

doSomething({ name: 'So and so', age: 12, description: 'A random person.' });

Đó chỉ là sở thích của tôi. Tôi cho rằng nó sẽ phụ thuộc rất nhiều vào phương thức được gọi và cách IDE giúp nhà phát triển hiểu chữ ký.

Tôi thấy đây là cách đơn giản và dễ đọc nhất:

enum Undo { ALLOW, PREVENT }

doSomething(Undo u) {
    if (Undo.ALLOW == u) {
        // save stuff to undo later.
    }
    // do your thing
}

doSomething(Undo.ALLOW);

MainMa không thích điều đó. Chúng tôi có thể phải đồng ý không đồng ý hoặc chúng tôi có thể sử dụng giải pháp mà Joshua Bloch đề xuất:

enum Undo {
    ALLOW {
        @Override
        public void createUndoBuffer() {
            // put undo code here
        }
    },
    PREVENT {
        @Override
        public void createUndoBuffer() {
            // do nothing
        }
    };

    public abstract void createUndoBuffer();
}

doSomething(Undo u) {
    u.createUndoBuffer();
    // do your thing
}

Bây giờ nếu bạn đã từng thêm một Undo.LIMITED_UNDO, mã của bạn sẽ không biên dịch trừ khi bạn triển khai phương thức createUndoBuffer (). Và trong doS Something () không có if (Undo.ALLOW == u). Tôi đã thực hiện cả hai cách và phương pháp thứ hai khá nặng nề và hơi khó hiểu khi Undo enum mở rộng sang các trang và trang mã, nhưng nó khiến bạn phải suy nghĩ. Tôi thường gắn bó với phương pháp đơn giản hơn để thay thế một boolean đơn giản bằng enum 2 giá trị cho đến khi tôi có lý do để thay đổi. Khi tôi thêm một giá trị thứ ba, tôi sử dụng IDE của mình để "Tìm kiếm sử dụng" và sau đó sửa mọi thứ.

Tôi nghĩ rằng giải pháp của bạn làm cho mã của bạn dễ đọc hơn một chút nhưng tôi sẽ tránh việc xác định một biến phụ chỉ để làm cho hàm của bạn gọi rõ ràng hơn. Ngoài ra, nếu bạn muốn sử dụng một biến phụ, tôi sẽ đánh dấu nó là hằng số nếu ngôn ngữ lập trình của bạn hỗ trợ nó.

Tôi có thể nghĩ về hai lựa chọn thay thế không liên quan đến một biến phụ:

1. Sử dụng một nhận xét thêm

doSomething(/* preventUndo */ true);

2. Sử dụng enum hai giá trị thay vì boolean

enum Options
{
    PreventUndo,
    ...
}

...

doSomething(PreventUndo);

Bạn có thể sử dụng thay thế 2 nếu ngôn ngữ của bạn hỗ trợ enums.

BIÊN TẬP

Tất nhiên, sử dụng các đối số được đặt tên cũng là một tùy chọn, nếu ngôn ngữ của bạn hỗ trợ chúng.

Về mã hóa thêm cần thiết cho enums, nó thực sự có vẻ không đáng kể đối với tôi. Thay vì

if (preventUndo)
{
    ...
}

bạn có

if (undoOption == PreventUndo)
{
    ...
}

hoặc là

switch (undoOption)
{
  case PreventUndo:
  ...
}

Và ngay cả khi nó gõ nhiều hơn một chút, hãy nhớ rằng mã được viết một lần và đọc nhiều lần, vì vậy nó có thể đáng để gõ thêm một chút bây giờ để tìm mã dễ đọc hơn sáu tháng sau.

Tôi đồng ý với những gì @GlenPeterson nói:

doSomething(Undo.ALLOW); // call using a self evident enum

nhưng cũng insterest sẽ là như sau vì dường như chỉ có hai tính tích cực (đúng hoặc sai)

//Two methods    

doSomething()  // this method does something but doesn't prevent undo

doSomethingPreventUndo() // this method does something and prevents undo

Vì bạn chủ yếu hỏi về javascript, bằng cách sử dụng coffeescript, bạn có thể có một đối số được đặt tên như cú pháp, siêu dễ:

# declare method, ={} declares a default value to prevent null reference errors
doSomething = ({preventUndo} = {}) ->
  if preventUndo
    undo = no
  else
    undo = yes

#call method
doSomething preventUndo: yes
#or 
doSomething(preventUndo: yes)

biên dịch thành

var doSomething;

doSomething = function(_arg) {
  var preventUndo, undo;
  preventUndo = (_arg != null ? _arg : {}).preventUndo;
  if (preventUndo) {
    return undo = false;
  } else {
    return undo = true;
  }
};

doSomething({
  preventUndo: true
});

doSomething({
  preventUndo: true
});

Hãy vui vẻ tại http://js2coffee.org/ để thử các khả năng

Chỉ dành cho một giải pháp ít thông thường hơn và vì OP đã đề cập đến Javascript, một khả năng là sử dụng một mảng kết hợp để ánh xạ các giá trị. Ưu điểm so với một boolean duy nhất là bạn có thể có nhiều đối số như bạn muốn và không phải lo lắng về trình tự của chúng.

var doSomethingOptions = new Array();

doSomethingOptions["PREVENTUNDO"] = true;
doSomethingOptions["TESTMODE"] = false;

doSomething( doSomethingOptions );

// ...

function doSomething( doSomethingOptions ){
    // Check for null here
    if( doSomethingOptions["PREVENTUNDO"] ) // ...
}

Tôi nhận ra đây là một phản xạ của một người nào đó từ một nền tảng được đánh máy mạnh mẽ và có thể không thực tế lắm nhưng hãy xem xét điều này cho độc đáo.

Một khả năng khác là có một đối tượng và cũng có thể có trong Javascript. Tôi không chắc chắn 100% điều này là chính xác. Có một cái nhìn vào các mẫu như Nhà máy để có thêm cảm hứng.

function SomethingDoer( preventUndo ) {
    this.preventUndo = preventUndo;
    this.doSomething = function() {
            if( this.preventUndo ){
                    // ...
            }
    };
}

mySomethingDoer = new SomethingDoer(true).doSomething();

Trọng tâm của câu hỏi của bạn và của các câu trả lời khác là cải thiện khả năng đọc nơi hàm được gọi, đây là trọng tâm tôi đồng ý. Bất kỳ hướng dẫn cụ thể nào, sự kiện "không có đối số boolean", sẽ luôn luôn hoạt động như là phương tiện cho mục đích này và không trở thành và tự kết thúc.

Tôi nghĩ thật hữu ích khi lưu ý rằng vấn đề này chủ yếu được khắc phục khi ngôn ngữ lập trình hỗ trợ các đối số / đối số từ khóa có tên, như trong C # 4 và Python hoặc trong đó các đối số phương thức được xen kẽ trong tên phương thức, như trong Smalltalk hoặc Objective-C.

Ví dụ:

// C# 4
foo.doSomething(preventUndo: true);

# Python
foo.doSomething(preventUndo=True)

// Objective-C
[foo doSomethingWith:bar shouldPreventUndo:YES];

Người ta nên tránh truyền các biến boolean làm đối số cho các hàm. Bởi vì các chức năng nên làm một việc tại một thời điểm. Bằng cách chuyển biến boolean, hàm có hai hành vi. Điều này cũng tạo ra vấn đề dễ đọc cho giai đoạn sau hoặc cho các lập trình viên khác có xu hướng xem mã của bạn. Điều này cũng tạo ra vấn đề trong việc kiểm tra chức năng. Có lẽ trong trường hợp này bạn phải tạo hai trường hợp thử nghiệm. Hãy tưởng tượng nếu bạn có một hàm có câu lệnh chuyển đổi và thay đổi hành vi của nó dựa trên loại chuyển đổi thì bạn phải có rất nhiều trường hợp thử nghiệm khác nhau được xác định cho nó.

Bất cứ khi nào người ta bắt gặp có một đối số boolean cho hàm, họ phải điều chỉnh mã sao cho họ không viết đối số boolean nào cả.

int preventUndo = true;
doSomething(preventUndo);

Một trình biên dịch tốt cho các ngôn ngữ thấp như C ++ sẽ tối ưu hóa mã máy của 2 dòng trên như dưới đây:

doSomething(true); 

vì vậy nó không quan trọng trong hiệu suất nhưng sẽ tăng khả năng đọc.

Ngoài ra, rất hữu ích khi sử dụng một biến trong trường hợp nó sẽ trở thành biến sau đó và cũng có thể chấp nhận các giá trị khác.