Khi nào bạn sử dụng từ khóa này. [đóng cửa]

Tôi tò mò về cách người khác sử dụng từ khóa này . Tôi có xu hướng sử dụng nó trong các hàm tạo, nhưng tôi cũng có thể sử dụng nó trong toàn bộ lớp trong các phương thức khác. Vài ví dụ:

Trong một hàm tạo:

public Light(Vector v)
{
    this.dir = new Vector(v);
}

Ở nơi khác

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}

Có một số cách sử dụng từ khóa này trong C #.

1. Để đủ điều kiện thành viên ẩn bằng tên tương tự
2. Để có một đối tượng truyền chính nó như là một tham số cho các phương thức khác
3. Để có một đối tượng tự trả về từ một phương thức
4. Để khai báo chỉ mục
5. Để khai báo các phương thức mở rộng
6. Để truyền tham số giữa các hàm tạo
7. Để nội bộ gán lại giá trị loại giá trị (struct) .
8. Để gọi một phương thức mở rộng trên thể hiện hiện tại
9. Để tự chuyển sang loại khác
10. Để xây dựng chuỗi được định nghĩa trong cùng một lớp

Bạn có thể tránh việc sử dụng đầu tiên bằng cách không có các biến thành viên và biến cục bộ có cùng tên trong phạm vi, ví dụ bằng cách tuân theo các quy ước đặt tên chung và sử dụng các thuộc tính (trường hợp Pascal) thay vì các trường (trường hợp lạc đà) để tránh va chạm với các biến cục bộ (cũng là lạc đà trường hợp). Trong C # 3.0, các trường có thể được chuyển đổi thành các thuộc tính một cách dễ dàng bằng cách sử dụng các thuộc tính được triển khai tự động .

Tôi không có ý này nghe có vẻ ngớ ngẩn, nhưng nó không thành vấn đề.

Nghiêm túc.

Nhìn vào những thứ quan trọng: dự án của bạn, mã của bạn, công việc của bạn, cuộc sống cá nhân của bạn. Không ai trong số họ sẽ nghỉ ngơi thành công cho dù bạn có sử dụng từ khóa "này" để đủ điều kiện truy cập vào các trường hay không. Từ khóa này sẽ không giúp bạn giao hàng đúng hẹn. Nó sẽ không làm giảm lỗi, nó sẽ không có bất kỳ ảnh hưởng đáng kể nào đến chất lượng mã hoặc khả năng bảo trì. Nó sẽ không giúp bạn tăng lương, hoặc cho phép bạn dành ít thời gian hơn tại văn phòng.

Đó thực sự chỉ là một vấn đề phong cách. Nếu bạn thích "cái này", thì hãy sử dụng nó. Nếu bạn không, thì không. Nếu bạn cần nó để có được ngữ nghĩa chính xác thì hãy sử dụng nó. Sự thật là, mỗi lập trình viên đều có phong cách lập trình độc đáo của riêng mình. Phong cách đó phản ánh quan niệm của các lập trình viên cụ thể về "mã đẹp nhất về mặt thẩm mỹ" sẽ trông như thế nào. Theo định nghĩa, bất kỳ lập trình viên nào khác đọc mã của bạn sẽ có một kiểu lập trình khác. Điều đó có nghĩa là sẽ luôn có điều gì đó bạn làm mà anh chàng kia không thích, hoặc sẽ làm khác đi. Tại một số thời điểm, một số người sẽ đọc mã của bạn và càu nhàu về một cái gì đó.

Tôi sẽ không băn khoăn về nó. Tôi chỉ chắc chắn rằng mã là thẩm mỹ nhất có thể theo thị hiếu của riêng bạn. Nếu bạn hỏi 10 lập trình viên cách định dạng mã, bạn sẽ nhận được khoảng 15 ý kiến ​​khác nhau. Một điều tốt hơn để tập trung vào là làm thế nào mã được bao thanh toán. Là những thứ trừu tượng phải không? Tôi đã chọn tên có ý nghĩa cho mọi thứ? Có rất nhiều mã trùng lặp? Có cách nào tôi có thể đơn giản hóa công cụ? Làm cho những điều đó đúng, tôi nghĩ, sẽ có tác động tích cực nhất đến dự án, mã của bạn, công việc và cuộc sống của bạn. Thật trùng hợp, có lẽ nó cũng sẽ khiến anh chàng kia càu nhàu ít nhất. Nếu mã của bạn hoạt động, dễ đọc và được cung cấp đầy đủ, anh chàng kia sẽ không xem xét kỹ lưỡng cách bạn khởi tạo các trường. Anh ấy sẽ sử dụng mã của bạn, ngạc nhiên trước sự tuyệt vời của nó,

