it-swarm-vi.com

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

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

p.s. xin vui lòng xin lỗi tiếng anh của tôi

Chỉnh sửa

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 nghiêm ngặt PHP câu trả lời liên quan đến nền tảng, bất kỳ ai cũng có thể chia sẻ suy nghĩ của mình về cách tốt nhất để sử dụng, đó là 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à thành thật mà nói 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?

p.s. cảm ơn mọi người vì câu trả lời của Prompt cho đến nay

70
poelinca

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. Bộ não của tôi có thể bỏ qua các dấu gạch dưới dễ dàng hơn nhiều so với việc có thể phát hiện ranh giới chữ thường/chữ hoa trong trường hợp lạc đà, đặc biệt là ranh giới giữa các glyph trông giống với các glyph khác của trường hợp ngược lại hoặc chữ số (I/l, O/0, t/I, Vân vân). 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 tìm thấy phiên bản này a lot dễ đọc hơn:

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.

84
Simon Whitaker

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 =)

97
Alexey Anufriyev

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.

20
dafmetal

Dựa trên 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 , dài 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ó được đào tạo nhiều hơn đã nhanh hơn trên các định danh theo kiểu vỏ lạc đà.
  5. Đào tạo theo một kiểu, tác động tiêu cực đến thời gian tìm cho các kiểu khác.

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

Chỉ có sự chậm chạp của trường hợp lạc đà (2) 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 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 trên blog.

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

20
Steven Jeuris

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 làm điều đó với Dennis Ritche và cho tôi biết những gì anh ta nói."

11
Mark Harrison

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 người, 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.

10
Paul Butcher

camelCase

Đâ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 mức tăng dễ đọc hơn.

tất nhiên giả sử 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.

8
AShelly

Đó 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 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_names cho các hàm tiện ích/phương thức "được bảo vệ" và kiểu Java methodNames cho các phương thức. Đội của tôi rất vui với điều đó :)

7
duros

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

Tôi xem xét việc 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
6
Lionel

Cả hai!

Tôi phát triển rất nhiều trong CakePHP và tôi sử dụng CamelCase hoặc $underscored_vars, Theo cách sau (ngay cả ngoài Dự án CakePHP):

  1. tên tệp - /lowercased_underscored.php Điển hình, nhưng đáng nói.
  2. các lớp - 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 camelCase nhìn thực sự kỳ lạ.
  3. biến - $are_variables_underscored === TRUE;
  4. các biến chứa phiên bản - $CamelCase = new CamelCase();
  5. khóa mảng - $collection['underscored_keys'];
  6. hằng số - Tôi nghĩ mọi người đều có thể đồng ý rằng các hằng số phải là ALL_CAPS_AND_UNDERSCORED.
  7. phương thức - $CamelCase->foo_method_underscored();
  8. phương thức tĩnh - CamelCase::just_like_regular_methods();
6
Stephen

Cá nhân tôi thích underscore_case bở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_case và được gọi là PascalCase Hà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ã đang đ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).

5
Paul Stephenson

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.

Giống

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

Nhưng tôi đoán vì ngôn ngữ này khá mơ hồ, đây là loại ngoài chủ đề ... :(

5
Kosta

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.

4
Ross

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õ điều đó 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.

4
Kevin Cantu

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.

4
Colin Goudie

Đô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 bộ đệm trên bus I2C:

i2c_BufferSend()

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

i2c_Buffer_send có thể là một sự 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.

4
Gauthier

Đố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 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 Word rõ ràng hơn (không may là 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 this. trên các lĩnh vực tư nhân. 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 phân biệt giữa các trường chỉ được truy cập bên trong bởi lớp (và làm cho nó siê rõ ràng khi nó xảy ra bên ngoài lớp object._field_x đứng ra).

2
Dandre Allison

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 tốt đẹp ở đâ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 ví dụ/thành viên camelCase biến. Điều này có thể không cần thiết khi bạn có những thứ như self hoặc this tuy 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 sẽ tránh được việc gõ một cách ngớ ngẩn không kém ':' which Python yêu cầu tại bắt đầ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 so với 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 chỉ dựa trên 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ề một trong những Luật của Parkinson ( số tiền tranh luận về một vấn đề tỷ lệ nghịch với tầm quan trọng thực tế của vấn đề ).

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.

2
phant0m

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.

2
Ed Harper

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í in_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!" (Mặc dù 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.

1
Skizz

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 là Ctrl+ thông qua các từ, nó thực sự dừng lại ở ranh giới camelCase.

I.e.: myIntVariable sẽ đượ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.

0
Bassam

Có thể có vẻ ngớ ngẩn, nhưng tôi không thích dấu 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.

0
Charles Bretana