Quy ước đặt tên: camelCase so với underscore_case? suy nghĩ của bạn về nó là gì? [đóng cửa]

Tôi đã sử dụng underscore_case được khoảng 2 năm và gần đây tôi đã chuyển sang camelCase vì công việc mới (đã sử dụng công việc sau khoảng 2 tháng và tôi vẫn nghĩ rằng underscore_case phù hợp hơn cho các dự án lớn, nơi có rất nhiều lập trình viên tham gia, chủ yếu là vì mã dễ đọc hơn).

Bây giờ mọi người trong công việc sử dụng camelCase bởi vì (vì vậy họ nói) mã trông thanh lịch hơn.

Bạn nghĩ gì về camelCase hoặc underscore_case

ps xin lỗi tiếng anh xấu của tôi

Biên tập

Một số cập nhật đầu tiên:

• nền tảng được sử dụng là PHP (nhưng tôi không mong đợi các câu trả lời nghiêm ngặt liên quan đến nền tảng PHP, bất kỳ ai cũng có thể chia sẻ suy nghĩ của họ về cách tốt nhất để sử dụng, đó là lý do tại sao tôi đến đây ngay từ đầu)

• Tôi sử dụng camelCase giống như mọi người khác trong nhóm (giống như hầu hết các bạn giới thiệu)

• chúng tôi sử dụng Zend Framework cũng đề xuất camelCase

Một số ví dụ (liên quan đến PHP):

• Khung Codeigniter khuyến nghị underscore_case và trung thực mã dễ đọc hơn.

• ZF giới thiệu camelCase và tôi không phải là người duy nhất nghĩ rằng mã ZF khó theo dõi hơn.

Vì vậy, câu hỏi của tôi sẽ được đăng lại:

Hãy xem trường hợp bạn có nền tảng Foo không đề xuất bất kỳ quy ước đặt tên nào và đó là lựa chọn của trưởng nhóm để chọn một. Bạn là trưởng nhóm, tại sao bạn lại chọn camelCase hoặc tại sao lại gạch dưới?

ps cảm ơn mọi người vì câu trả lời nhanh chóng cho đến nay

Tôi đồng ý rằng nó phụ thuộc vào ngôn ngữ bạn đang sử dụng ở một mức độ nào đó; mã có xu hướng trông gọn gàng hơn khi tên biểu tượng của bạn tuân theo chế độ định dạng giống như thư viện chứng khoán và thư viện sẵn có của ngôn ngữ.

Nhưng trong trường hợp có sự lựa chọn, tôi thích gạch dưới vỏ lạc đà hơn, vì một lý do đơn giản: tôi thấy phong cách đó dễ đọc hơn. Đây là một ví dụ: bạn thấy dễ đọc hơn? Điều này:

aRatherLongSymbolName

hoặc này:

a_rather_long_symbol_name

Tôi thấy phiên bản gạch dưới dễ đọc hơn nhiều. Não của tôi có thể bỏ qua các dấu gạch dễ dàng hơn nhiều so với khả năng phát hiện các ranh giới chữ thường / hoa trong trường hợp lạc đà, đặc biệt là nơi ranh giới là giữa glyphs mà trông giống như glyphs khác của trường hợp ngược lại, hoặc chữ số ( I/l, O/0, t/I, vv). Ví dụ: biến boolean này lưu trữ một giá trị cho biết liệu Igloo có được xây dựng với sự cho phép lập kế hoạch phù hợp hay không (chắc chắn là trường hợp sử dụng chung cho tất cả chúng ta):

isIllicitIgloo

Tôi thấy phiên bản này dễ đọc hơn nhiều :

is_illicit_igloo

Có lẽ thậm chí còn tệ hơn một tên biểu tượng khó đọc là một tên biểu tượng dễ đọc sai. Tên biểu tượng tốt là tài liệu tự, điều đó với tôi có nghĩa là bạn sẽ có thể đọc chúng và hiểu ý nghĩa của chúng trong nháy mắt. (Tôi chắc chắn rằng tất cả chúng ta đều đọc mã in trên giường để giải trí, nhưng đôi khi chúng ta cũng vội vã vội vã.) Tôi thường tìm thấy với các tên biểu tượng vỏ lạc đà rất dễ đọc sai và gây ấn tượng sai về ngữ nghĩa của biểu tượng.

Tôi nghĩ bạn nên sử dụng quy ước đặt tên được thông qua bởi nền tảng của bạn. underscore_case sẽ trông lạ trong mã C #, như camelCase trong Ruby =)

