Tôi có vô đạo đức không khi sử dụng một tên biến chỉ khác với loại của nó theo từng trường hợp?

Ví dụ: lấy đoạn mã này:

var person = new Person();

hoặc cho bạn Pythonistas:

person = Person()

Tôi đã liên tục nói điều này tồi tệ như thế nào, nhưng vẫn chưa thấy một ví dụ nào về sự vô đạo đức của hai dòng mã này. Đối với tôi, con người là một Con người và cố gắng đặt cho nó một cái tên khác là một sự lãng phí thời gian. Tôi cho rằng trong những ngày trước khi tô sáng cú pháp, điều này sẽ là một vấn đề lớn. Nhưng ngày nay, khá dễ dàng để phân biệt một tên kiểu ngoài một tên biến. Heck, thậm chí còn dễ dàng nhận thấy sự khác biệt ở đây trên SO.

Hay có điều gì đó tôi đang thiếu? Nếu vậy, sẽ rất hữu ích nếu bạn có thể cung cấp một ví dụ về mã gây ra sự cố.

Lý do của những người nói với bạn điều này là xấu là gì? Tôi làm điều này tất cả các thời gian. Đây là cách đơn giản nhất để đặt tên cho một biến duy nhất của một kiểu. Nếu bạn cần hai Personđối tượng thì bạn có thể đặt tiền tố personbằng các tính từ có nghĩa như

fastPerson
slowPerson

nếu không thì chỉ

person

là ổn với tôi.

Tôi sử dụng mô hình này rất nhiều trong các chữ ký phương pháp. Nếu tôi không thể cung cấp tên mô tả thay thế thì IMHO, không có gì sai với điều này.

Sẽ là sai nếu bạn có hai kiểu Người và Người thì điều đó rất sai lầm.

Tôi sử dụng nó mọi lúc cho các tham chiếu đối tượng tạm thời. Tôi sẽ tránh nó giống như bệnh dịch hạch cho các kiểu dữ liệu nguyên thủy.

Person person = new Person(); // okay

int Int = 42; // pure evil

Nếu ai đó nói điều đó là xấu xa, hãy hỏi họ xem điều này có tốt hơn không:

var abc = new Person();

Nếu Người là một Người chung trong ngữ cảnh, thì "người" là một cái tên thực sự hay. Tất nhiên nếu Người đó có một vai trò cụ thể trong mã thì tốt hơn nên đặt tên cô ấy bằng cách sử dụng vai trò đó.

Tôi cho rằng mình sẽ bị hạ phiếu vì nói như vậy, nhưng ...

Chỉ mới trải qua một thế kỷ chứng kiến ​​những vụ giết người kinh hoàng và lòng tham, những lập trình viên chúng tôi thực sự may mắn nếu điều trái đạo đức nhất mà chúng tôi có thể làm là đặt tên cho một biến.

Tôi không nghĩ nó nhất thiết phải "xấu", nhưng rõ ràng nếu bạn có thể đủ điều kiện để cung cấp cho nó nhiều ngữ cảnh hơn, chẳng hạn như kiểu người như thế nào (bạn chỉ giao dịch với một trong số nhiều người có thể có), thì người khác sẽ chọn nó lên có thể hiểu rõ hơn.

Jason - Tôi không chắc ai đã nói với bạn rằng điều này là xấu. Một số tác giả sử dụng điều này như một cách tiêu chuẩn để thể hiện một Phiên bản (chữ thường) của một Lớp (viết hoa).

Tôi sử dụng điều này khá thường xuyên vì tôi thấy rằng biến có xu hướng thấp hơn thực sự giao tiếp với tôi không chỉ rằng đây là một thể hiện mà còn là tên của lớp.

Trừ khi ai đó có lập luận chắc chắn ngược lại, tôi chắc chắn sẽ tiếp tục làm điều này.

Lý do nó bị coi là xấu là nếu bạn cần phải có 2 Person trong tương lai, thì bạn có thể kết thúc với mã giống như vậy.

Person person = new Person ();

Person person2 = new Person ();

Điều đó sau đó sẽ giáp với "Bad". Tuy nhiên, trong trường hợp đó, bạn nên cấu trúc lại nhân vật gốc của mình để phân biệt giữa hai loại.

Đối với ví dụ của bạn, tên biến "person" là một tên mô tả hoàn hảo cho đối tượng "Person". Do đó không có gì sai với nó.

