Đây http://source.android.com/source/code-style.html#follow-field-naming-conventions nó được tuyên bố rằng:Hướng dẫn đặt tên cho trường riêng tư của Android là ok?
Dòng Tên
- ngoài công lập, tên trường không tĩnh bắt đầu với m.
- Tên trường tĩnh bắt đầu bằng s.
- Các trường khác bắt đầu bằng chữ thường.
- Trường cuối cùng công khai (hằng số) là ALL_CAPS_WITH_UNDERSCORES.
Nó cũng khẳng định rằng:
Các quy tắc dưới đây không phải là hướng dẫn hoặc khuyến nghị, nhưng quy tắc nghiêm ngặt. Bạn không thể bỏ qua các quy tắc mà chúng tôi liệt kê bên dưới ngoại trừ được chấp thuận trên cơ sở cần sử dụng.
Tôi không thích quy ước "m" trước các trường riêng tư hoặc gói trong lớp học. Tôi thực sự tìm thấy điều này uninspired ... Tôi có nghĩa là, nếu chúng ta cố gắng áp dụng thiết kế tốt, các khớp nối thấp của các lớp học ngụ ý có vài lĩnh vực công cộng. thực tế, trong các chương trình của tôi, tôi thường không có các lĩnh vực công cộng, ngay cả khi tôi cần một số tôi sử dụng getters và setters ...
Vì vậy, tại sao tôi buộc phải có hầu hết tất cả các trường trong chương trình bằng "m" ở phía trước họ? sẽ không dễ dàng hơn để có một vài lĩnh vực công cộng, nếu có, với một số "g" ở phía trước hoặc một cái gì đó? hoặc chỉ sử dụng setters và getters như đậu đề nghị? điều này thực sự làm cho mã của tôi khó đọc hơn.
Ngoài ra, làm theo các hướng dẫn này, biến nhiệt độ cục bộ được sử dụng trong phương pháp không bị giới hạn để chúng có thể dễ dàng bị nhầm lẫn với các trường chung trên toàn cầu (cũng không bị hạn chế). Điều này tôi cũng thấy là sai, vì nó là một nguồn có thể xảy ra sai lầm ... Tôi hiểu có cách phân biệt với các trường, nhưng các trường thành viên riêng tư/được bảo vệ được sử dụng nhiều nhất trong một ứng dụng, chúng không nên ít "có thể đọc được".
Bạn nghĩ sao? Tôi có nên làm theo các hướng dẫn không?
Một trong những lý do khiến các tiền tố như thế này thường được ủy quyền là ngăn chặn ẩn các trường thành viên. Ví dụ, bạn thường có một tham số cho một hàm tạo hoặc phương thức setter có cùng tên với trường thành viên nếu bạn không có bất kỳ tiền tố nào. Trong trường hợp này, bạn phải truy cập vào trường thành viên bằng cách sử dụng "this". trước mặt nó bất cứ khi nào nó bị ẩn. Đôi khi các lập trình viên quên "điều này", dẫn đến lỗi. Tiền tố trên các trường công cộng không hữu ích vì không cần thiết lập một trường công lập trên một trường công cộng. –
Tôi thực sự thích tiền tố m_ trên các trường riêng vì nó làm cho các phương thức lớp của bạn dễ đọc hơn. Những quy ước được sử dụng bởi vì mã được đọc nhiều hơn viết của nó ... Tôi nghĩ thats trong Mã hoàn thành một nơi nào đó? ... –
tôi đồng ý với bạn .. tôi không thích quy ước "m" và tôi hạnh phúc không sử dụng nó – hendrix