Tôi chỉ sử dụng nó khi thực sự cần thiết, tức là khi một biến khác đang phủ bóng lên một biến khác. Chẳng hạn như ở đây:

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

Hoặc như Ryan Fox chỉ ra, khi bạn cần vượt qua điều này như một tham số. (Các biến cục bộ được ưu tiên hơn các biến thành viên)

Cá nhân, tôi cố gắng luôn luôn sử dụng điều này khi đề cập đến các biến thành viên. Nó giúp làm rõ mã và làm cho nó dễ đọc hơn. Ngay cả khi không có sự mơ hồ, lần đầu tiên ai đó đọc mã của tôi không biết điều đó, nhưng nếu họ thấy điều này được sử dụng một cách nhất quán, họ sẽ biết liệu họ có đang xem biến thành viên hay không.

Tôi sử dụng nó mỗi khi tôi đề cập đến một biến thể hiện, ngay cả khi tôi không cần. Tôi nghĩ rằng nó làm cho mã rõ ràng hơn.

Tôi không thể tin tất cả những người nói rằng sử dụng nó luôn là một "cách tốt nhất" và như vậy.

Sử dụng "cái này" khi có sự mơ hồ, như trong ví dụ của Corey hoặc khi bạn cần truyền đối tượng làm tham số, như trong ví dụ của Ryan . Không có lý do để sử dụng nó bởi vì có thể giải quyết một biến dựa trên chuỗi phạm vi nên đủ rõ ràng rằng các biến đủ điều kiện với nó là không cần thiết.

EDIT: Tài liệu C # về "this" cho biết thêm một lần sử dụng, ngoài hai từ tôi đã đề cập, cho từ khóa "this" - để khai báo các chỉ mục

EDIT: @Juan: Huh, tôi không thấy bất kỳ sự mâu thuẫn nào trong các tuyên bố của mình - có 3 trường hợp khi tôi sẽ sử dụng từ khóa "này" (như được ghi trong tài liệu C #) và đó là những lúc bạn thực sự cần nó. Dán "cái này" trước các biến trong hàm tạo khi không có bóng đổ xảy ra chỉ đơn giản là lãng phí tổ hợp phím và lãng phí thời gian của tôi khi đọc nó, nó không mang lại lợi ích gì.

Tôi sử dụng nó bất cứ khi nào StyleCop nói với tôi. StyleCop phải được tuân theo. Ồ vâng.

Bất cứ lúc nào bạn cần một tham chiếu đến đối tượng hiện tại.

Một kịch bản đặc biệt tiện dụng là khi đối tượng của bạn đang gọi một hàm và muốn truyền chính nó vào nó.

Thí dụ:

void onChange()
{
    screen.draw(this);
}

Tôi cũng có xu hướng sử dụng nó ở mọi nơi, chỉ để đảm bảo rằng rõ ràng đó là thành viên cá thể mà chúng ta đang làm việc.

Tôi sử dụng nó bất cứ nơi nào có thể có sự mơ hồ (rõ ràng). Không chỉ là sự mơ hồ của trình biên dịch (nó sẽ được yêu cầu trong trường hợp đó), mà còn là sự mơ hồ đối với ai đó đang xem mã.

Một cách sử dụng hơi hiếm khác cho từ khóa này là khi bạn cần gọi một triển khai giao diện rõ ràng từ bên trong lớp triển khai. Đây là một ví dụ giả định:

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}

Đây là khi tôi sử dụng nó:

• Truy cập các Phương thức riêng tư trong lớp (để phân biệt)
• Truyền đối tượng hiện tại sang phương thức khác (hoặc dưới dạng đối tượng người gửi, trong trường hợp có sự kiện)
• Khi tạo phương thức mở rộng: D

Tôi không sử dụng điều này cho các trường Riêng tư vì tôi đặt tiền tố tên biến trường riêng với dấu gạch dưới (_).

[C ++]

Tôi đồng ý với lữ đoàn "sử dụng nó khi bạn phải". Mã trang trí không cần thiết với điều này không phải là một ý tưởng tuyệt vời bởi vì trình biên dịch sẽ không cảnh báo bạn khi bạn quên làm điều đó. Điều này giới thiệu sự nhầm lẫn tiềm ẩn cho những người mong đợi điều này sẽ luôn ở đó, tức là họ sẽ phải suy nghĩ về nó.

Vì vậy, khi nào bạn sẽ sử dụng nó? Tôi vừa xem qua một số mã ngẫu nhiên và tìm thấy những ví dụ này (Tôi sẽ không phán xét liệu đây có phải là những điều tốt để làm hay không):

• Truyền "chính mình" cho một chức năng.
• Gán "chính mình" cho một con trỏ hoặc một cái gì đó tương tự.
• Đúc, tức là lên / xuống đúc (an toàn hoặc bằng cách khác), bỏ đi sự cố định, v.v.
• Trình biên dịch thực thi định hướng.

Bạn nên luôn luôn sử dụng nó, tôi sử dụng nó để phân biệt các trường và tham số riêng tư (vì quy ước đặt tên của chúng tôi nói rằng chúng tôi không sử dụng tiền tố cho tên thành viên và tên tham số (và chúng dựa trên thông tin tìm thấy trên internet, vì vậy tôi cho rằng thực hành tốt nhất))

Tôi sử dụng nó khi, trong một hàm chấp nhận tham chiếu đến một đối tượng cùng loại, tôi muốn làm cho nó hoàn toàn rõ ràng về đối tượng mà tôi đang đề cập đến, ở đâu.

Ví dụ

class AABB
{
  // ... members
  bool intersects( AABB other )
  {
    return other.left() < this->right() &&
           this->left() < other.right() &&

           // +y increases going down
           other.top() < this->bottom() &&
           this->top() < other.bottom() ;
  }
} ;

(so với)

class AABB
{
  bool intersects( AABB other )
  {
    return other.left() < right() &&
           left() < other.right() &&

           // +y increases going down
           other.top() < bottom() &&
           top() < other.bottom() ;
  }
} ;

Nhìn thoáng qua mà AABB không right()đề cập đến? Việc thisthêm một chút của một làm rõ.

Trong câu trả lời số 5 của Jakub Šturc về việc truyền dữ liệu giữa các bộ điều phối có thể có thể sử dụng một lời giải thích nhỏ. Điều này là trong quá tải các nhà xây dựng và là một trường hợp trong đó việc sử dụng thislà bắt buộc. Trong ví dụ sau, chúng ta có thể gọi hàm tạo được tham số hóa từ hàm tạo không tham số với tham số mặc định.

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

Đôi khi tôi thấy đây là một tính năng đặc biệt hữu ích.

Tôi có thói quen sử dụng nó một cách tự do trong Visual C ++ vì làm như vậy sẽ kích hoạt những cái IntelliSense mà tôi nhấn phím '>' và tôi lười biếng. (và dễ bị lỗi chính tả)

Nhưng tôi vẫn tiếp tục sử dụng nó, vì tôi thấy thật hữu ích khi thấy rằng tôi đang gọi một chức năng thành viên chứ không phải là một chức năng toàn cầu.

Tôi có xu hướng gạch dưới các trường với _ vì vậy đừng bao giờ thực sự cần sử dụng cái này. Ngoài ra R # có xu hướng tái cấu trúc chúng đi ...

Tôi khá nhiều chỉ sử dụng điều này khi tham chiếu một thuộc tính loại từ bên trong cùng loại. Như một người dùng khác đã đề cập, tôi cũng nhấn mạnh các trường địa phương để chúng được chú ý mà không cần điều này .