Tôi nói tên nó là gì: nếu biến đại diện cho một người có 2 con chó, hãy gọi nó personWith2Dogs. Nếu biến có phạm vi ngắn (như var loop) thì người đó vẫn ổn.

Tôi sử dụng nó rất nhiều trong mã của mình và không nghĩ rằng có gì sai với nó. Điều đó nói rằng, tôi (có thể) sẽ không sử dụng nó trong một phương thức lâu hơn, giả sử một màn hình và nếu có nhiều trường hợp của lớp Person. Chắc chắn không đặt tên cho họ là person1, person2, person3 ... thay vào đó hãy sử dụng thứ gì đó mô tả hơn, như person_to_del, person_to_ban, person_to_update, v.v.

Không phải là vô đạo đức, nhưng một tìm kiếm toàn cầu sẽ tìm thấy cả hai Personvà personnếu bạn không kích hoạt phân biệt chữ hoa chữ thường. Tôi thích tiền tố hơn để làm cho việc tìm kiếm / thay thế toàn cầu dễ dàng hơn, nhưng hoàn toàn KHÔNG PHẢI là tiếng Hungary hoặc thứ gì đó dài / phức tạp. Vì vậy, tôi sử dụng ...

Personcho lớp / kiểu aPersoncho một biến cục bộ thePersoncho một tham số phương thức myPerson cho một biến cá thể ourPersoncho một biến lớp

Trong một số trường hợp hiếm hoi, tôi có thể sử dụng ptrong ngữ cảnh cục bộ nơi tôi có RẤT NHIỀU tham chiếu, nhưng điều đó thường chỉ áp dụng cho các chỉ mục vòng lặp và những thứ tương tự.

Nó phụ thuộc.

Nếu bạn có kiểu viết hoa nghiêm ngặt, vì vậy các biến bắt đầu bằng chữ thường (và sử dụng under_scores hoặc camelCase để ngắt từ) và Lớp bắt đầu bằng Chữ cái viết hoa, thì rõ ràng người là một biến và Người là một lớp và khi ai đó hiểu điều này , chúng dường như sẽ không nằm trong không gian tên chồng chéo. (Tương tự, mọi người hầu như không bao giờ bị nhầm lẫn giữa động từ hoặc danh từ "đánh bóng" và tính từ "Ba Lan".)

Nếu bạn không có phong cách như vậy, thì bạn có hai cái tên có thể dễ bị nhầm lẫn và chỉ khác nhau trong trường hợp. Điều đó thật xấu.

Những lập luận chính xác mà những người đó sử dụng là gì?

Nếu họ không cho phép bạn sử dụng người làm tên biến, bạn có thể cân nhắc thêm tiền tố 'a'.

aPerson = Person()

Tôi nghĩ những gì bạn đang làm là tốt. Tôi nghĩ nói chung điều quan trọng là phải có các tiêu chuẩn mã hóa được đồng ý.

Ví dụ: tôi sử dụng LowerCamelCase cho các phiên bản, biến và UpperCamelCase cho các lớp, v.v.

Tiêu chuẩn mã hóa nên loại bỏ vấn đề này.

Khi tôi xem xét các chương trình mã nguồn mở thành công, chúng thường có các tiêu chuẩn mã hóa

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

Đồng ý với các tiêu chuẩn mã hóa sẽ là trận chiến cuối cùng mà bạn phải trải qua.