Thành thật mà nói, nó không thực sự quan trọng miễn là mọi người trong nhóm sử dụng cùng một sơ đồ. Cơ hội là một hoặc khác là tự nhiên hơn đối với bạn, mặc dù tầm quan trọng thực sự là khả năng đọc mã trong thời gian dài và sau đó điều quan trọng là mọi người phải tuân thủ các quy tắc đặt tên giống nhau.

Dựa trên một câu trả lời, câu trả lời của John Isaacks:

"Thành thật mà nói thì mã dễ đọc hơn" Ý kiến ​​hay thực tế?

Tôi quyết định thực hiện một số nghiên cứu, và tìm thấy bài báo này . Khoa học nói gì về chủ đề này?

1. Vỏ lạc đà có xác suất chính xác lớn hơn so với dấu gạch dưới. (tỷ lệ cược cao hơn 51,5%)
2. Trung bình, trường hợp lạc đà mất 0,42 giây , lâu hơn 13,5%.
3. Đào tạo không có tác động đáng kể về mặt thống kê đối với cách phong cách ảnh hưởng đến tính chính xác.
4. Những người được đào tạo nhiều hơn đã nhanh hơn về các định danh theo kiểu vỏ lạc đà.
5. Đào tạo theo một phong cách, tác động tiêu cực đến thời gian tìm kiếm các phong cách khác.

Trong bài viết trên blog của tôi về chủ đề này, tôi xem lại bài báo khoa học và đưa ra kết luận sau đây.

Chỉ có sự chậm chạp của trường hợp lạc đà (2) là thực sự phù hợp để lập trình, loại bỏ các điểm khác là không liên quan do các IDE hiện đại và phần lớn người dùng camelCase trong nghiên cứu. Các cuộc thảo luận (cùng với một cuộc thăm dò) có thể được tìm thấy trên bài viết blog.

Tôi tò mò làm thế nào bài viết này có thể thay đổi ý kiến. :)

Sao chép những người thông minh nhất

Trong trường hợp ngôn ngữ lập trình, sao chép phong cách của nhà phát triển ngôn ngữ.

Ví dụ, tôi mã C chính xác như được thực hiện trong K & R.

Sau đó, khi bất cứ ai cố gắng bắt đầu một cuộc trò chuyện theo phong cách mã hóa nhàm chán, tôi có thể nói với họ "hãy mang điều đó lên với Dennis Ritche và cho tôi biết những gì anh ta nói."

Nói chung, tôi thích camelCase. Tuy nhiên, đó là vì phần lớn sự nghiệp của tôi, tôi đã làm việc trong các ngôn ngữ và môi trường nơi các hướng dẫn viên phong cách thường khuyên dùng camelCase. (Java, ECMAScript, C ++). Bạn, là một người PHP, có khả năng có sở thích ngược lại.

Điều đó nói rằng, khi bạn vượt ra ngoài baOrFouremme hoặc nếu bạn sử dụng các chữ viết tắt nhưXmlForExample, nó sẽ không thể đọc được.

Đó là lý do tại sao emacs cho chúng ta chế độ kính.

lạc đà

Đây là một trong số ít những nơi tôi sẽ luôn chọn 'khả năng loại' hơn khả năng đọc. CamelCase chỉ dễ gõ hơn và ngón tay của tôi đẹp hơn sẽ giúp tôi dễ dàng đạt được hơn.

tất nhiên giả định rằng dự án không xây dựng trên một cơ sở mã hiện có với một tiêu chuẩn khác.

Đó là một câu hỏi thú vị, tôi đã suy nghĩ về điều này nhiều lần. Nhưng tôi không có câu trả lời chắc chắn.

Theo các công ước "văn hóa", đó là một lựa chọn tốt. "Văn hóa" trong trường hợp này có nghĩa là các quy ước được thiết lập trong nhóm / công ty và về cơ bản chúng cũng mang các quy ước về ngôn ngữ / nền tảng. Nó giúp người khác đọc / sử dụng mã của bạn một cách dễ dàng và không yêu cầu thêm nỗ lực và thời gian để hiểu cách hiểu về mã của bạn.

Đôi khi nó là thú vị để phá vỡ các ký hiệu được chấp nhận. Một trong những dự án nhỏ của tôi (trên Python) tôi đã sử dụng underscored_namescho các hàm tiện ích / phương thức "được bảo vệ" và kiểu Java methodNamescho các phương thức. Đội của tôi rất vui với điều đó :)

Phụ thuộc vào ngôn ngữ lập trình.

Tôi xem xét sử dụng trường hợp trong cùng một chiếc thuyền về việc có sử dụng ký hiệu Hungary hay không:

• Python: underscore_case, không có ký hiệu Hungary
• C ++: camelCase, ký hiệu Hungary

Cả hai!

Tôi làm rất nhiều phát triển trong CakePHP, và tôi sử dụng một trong hai CamelCasehoặc $underscored_vars, trong thời trang sau (thậm chí bên ngoài dự án CakePHP):

1. tên tập tin - /lowercased_underscored.phpĐiển hình, nhưng đáng nói.
2. các lớp học - class CamelCase extends ParentObject. Lưu ý rằng, khi sử dụng CamelCase, ký tự ban đầu không phải là chữ thường. Tôi thấy camelCasetrông thật kỳ lạ.
3. biến -$are_variables_underscored === TRUE;
4. các biến chứa các trường hợp -$CamelCase = new CamelCase();
5. các phím mảng -$collection['underscored_keys'];
6. hằng số - Tôi nghĩ mọi người đều có thể đồng ý rằng hằng số nên được ALL_CAPS_AND_UNDERSCORED.
7. phương pháp -$CamelCase->foo_method_underscored();
8. phương pháp tĩnh -CamelCase::just_like_regular_methods();

Cá nhân tôi thích underscore_casebởi vì tôi thấy nó dễ đọc hơn, nhưng đồng ý với những người trả lời khác, những người chỉ ra rằng tính nhất quán với cơ sở mã hiện tại quan trọng hơn nhiều.

Tuy nhiên, tôi có một ví dụ cho những người nói "tuân theo quy ước về ngôn ngữ của bạn và các thư viện của nó".

Trước đây, chúng tôi đã viết mã C trên Windows bằng cách sử dụng underscore_casevà được gọi là các PascalCasehàm Win32:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

Sự khác biệt trực quan giữa tên hàm của chúng tôi và tên hàm của Microsoft là một sự trợ giúp chứ không phải là một trở ngại, vì nó cho thấy rõ khi mã đi vào "vùng đất hệ thống".

Ngoài ra, tôi có thể thay đổi các quy tắc tô sáng cú pháp của trình soạn thảo của mình để hiển thị chúng theo các màu khác nhau, điều này mang lại thêm manh mối trực quan khi cố gắng hiểu các phần mã lạ (hoặc thậm chí là của riêng tôi).

Tôi thực sự thích Dylan chỉ là bình thường-gạch ngang-như-chúng-là-dễ-dễ-loại-và-dễ-đọc.

Như

result-code := write-buffer(file-stream, some-string)