Tôi chỉ sử dụng nó khi được yêu cầu, ngoại trừ các hoạt động đối xứng do đa hình đối số duy nhất phải được đưa vào các phương thức của một bên:

boolean sameValue (SomeNum other) {
   return this.importantValue == other.importantValue;
} 

[C ++]

cái này được sử dụng trong toán tử gán trong đó hầu hết thời gian bạn phải kiểm tra và ngăn chặn sự lạ (vô ý, nguy hiểm hoặc chỉ lãng phí thời gian cho chương trình) những thứ như:

A a;
a = a;

Toán tử gán của bạn sẽ được viết:

A& A::operator=(const A& a) {
    if (this == &a) return *this;

    // we know both sides of the = operator are different, do something...

    return *this;
}

this trên trình biên dịch C ++

Trình biên dịch C ++ sẽ âm thầm tìm kiếm một biểu tượng nếu nó không tìm thấy nó ngay lập tức. Đôi khi, hầu hết thời gian, nó là tốt:

• sử dụng phương thức của lớp mẹ nếu bạn không quá tải nó trong lớp con.
• phát huy giá trị của một loại thành loại khác

Nhưng đôi khi, bạn không muốn trình biên dịch đoán. Bạn muốn trình biên dịch chọn biểu tượng đúng chứ không phải biểu tượng khác.

Đối với tôi , những lần đó là khi, trong một phương thức, tôi muốn truy cập vào một phương thức thành viên hoặc biến thành viên. Tôi chỉ không muốn một số biểu tượng ngẫu nhiên nhặt được chỉ vì tôi đã viết printfthay vì print. this->printfsẽ không được biên dịch.

Vấn đề là, với các thư viện kế thừa C (§), mã kế thừa được viết từ nhiều năm trước (§ §) hoặc bất cứ điều gì có thể xảy ra trong ngôn ngữ mà sao chép / dán là một tính năng lỗi thời nhưng vẫn hoạt động, đôi khi, nói với trình biên dịch không phát trí thông minh là một ý tưởng tuyệt vời.

Đây là những lý do tôi sử dụng this.

(§) nó vẫn là một loại bí ẩn đối với tôi, nhưng bây giờ tôi tự hỏi liệu thực tế bạn có bao gồm tiêu đề <windows.h> trong nguồn của bạn không, là lý do tất cả các biểu tượng thư viện C kế thừa sẽ gây ô nhiễm không gian tên toàn cầu của bạn

(§ §) nhận ra rằng "bạn cần bao gồm một tiêu đề, nhưng bao gồm tiêu đề này sẽ phá vỡ mã của bạn bởi vì nó sử dụng một số macro ngu ngốc với một tên chung" là một trong những khoảnh khắc roulette Nga trong cuộc sống của một lập trình viên

'điều này.' giúp tìm các thành viên trong lớp 'này' với rất nhiều thành viên (thường là do chuỗi thừa kế sâu sắc).

Đánh CTRL + Space không giúp ích gì cho việc này, bởi vì nó cũng bao gồm các loại; trong đó như 'cái này.' bao gồm các thành viên CHỈ.

Tôi thường xóa nó một khi tôi có những gì tôi đã có sau: nhưng đây chỉ là phong cách của tôi.

Về phong cách, nếu bạn là một người đơn độc - bạn quyết định; nếu bạn làm việc cho một công ty tuân thủ chính sách của công ty (nhìn vào những thứ trong kiểm soát nguồn và xem những gì người khác đang làm). Về mặt sử dụng nó để đủ điều kiện thành viên, không có đúng hay sai. Điều sai duy nhất là sự không nhất quán - đó là quy tắc vàng của phong cách. Để lại nit-pick người khác. Dành thời gian của bạn để suy nghĩ về các vấn đề mã hóa thực sự - và rõ ràng là mã hóa - thay vào đó.

Tôi sử dụng nó mỗi khi tôi có thể. Tôi tin rằng nó làm cho mã dễ đọc hơn và mã dễ đọc hơn tương đương với ít lỗi hơn và dễ bảo trì hơn.