Trên thực tế, hãy nhìn vào mục nhập wikipedia (từ http://en.wikipedia.org/wiki/CamelCase )

Phong cách lập trình và mã hóa

Viết hoa nội bộ đôi khi được khuyến nghị để chỉ ra ranh giới từ theo hướng dẫn về kiểu viết mã để viết mã nguồn (ví dụ: ngôn ngữ lập trình Mesa và ngôn ngữ lập trình Java). Các khuyến nghị có trong một số nguyên tắc này được hỗ trợ bởi các công cụ phân tích tĩnh để kiểm tra sự tuân thủ của mã nguồn.

Các khuyến nghị này thường phân biệt giữa UpperCamelCase và LowerCamelCase, thường chỉ định loại nào nên được sử dụng cho các loại thực thể cụ thể: biến, trường bản ghi, phương thức, thủ tục, loại, v.v.

Một kiểu mã hóa Java được sử dụng rộng rãi quy định rằng UpperCamelCase được sử dụng cho các lớp và LowerCamelCase được sử dụng cho các phiên bản và phương thức. [19] Nhận ra cách sử dụng này, một số IDE, chẳng hạn như Eclipse, triển khai các phím tắt dựa trên CamelCase. Ví dụ: trong tính năng Hỗ trợ nội dung của Eclipse, chỉ cần nhập các chữ cái viết hoa của từ CamelCase sẽ đề xuất bất kỳ tên phương thức hoặc lớp phù hợp nào (ví dụ: nhập "NPE" và kích hoạt hỗ trợ nội dung có thể đề xuất "NullPointerException").

Ký hiệu tiếng Hungary ban đầu để lập trình chỉ định rằng một chữ viết tắt chữ thường cho "kiểu sử dụng" (không phải kiểu dữ liệu) phải đặt tiền tố cho tất cả các tên biến, với phần còn lại của tên trong UpperCamelCase; như vậy nó là một dạng của LowerCamelCase. CamelCase là quy ước chính thức cho tên tệp trong Java và cho máy tính cá nhân Amiga.

Microsoft .NET khuyến nghị LowerCamelCase cho các tham số và trường không công khai và UpperCamelCase (hay còn gọi là "Kiểu Pascal") cho các kiểu định danh khác. [20]

Python đề xuất UpperCamelCase cho tên lớp. [21]

Sổ đăng ký NIEM yêu cầu Phần tử dữ liệu XML sử dụng UpperCamelCase và Các thuộc tính XML sử dụng LowerCamelCase.

Không có quy ước duy nhất nào cho việc bao gồm các chữ viết tắt chữ hoa (chủ yếu là các từ viết tắt và chữ viết tắt) trong tên CamelCase. Các cách tiếp cận bao gồm để lại toàn bộ chữ viết tắt bằng chữ hoa (chẳng hạn như trong "useHTTPConnection") và chỉ để lại chữ cái đầu tiên trong chữ hoa (chẳng hạn như trong "useHttpConnection").

Vỏ lạc đà không có nghĩa là phổ biến trong máy tính. Người dùng một số ngôn ngữ lập trình hiện đại, đặc biệt là những ngôn ngữ trong họ Lisp và Forth, gần như luôn sử dụng dấu gạch nối. Trong số các lý do đôi khi được đưa ra là làm như vậy không yêu cầu phải dịch chuyển trên hầu hết các bàn phím, các từ sẽ dễ đọc hơn khi chúng được tách rời và hộp đựng lạc đà có thể không được bảo quản một cách đáng tin cậy trong các ngôn ngữ phân biệt chữ hoa chữ thường hoặc gấp chữ (chẳng hạn như Lisp chung, trong khi về mặt kỹ thuật là một ngôn ngữ phân biệt chữ hoa chữ thường, chuẩn hóa (gấp) các định danh thành chữ hoa theo mặc định).

Có thể lập luận mạnh mẽ hơn rằng các tên phương thức thuộc loại đó không chỉ vô hại mà còn có thể là một chỉ báo cho mã chất lượng tốt.

• Một chỉ báo về mức độ chi tiết của mã tốt: Nếu các phương pháp của bạn ngắn gọn, có mục đích duy nhất và được đặt tên mô tả, bạn không cần nhiều thông tin trong các tên biến. Nếu bạn có các phương thức dài thực hiện nhiều việc và cần theo dõi nhiều ngữ cảnh và trạng thái, thì tên biến của bạn cần phải mô tả nhiều hơn.

• Một chỉ báo về các phép tính có mục đích chung được đẩy xuống thành các phương pháp có mục đích chung: nếu bạn thực hiện thao tác trung gian cấu trúc dữ liệu trong một phương pháp kinh doanh, ví dụ: một mảng người dùng phải được loại trừ trùng lặp, bạn sẽ phải có các biến trong phạm vi với các tên như users[]và deduplicatedUsers[]. Nếu bạn chuyển phép khử trùng lặp sang một phương thức tiện ích, bạn có thể gọi phương thức Utils.dedup(array)và bạn có thể gọi mảng được khử trùng lặp deduplicatedArrayhoặc chỉ result.

• Các trình biên dịch ngược Java thường sử dụng một lược đồ như vậy để đặt tên cho các biến cục bộ (các biến phiên bản và lớp thường có sẵn trong mã bytecode, nhưng các biến cục bộ thì không) và kết quả dễ đọc hơn bạn có thể mong đợi, trên thực tế thường dễ đọc hơn nguồn chính thức.

• Xem nguyên tắc của Larry Wall về "Sự mơ hồ cục bộ là ổn" - http://www.wall.org/~larry/natural.html .

Tôi muốn nói rằng bạn có thể có một số cách sử dụng cụ thể bất cứ khi nào bạn tạo một đối tượng. Riêng loại thì rất ít khi phản ánh công dụng đó.

Vì vậy, nếu bạn muốn tạo một liên hệ mới trong ứng dụng sổ địa chỉ của mình, bạn có thể muốn gọi biến newContact .

Và nếu bạn là đơn vị đang kiểm tra mã của mình để kiểm tra hành vi của Personcác đối tượng chưa được đặt tên, bạn có thể muốn gọi chúngunnamedPerson hoặc một cái gì đó tương tự.

Gọi nó chỉ đơn giản là personbỏ qua một cơ hội lớn để làm cho mã của bạn tự ghi lại.

Chỉ khi bạn đang lập trình trong VB6. Trong trường hợp đó , những gì bạn đang làm là bất hợp pháp, nhưng không trái đạo đức.

Tôi cũng làm điều đó, và tôi cũng không hiểu tại sao nó phải là 'trái đạo đức'. Mặc dù tôi có thể hiểu rằng nó 'có thể' đôi khi gây nhầm lẫn, nhưng hôm nay chúng tôi có IDE với intellisense và đánh dấu cú pháp sẽ đảm bảo rằng (nếu bạn mắc lỗi và tham chiếu biến thay vì lớp của bạn, và ngược lại) bạn sẽ thấy lỗi của bạn khá nhanh. Và chúng tôi cũng có trình biên dịch. :)