Nhưng tôi đoán vì ngôn ngữ này khá tối nghĩa, đây là loại ngoài chủ đề ... :(

Tôi được dạy sử dụng camelCase tại trường đại học. Tôi đã sử dụng một vài quy ước khác nhau trong vài năm qua nhưng thích camelCase hơn bất kỳ điều gì khác. Tôi nghĩ rằng tôi nhớ đã đọc ở đâu đó rằng camelCase thực sự là dễ đọc và dễ hiểu nhất.

Như hầu hết mọi người đã đề cập - Sử dụng các tiêu chuẩn hiện có. Nếu đó là một dự án mới, hãy sử dụng tiêu chuẩn cho ngôn ngữ và khung bạn sẽ sử dụng.

Và đừng nhầm lẫn, đây không phải là về khả năng đọc (chủ quan), mà là về sự nhất quán và chuyên nghiệp. Bất cứ ai đã làm việc trong một cơ sở mã với nhiều 'tiêu chuẩn' đang diễn ra đều sẽ hiểu.

Đôi khi tôi sử dụng một hỗn hợp: module_FeftName. Tất cả các chức năng (không tĩnh) trong các mô-đun của tôi bắt đầu bằng chữ viết tắt mô-đun.

Ví dụ: chức năng gửi nội dung của bộ đệm trên bus I2C:

i2c_BufferSend()

Sự thay thế i2c_buffer_sendkhông hiển thị một sự tách biệt đủ lớn giữa tiền tố và tên hàm. i2cBufferSendtrộn các tiền tố quá nhiều (có khá nhiều hàm I2C trong mô-đun này).

i2c_Buffer_send có thể đã được thay thế, mặc dù.

Câu trả lời của tôi là bạn thích nghi với những gì phù hợp nhất với dự án của bạn (ngôn ngữ, kiến ​​trúc SW của bạn, ...) và tôi muốn chỉ ra rằng việc trộn các kiểu này có thể hữu ích.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Cá nhân, tôi thích camelCase, nhưng trong một số phông chữ tôi nghĩ rằng dấu gạch dưới dễ đọc hơn.

Tôi sẽ đề nghị rằng nếu bạn cần sử dụng tiền tố để phân biệt các bộ biến, bạn nên sử dụng ngôn ngữ cho phép bạn tạo không gian tên hoặc đối tượng hoặc một cái gì đó để giữ thông tin đó.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Tương tự như vậy, nếu bạn cần phân biệt các loại, tại sao không sử dụng ngôn ngữ cho phép chúng?

var intThingy = 7; // :(

int thingy = 7;    // :)

Khi bạn đã hiểu rõ và bạn không chỉ sử dụng tên làm siêu dữ liệu, thì bạn sẽ không có đủ tên dài mà vấn đề rất quan trọng cho dù bạn có thích nhấn phím thêm hay không.

Lúc đầu, tôi đồng ý với dafmetal. Điều quan trọng nhất là bạn không trộn lẫn các phong cách lập trình khác nhau. Làm điều này trong một và cùng một tệp là điều tồi tệ nhất bạn có thể làm IMHO. Trên các tập tin khác nhau, nó gây mất tập trung, nhưng không gây tử vong.

Điều tiếp theo bạn phải làm là đặt tên cho các quy tắc phổ biến cho ngôn ngữ mà bạn đang viết. Mã C ++ của tôi cho instnace, sẽ trông khác với một cái gì đó cho Python rõ ràng (PEP8 là một hướng dẫn hay ở đây)

Bạn cũng có thể sử dụng các quy ước đặt tên khác nhau để chỉ những thứ khác nhau, nhiều như bạn có thể sử dụng UPPER_CASE cho các hằng số (tất nhiên chỉ áp dụng cho một số ngôn ngữ nhất định), bạn có thể sử dụng this_style cho tên biến cục bộ, trong khi bạn sử dụng camelCase chẳng hạn biến. Điều này có thể không cần thiết khi bạn có những thứ như selfhoặc thistuy nhiên.

Cập nhật

Hãy xem trường hợp bạn có nền tảng phù thủy Foo không đề xuất bất kỳ quy ước đặt tên nào và đó là lựa chọn của người lãnh đạo nhóm để chọn một. Bạn là trưởng nhóm, tại sao bạn lại chọn camelCase hoặc tại sao lại gạch dưới.

Không có lợi thế cho người này hơn người kia thực sự. Vấn đề này rất chủ quan và một khi được thỏa thuận, nó sẽ không tạo ra sự khác biệt. Luôn có những cuộc chiến liên tục về những điều nhỏ nhặt này. Nhưng một khi bạn đã điều chỉnh được một trong hai, các cuộc thảo luận dường như hoàn toàn không cần thiết.

Để trích dẫn Alex Martelli về một vấn đề rất giống nhau:

Chắc chắn, tôi cảm thấy mệt mỏi, trong Ruby, khi gõ "kết thúc" ngớ ngẩn ở cuối mỗi khối (thay vì chỉ vô ý) - nhưng sau đó tôi phải tránh gõ từ 'ngớ ngẩn không kém': 'mà Python yêu cầu sự khởi đầu của mỗi khối, vì vậy đó gần như là một rửa :-). Các khác biệt cú pháp khác, chẳng hạn như '@foo' so với 'self.foo' hoặc tầm quan trọng cao hơn của trường hợp trong Ruby vs Python, thực sự không liên quan đến tôi.

Những người khác không nghi ngờ gì về việc họ lựa chọn ngôn ngữ lập trình cho những vấn đề như vậy và họ tạo ra những cuộc tranh luận sôi nổi nhất - nhưng với tôi đó chỉ là một ví dụ về Luật của Parkinson trong hành động ( số tiền tranh luận về một vấn đề tỷ lệ nghịch với vấn đề tầm quan trọng thực tế ).

Nguồn

Nếu bạn là trưởng nhóm, bạn chỉ cần đi với một. Vì người này không có bất kỳ lợi thế nào so với người khác, bạn có thể ném xúc xắc hoặc chọn những gì bạn thích hơn.

Tôi đã đọc cách đây vài năm rằng các lập trình viên không nói tiếng Anh là ngôn ngữ đầu tiên có xu hướng tìm trường hợp gạch dưới dễ hiểu hơn về trường hợp lạc đà đó - nhưng tôi không thể tìm thấy tài liệu tham khảo và tôi không biết liệu đó có phải là sự thật hay không.

Đối với các ngôn ngữ lập trình tôi đã sử dụng, như Java, Python, C ++, tôi đã sử dụng một định dạng rõ ràng:

• ClassNamesArePascalCase
• phương thứcNamesAreCamalCase
• biến_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Điều này cho phép tôi nhận ra ngay lập tức những gì tôi đang giải quyết. Tôi đã thấy rằng sẽ hữu ích để duy trì cho chính mình, và nó nên dễ dàng theo dõi cho người khác đọc mã. Tôi nghĩ như những người khác đề cập đến sự nhất quán là quan trọng nhất. Vì vậy, tôi thấy định dạng của mình đủ đơn giản để duy trì, đồng thời cung cấp sự khác biệt rõ ràng giữa các loại tên. Tôi có thể tưởng tượng interface_Names_Are_Like_ This và Abstract_Class_Are_Like_Đây là các tiện ích mở rộng có thể, nhưng dường như phức tạp hơn để làm theo và có thể không phải là một cách phân biệt hữu ích.

Tôi cũng thấy hữu ích khi nghiêm ngặt và đặt tên cho mọi thứ trong PascalCase, chẳng hạn như trình phân tích cú pháp HTML như HtmlParser thay vì HTMLParser hoặc HTMLparser. Bởi vì tôi tin rằng việc nhớ quy tắc nghiêm ngặt sẽ dễ dàng hơn và giữ cho ranh giới từ rõ ràng hơn (thật không may, nó yêu cầu những lỗi sai chính tả như HTML hoặc SQL). Tương tự với camelCase, htmlParserMethod thay vì HTMLParserMethod hoặc HTMLparserMethod.

CẬP NHẬT :

Kể từ khi tôi tìm thấy việc sử dụng trong việc mở rộng các quy tắc này để bao gồm các biến riêng tư. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

Trong Java, điều này có nghĩa là các trường riêng theo định nghĩa trong một không gian tên khác với các biến cục bộ, có nghĩa là bạn có thể bỏ qua các this.trường riêng. Các định dạng khác tôi đã thấy tiền tố với " m", nhưng các định dạng đó cũng sử dụng camelCase cho các tên biến. Điều này cũng cho phép tôi để làm cho một sự phân biệt giữa các trường mà chỉ nên được truy cập nội bộ bởi lớp (và làm cho nó siêu rõ ràng khi nó đang xảy ra bên ngoài của lớp object._field_xnổi bật).

Nếu điều đó tùy thuộc vào tôi, tôi sẽ không thực thi hoặc gợi ý về việc sử dụng bất kỳ phong cách cụ thể nào bởi vì, với tư cách là lập trình viên, chúng tôi có thể đọc ký hiệu IfItIsInCamelCase hoặc in_underscore_space hoặc thậm chí trong_SomeOtherStyle và hiểu ý nghĩa của nó. Phải dành một lượng thời gian nhỏ để phân tích biểu tượng không phải là chi phí lớn trong sơ đồ lớn của mọi thứ.

Bây giờ, đối số chính cho một quy ước tôi đoán là bạn biết trước định dạng của hàm / tên biến là gì và không cần tìm nó - đó có phải là LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file không? Bây giờ, tôi sẽ chống lại lập luận đó bằng cách nói "Nhận một IDE hỗ trợ hoàn thành tự động kiểu intellisense!" (không phải lúc nào cũng có thể).

Tuy nhiên, cuối cùng, việc bạn sử dụng beacuse theo trình biên dịch / trình thông dịch không thực sự quan trọng. Điều quan trọng là tên này hữu ích:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Ba phong cách khác nhau, nhưng bạn biết chính xác những gì mỗi người làm.

Có thể có vẻ ngớ ngẩn, nhưng tôi không thích gạch dưới vì phần gạch dưới mỏng và ẩn trong nhiều dòng văn bản và tôi nhớ nó. Ngoài ra, trong một số (nhiều) trình soạn thảo văn bản và / hoặc môi trường dev, khi bạn nhấp đúp vào tên mã thông báo để tô sáng nó để sao chép hoặc kéo và thả nó, hệ thống sẽ không làm nổi bật toàn bộ mã thông báo, nó chỉ làm nổi bật một phần của mã thông báo, giữa các dấu gạch dưới liền kề. Điều đó khiến tôi phát điên.

Tôi có xu hướng thích camelCase vì lý do ngớ ngẩn rằng tôi thực hiện hầu hết sự phát triển của mình trong Eclipse (Đối với Java, PHP và JavaScript) và khi tôi Ctrl+ ←hoặc Ctrl+ →thông qua các từ, nó thực sự dừng lại ở ranh giới camelCase.

Tức là: myIntVariablesẽ được Eclipse coi là 3 từ khi Ctrl+ ← →'thông qua nó.

Tôi biết đó là một sự ngớ ngẩn kỳ lạ, nhưng tôi thấy mình thích chỉnh sửa các từ giữa trong một tên camelCase.