Phong cách được chấp nhận để sử dụng từ khóa `this` trong Java là gì?


37

Tôi đến từ các ngôn ngữ như Python hoặc Javascript (và các ngôn ngữ khác ít hướng đối tượng hơn) và tôi đang cố gắng cải thiện kiến ​​thức làm việc về Java, điều mà tôi chỉ biết theo cách hời hợt.

Có được coi là một thực tiễn xấu khi luôn luôn bổ sung thischo các thuộc tính hiện tại không? Tôi cảm thấy tự nhiên hơn khi viết

...
private String foo;

public void printFoo() {
    System.out.println(this.foo);
}
...

hơn

...
private String foo;

public void printFoo() {
    System.out.println(foo);
}
...

vì nó giúp tôi phân biệt các thuộc tính thể hiện với các biến cục bộ.

Tất nhiên, trong một ngôn ngữ như Javascript, nó luôn có ý nghĩa hơn khi luôn sử dụng this, vì người ta có thể có nhiều chức năng lồng nhau hơn, do đó các biến cục bộ đến từ phạm vi lớn hơn. Trong Java, theo như tôi hiểu, không có lồng nhau như thế này là có thể (ngoại trừ các lớp bên trong), vì vậy có lẽ nó không phải là một vấn đề lớn.

Trong mọi trường hợp, tôi muốn sử dụng this. Nó sẽ cảm thấy kỳ lạ và không thành ngữ?


Chúng tôi sử dụng một công cụ để cải thiện điều đó trong công ty của chúng tôi. Mã công cụ chạy lại với chúng tôi mà không có điều này tùy thuộc vào chính sách của công ty. Vì vậy, mọi người đều mã hóa cách họ thích và mã được định dạng đúng cách tại thời điểm cam kết.
deadalnix

2
"vì người ta có thể có nhiều chức năng lồng nhau hơn, do đó các biến cục bộ đến từ phạm vi lớn hơn." Ngoài ra, thực tế là "cái này" thực sự không phải là một trong những nơi mà một biến không đủ tiêu chuẩn có thể đến từ một hàm trong JS.
Random832

2
Tôi tiền tố tất cả các biến thể hiện với dấu gạch dưới để tôi có thể dễ dàng nhận ra sự khác biệt giữa các biến cục bộ và biến thể mà không cần sử dụng this.
WuHoUnited

4
Trong C # StyleCop muốn bạn đặt this.khi đề cập đến các biến thành viên, phương thức, v.v. Tôi thích điều đó, tôi đồng ý với quy tắc này. Tôi nghĩ rằng nó là tốt hơn so với việc đặt tên một cái gì đó với một dấu gạch dưới ở đầu. Tôi sẽ tuân theo quy tắc tương tự nếu tôi viết mã bằng java.
Công việc

Câu trả lời:


40

Trong hầu hết các IDE, bạn chỉ cần di chuột qua biến nếu bạn muốn biết. Ngoài ra, thực sự, nếu bạn đang làm việc trong một phương thức cá thể, bạn thực sự nên biết tất cả các biến liên quan. Nếu bạn có quá nhiều, hoặc tên của họ đụng độ, thì bạn cần phải cấu trúc lại.

Nó thực sự khá dư thừa.


7
Ngoài ra: một IDE lành mạnh sẽ làm cho các trường và các biến / tham số cục bộ trở nên khác biệt trực quan. Ví dụ, trong các trường Eclipse (theo mặc định) có màu xanh lam, trong khi các biến cục bộ có màu đen.
Joachim Sauer

1
@Joachim Điểm hay, Eclipse thậm chí có thể tô màu các tham số và biến cục bộ khác nhau nếu người dùng muốn (tuy nhiên đây không phải là mặc định).
Eric-Karl

3
Mặc dù tôi đồng ý, nhưng khi bắt gặp mã của các nhà phát triển khác (và trong khi không quen thuộc ngay từ cái nhìn đầu tiên), tôi thấy this.hữu ích hơn rất nhiều. Điều này cũng có thể là do tôi không có IDE có mã màu cục bộ / biến đối tượng khác nhau.
Brad Christie

3
+1 cho (paraphotto) "refactor nếu bạn cần sử dụng điều này để suy luận rằng đó là một thành viên". Chỉ là những gì tôi muốn chỉ ra.
Yam Marcovic