Tôi cũng không thấy có vấn đề gì với việc luyện tập này. Miễn là chỉ có một biến của lớp đó, nó sẽ dễ viết và dễ đọc. Imo, điều đó thậm chí còn áp dụng trong một trình soạn thảo văn bản cơ bản. Cá nhân tôi không thể nhớ bất cứ ai gọi điều này là xấu hoặc thậm chí là vô đạo đức. Chỉ cần tiếp tục làm điều này :)

Tôi nghĩ rằng 'quy tắc' mà bạn có thể đang nghĩ đến được dành nhiều hơn cho các kiểu nguyên thủy và các lớp mà tên lớp tạo ra một tên biến kém.

Ví dụ: nếu bạn đang xử lý việc tính toán chi phí của một mặt hàng cụ thể trong một cửa hàng trực tuyến, thì mã sau đây sẽ không phải là dạng tốt:

Decimal _decimal = item.BaseCost + item.Tax;

Thay vào đó, một cái tên mô tả hơn sẽ được khuyên dùng, chẳng hạn như '_total' hoặc '_cost'.

Vấn đề duy nhất với loại thứ này mà tôi đã tìm thấy là bạn có muốn trùng tên cho một thành viên riêng tư và cả tài sản chung hay không.

Nếu những điều này chỉ khác nhau trong trường hợp, nó sẽ hoạt động tốt trong các ngôn ngữ phân biệt chữ hoa chữ thường như C #, nhưng không phải trong VB.NET.

Vì vậy, ví dụ, trong VB, tôi sẽ viết

Private _name As String

nhưng

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

Tôi cũng sẽ làm như vậy trong C #, vì vậy việc dịch từ cái này sang cái kia là không khó. Nó cũng làm cho nó ít bị lỗi hơn một chút, vì nó rất dễ đọc sai hoặc thực sự là nhập sai các từ chỉ khác nhau theo từng trường hợp.

Không phải là vô đạo đức, nhưng nếu tên tốt nhất của bạn cho biến của bạn là tên của loại, một cái gì đó sai hoặc bạn chỉ tạo ra một bằng chứng về khái niệm hoặc một cái gì đó tương tự. Đối với tôi, một tên biến phải liên quan đến ý nghĩa trong ngữ cảnh kinh doanh chứ không phải ngôn ngữ lập trình. Sẽ khó hiểu mã hơn.

Tôi thường sử dụng Person person = new Person() bản thân mình. Thường được sử dụng trong Java / C #.

Mặc dù hôm qua tôi đã tự hỏi tại sao

private enum DataType {NEW, OLD}

không hoạt động trong C # ...

Đặc biệt là khi nhìn thấy cách bạn có thể sử dụng String, string, Double, double, ... theo ý thích trong C #.

Person person = new Person()

là tốt trong cuốn sách của tôi.

Thật kinh khủng khi bạn có:

string Person;
string person;

Rất dễ dàng để kết hợp cả 2.

Những gì đã được thể hiện với tôi, ngoài việc không đáp ứng Tiêu chuẩn mã hóa của chúng tôi, là tránh thêm sự nhầm lẫn khi người khác đang đọc mã của tôi. Cá nhân tôi thấy không có vấn đề gì với nó, miễn là ý nghĩa rõ ràng.