Khi bạn có nhiều nhà phát triển làm việc trên cùng một cơ sở mã, bạn cần một số nguyên tắc / quy tắc mã. Nơi tôi làm việc, chúng tôi đã quyết định sử dụng 'cái này' trên các trường, thuộc tính và sự kiện.

Đối với tôi nó có ý nghĩa tốt để làm điều đó như thế này, nó làm cho mã dễ đọc hơn khi bạn phân biệt giữa các biến lớp và biến phương thức.

Nó phụ thuộc vào tiêu chuẩn mã hóa mà tôi đang làm việc. Nếu chúng ta đang sử dụng _ để biểu thị một biến thể hiện thì "cái này" sẽ trở nên dư thừa. Nếu chúng ta không sử dụng _ thì tôi có xu hướng sử dụng điều này để biểu thị biến thể hiện.

Tôi sử dụng nó để gọi Intellisense giống như JohnMcG , nhưng tôi sẽ quay lại và xóa "cái này ->" khi tôi hoàn thành. Tôi tuân theo quy ước của Microsoft về tiền tố các biến thành viên với "m_", vì vậy việc để nó làm tài liệu sẽ chỉ là dư thừa.

1 - Thành ngữ setter Java phổ biến:

 public void setFoo(int foo) {
     this.foo = foo;
 }

2 - Khi gọi một hàm với đối tượng này là tham số

notifier.addListener(this);

Có một cách sử dụng chưa được đề cập trong C ++ và đó là không đề cập đến đối tượng riêng hoặc định hướng một thành viên từ một biến nhận được.

Bạn có thể sử dụng thisđể chuyển đổi một tên không phụ thuộc thành tên phụ thuộc đối số bên trong các lớp mẫu kế thừa từ các mẫu khác.

template <typename T>
struct base {
   void f() {}
};

template <typename T>
struct derived : public base<T>
{
   void test() {
      //f(); // [1] error
      base<T>::f(); // quite verbose if there is more than one argument, but valid
      this->f(); // f is now an argument dependent symbol
   }
}

Mẫu được biên dịch với một cơ chế hai vượt qua. Trong lần truyền đầu tiên, chỉ các tên phụ thuộc không đối số được giải quyết và kiểm tra, trong khi các tên phụ thuộc chỉ được kiểm tra để kết hợp, mà không thực sự thay thế các đối số mẫu.

Ở bước đó, không thực sự thay thế loại, trình biên dịch gần như không có thông tin về những gì base<T>có thể (lưu ý rằng việc chuyên môn hóa mẫu cơ sở có thể biến nó thành các loại hoàn toàn khác nhau, thậm chí các loại không xác định), vì vậy nó chỉ giả định rằng đó là một loại . Ở giai đoạn này, cuộc gọi không phụ thuộc fcó vẻ tự nhiên đối với lập trình viên là một biểu tượng mà trình biên dịch phải tìm thấy như một thành viên của derivedhoặc trong các không gian tên kèm theo - trong đó không xảy ra trong ví dụ-- và nó sẽ phàn nàn.

Giải pháp là biến tên không phụ thuộc fthành tên phụ thuộc. Điều này có thể được thực hiện theo một vài cách, bằng cách nêu rõ loại hình được triển khai ( base<T>::f- việc base<T>tạo biểu tượng phụ thuộc vào Tvà trình biên dịch sẽ chỉ cho rằng nó sẽ tồn tại và hoãn kiểm tra thực tế cho lần vượt qua thứ hai, sau thay thế đối số.

Cách thứ hai, sắp xếp nhiều hơn nếu bạn kế thừa từ các mẫu có nhiều hơn một đối số hoặc tên dài, chỉ là thêm một this->trước biểu tượng. Vì lớp mẫu mà bạn đang triển khai không phụ thuộc vào một đối số (nó kế thừa từ base<T>) this->phụ thuộc vào đối số và chúng tôi nhận được kết quả tương tự: this->fđược kiểm tra trong vòng thứ hai, sau khi thay thế tham số mẫu.

Bạn không nên sử dụng "cái này" trừ khi bạn thực sự phải làm.

Có một hình phạt liên quan đến tính dài dòng không cần thiết. Bạn nên cố gắng cho mã chính xác miễn là nó cần, và không còn nữa.