Tôi không thấy nó làm cho nó khó đọc hơn và đổi lại, mã vẫn có thể đọc được trong các trình soạn thảo có cú pháp tô sáng ít phức tạp hơn mà không phân biệt giữa các trường và địa phương. Tôi luôn có ý kiến ​​rằng bạn nên cố gắng để mã của mình dễ đọc hơn trong trình soạn thảo văn bản cơ bản nhất và nếu không, cần phải có lý do chính đáng cho mã này.
Kevin

26

Tôi thích sử dụng this. Nó giúp đọc mã dễ dàng hơn trong các trình soạn thảo khác nhau tô màu các biến cục bộ và thể hiện theo cùng một cách. Nó cũng làm cho việc đọc mã trên một trang in dễ dàng hơn trong khi xem xét mã. Đây cũng là một lời nhắc nhở khá mạnh mẽ về phạm vi của biến đối với các nhà phát triển khác.

Tuy nhiên, có những lập luận chống lại điều này. Trong các IDE hiện đại, bạn có thể tìm ra phạm vi của một biến bằng cách di chuột qua nó hoặc xem nó trong một cấu trúc giống như cây. Bạn cũng có thể thay đổi màu sắc và / hoặc mặt phông chữ của các biến tùy thuộc vào phạm vi của chúng (thậm chí theo cách mà khi được in, rõ ràng phạm vi của biến là gì).

Tôi tin rằng câu cuối cùng của ChrisF đã chết: hãy kiên định trong cách sử dụng của bạn.


7
"Đó cũng là một lời nhắc nhở khá mạnh mẽ về phạm vi của biến đối với các nhà phát triển khác." - lý do tôi có xu hướng sử dụng và muốn xem this.trong mã. Mất nửa giây để viết và có thể tiết kiệm được nhiều phút khi phải tìm hiểu xem anh chàng trước khi bạn thực sự có ý định sử dụng thuộc tính trường hợp pascal thay vì trường hợp lạc đà ở đó khi anh ta thực hiện cú thay đổi phút cuối 20 lần trước.
Scrwtp

18

Một nơi tôi thường xuyên sử dụng 'cái này' là setters và hoặc constructor:

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

Ngoài ra, tôi không cảm thấy cần thiết phải thêm nó. Khi đọc phần thân của một phương thức, các tham số và địa phương nằm ngay tại đó - và khá dễ dàng để theo dõi (ngay cả khi không có sự trợ giúp của IDE). Ngoài ra các địa phương và các trường có xu hướng có tính chất khác nhau (trạng thái đối tượng so với lưu trữ hoặc tham số nhất thời).

Nếu có bất kỳ sự nhầm lẫn nào về biến là gì và trường nào, có lẽ có nghĩa là một phương thức có quá nhiều biến / tham số, quá dài và quá phức tạp và nên được đơn giản hóa.

Nếu bạn chọn sử dụng 'this' để gắn thẻ các trường, tôi sẽ khuyên bạn nên đảm bảo rằng quy ước luôn được tuân thủ nghiêm ngặt - sẽ thực sự dễ dàng để bắt đầu giả định không 'cái này' có nghĩa là nó là một thứ cục bộ và phá vỡ dựa trên giả định.

chỉnh sửa: Tôi cũng kết thúc bằng cách sử dụng cái này bằng, sao chép hoặc bất cứ thứ gì có tham số 'that' có cùng loại đối tượng:

public boolean isSame(MyClass that) {
    return this.uuid().equals(that.uuid());
}

8

Thật đáng tranh luận.

Lấy C # là một sự tương tự vì nó có cú pháp và cấu trúc rất giống với Java, chúng tôi thấy rằng C # StyleCop có một quy tắc mặc định khẳng định bạn thêm this, nhưng ReSharper có một quy tắc mặc định nói rằng đó thislà dự phòng (và đó là) loại bỏ.

Vì vậy, nếu bạn đang sử dụng một công cụ, bạn sẽ thêm chúng nhưng nếu bạn sử dụng một công cụ khác, bạn sẽ xóa chúng. Nếu bạn đang sử dụng cả hai công cụ thì bạn sẽ phải chọn và vô hiệu hóa một trong các quy tắc.

Tuy nhiên, những gì các quy tắc có nghĩa là bạn nhất quán trong cách sử dụng của bạn - đó có lẽ là điều quan trọng nhất.


8

Có được coi là một thực tiễn xấu khi luôn luôn bổ sung điều này cho các thuộc tính hiện tại không?

Có - bởi một số, không - bởi những người khác.