Đối với các kiểu CLR (int, string, v.v.), bạn có thể sử dụng String hoặc string (v.v.) để khai báo kiểu, vì vậy tôi sẽ tránh sử dụng những thứ như

int Int = 0;
string String = "hi there";

Việc tạo ra sự khác biệt duy nhất là viết hoa là rất nguy hiểm ... hãy tiếp tục làm điều này cho một dự án lớn và tôi đảm bảo rằng bạn sẽ gặp phải những lỗi kỳ lạ mà bạn dường như không thể xác định được.

fastPerson / slowPerson như trên cũng được ... chúng mang tính mô tả và phân biệt với tên kiểu biến ... nhưng thôi nào, gọi một int "Int" sẽ rất lười biếng.

Tôi sẽ nói nó không bao giờ vô đạo đức - nó thực sự chỉ là tên biến dòng cơ sở của bạn. Nếu bạn không thể nghĩ ra một cái tên hay hơn, đặt tên nó sau khi nó loại là một mặc định tốt (Đối với các loại phức tạp. Chỉ - cho xây dựng vào loại của nó ác ) Và rất nhiều thời gian ở đó thực sự không phải là một cái tên hay hơn nguyên nhân bạn không' t biết bất cứ điều gì khác về biến. Thích với phương pháp này

void SaveToDatabase(Person person) {...}

Về điều duy nhất mà bạn có thể gọi một cách hợp lý là người đó là person_to_savehoặc một cái gì đó tương tự có vẻ thừa.

Tuy nhiên, trong nhiều trường hợp, bạn có thể cải thiện khả năng đọc mã của mình bằng cách thay thế người bằng một tên mô tả hơn. Ví dụ, điều này ít mô tả hơn

void AddToAccount(Account account, Person person)  {...}

hơn cái này

void AddToAccount(Account account, Person dependent)  {...}

Tuy nhiên, xin vui lòng - xin vui lòng không đặt 'a' hoặc 't' trước tên loại. IE aPerson cho 'một người' hoặc tPerson cho 'người đó'. Nó quá phức tạp và không thêm nhiều giá trị nếu có. Thêm vào đó, bạn bắt đầu gây ô nhiễm phạm vi của bạn với một loạt các biến bắt đầu bằng a hoặc t có thể giảm thiểu giá trị của tri giác.

Tôi sẽ không nói nó kinh khủng. Tôi thường đặt tiền tố tên của biến bằng 'a' trong điều này để cho thấy rằng đó là một phiên bản duy nhất của kiểu, vì vậy tôi sẽ làm

Person aPerson = new Person();

Tôi nghĩ nó làm cho mã đọc tự nhiên hơn.

Hoàn toàn không có gì sai với nó tùy thuộc vào những lưu ý được chỉ ra bởi những người khác (tóm tắt ở đây để thuận tiện): không làm điều đó với các kiểu nguyên thủy, cấu trúc lại phiên bản gốc nếu một phiên bản khác được thêm vào sau đó, không sử dụng char-case để phân biệt tên lớp, v.v.

Quy tắc ngón tay cái của tôi? Các câu lệnh trong mã nên đọc giống như các câu tiếng Anh đơn giản.

Person person = new Person ();

Nhân viên nhân viên = person.getRole (NHÂN VIÊN);

Parent cha = person.getRole (PARENT);

person.getFullName ();

nhân viên.getSalary ();

parent.getChildren ();

parent.getFullName (); // giả sử mẫu trang trí đang phát

if (person.hasRole (EMPLOYEE)) {

  ...

}

Và kể từ đó trở đi.

Nếu phạm vi của biến bị giới hạn (ví dụ: phương thức đóng gói là 10-15 dòng), tôi thậm chí có thể sử dụng 'p' thay vì 'person'. Các tên biến ngắn hơn sẽ ít gây mất tập trung khi bạn cố gắng nắm bắt ngữ cảnh trong đầu. Tránh các tiền tố vô cớ như 'a' hoặc (rùng mình) ký hiệu Hungary và các nhánh của chúng. (Xin lưu ý bạn, tôi không có gì chống lại các tiền tố như vậy khi được sử dụng trong ngữ cảnh thích hợp - mã API C ++ / COM / ATL / Win32, v.v., nơi nó giúp giữ các bài tập / đánh máy thẳng hàng).

Hai bit (!) Của tôi :-)