Tôi thích và sử dụng thistừ khóa trong các dự án của tôi trong Java và C #. Mọi người có thể lập luận rằng IDE sẽ luôn làm nổi bật các tham số và các trường bằng màu khác nhau, tuy nhiên chúng tôi không luôn làm việc trong IDE - chúng tôi phải thực hiện nhiều thao tác sáp nhập / khác biệt / một số thay đổi nhanh trong notepad / kiểm tra một số đoạn mã trong e-mail . Đó là cách dễ dàng hơn cho tôi để phát hiện từ cái nhìn đầu tiên mà nhà nước sơ thẩm được thay đổi - ví dụ, để xem xét một số vấn đề đồng thời có thể.


7

Tôi nghĩ rằng nếu bạn cần sử dụng cái này, bạn có một phương thức quá dài hoặc một lớp đang cố gắng làm quá nhiều hoặc cả hai.

Các phương thức không bao giờ dài quá một vài dòng mã, sử dụng một hoặc hai biến cục bộ, xác định cái gì trở nên dễ dàng; thậm chí chỉ với bối cảnh 3 dòng của hầu hết các công cụ diff. Nếu các phương thức của bạn quá dài và các lớp của bạn có quá nhiều khả năng đáp ứng (thường có nghĩa là quá nhiều trường), giải pháp là phân tách chúng thay thế.

Tôi nghĩ rằng "cái này" chỉ là mã khóa. Đặc biệt với các IDE hiện đại sẽ tô màu các tham số cục bộ / biến cục bộ / trường khác nhau.


5

Tôi nghĩ rằng bạn đã trả lời câu hỏi của riêng bạn với điều này:

Tôi cảm thấy tự nhiên hơn khi viết

... này.foo ...

hơn

... foo ...

vì nó giúp tôi phân biệt các thuộc tính thể hiện với các biến cục bộ.

Nếu bạn cảm thấy thoải mái hơn this.khi sử dụng trong khi cải thiện kiến ​​thức làm việc của mình với Java, thì bằng mọi cách, hãy sử dụng thứ đó ( tôi nghĩ, theo một cách nào đó, bản thân Python quen thuộc mà bạn có liên quan ).

Vấn đề là, mặc dù mọi người sẽ đưa ra những lý lẽ chắc chắn / thích hợp về việc sử dụng hay không sử dụng this., nhưng nó vẫn giống như một cuộc tranh luận, ví dụ được đưa ra:

  • nó làm cho mục đích của các biến rõ ràng so với việc bạn nên viết lại mã nếu nó không rõ ràng từng biến là gì;
  • this.là dư thừa nếu bạn dành cả ngày trong IDE so với tôi thực hiện đánh giá mã và tạo khác biệt trên các phiên bản khác nhau bằng cách sử dụng bộ so sánh không có tô sáng cú pháp;
  • không gõ giúp this.tôi đạt được một phần nghìn giây năng suất quan trọng so với việc tôi được trả tiền bằng cách nhấn phím và thêm vào this.giống như tăng lương: D;
  • Vân vân

Nhưng điểm mấu chốt là, vào cuối ngày, nó vẫn tiếp tục theo sở thích cá nhân và môi trường làm việc .


5

Thông thường thêm điều này là không cần thiết. Tôi không nghĩ rằng đó là một thực tiễn tồi tệ, nhưng việc sử dụng quá mức này có thể được coi là bất thường trong hầu hết các cơ sở mã Java mà tôi đã thấy.

Tuy nhiên tôi thấy nó có giá trị trong một vài tình huống cụ thể:

Ghi đè các tham số cục bộ - đôi khi cần phải xác định rằng bạn muốn sử dụng một biến thể hiện hơn là một tham số / biến cục bộ cùng tên. Điều này khá phổ biến trong các hàm tạo, trong đó bạn muốn tên tham số khớp với tên bên trong của biến thể hiện, nó được sử dụng để khởi tạo, vd

class MyObject {
  int value;

  public MyObject(int value) {
    this.value=value;
  }
}

Khi xử lý các thể hiện khác của cùng một lớp - tôi tin rằng nó làm cho mã rõ ràng hơn và dễ hiểu hơn để rõ ràng về trường hợp nào của lớp mà bạn đang đề cập đến, vd

class MyObject {
  int value;
  ....

  public MyObject add(MyObject other) {
    return new MyObject( this.value + other.value )
  }
}
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.