Quy ước đặt tên Javascript


12

Tôi đến từ nền tảng Java và chưa quen với JavaScript. Tôi đã nhận thấy nhiều phương thức JavaScript sử dụng tên tham số ký tự đơn, chẳng hạn như trong ví dụ sau.

doSomething(a,b,c)

Tôi không thích nó, nhưng một nhà phát triển JavaScript đồng nghiệp đã thuyết phục tôi rằng điều này được thực hiện để giảm kích thước tệp, lưu ý rằng các tệp JavaScript phải được chuyển đến trình duyệt.

Sau đó, tôi thấy mình nói chuyện với một nhà phát triển khác. Anh ấy chỉ cho tôi cách Firefox sẽ cắt bớt tên biến để tải trang nhanh hơn. Đây có phải là một thực hành tiêu chuẩn cho các trình duyệt web?

Các chuyển đổi đặt tên thực hành tốt nhất nên được tuân theo khi lập trình bằng JavaScript là gì? Liệu chiều dài định danh có vấn đề, và nếu vậy, đến mức độ nào?


13
Tôi rất nghi ngờ trình duyệt thay đổi tên biến. Với sự hiện diện của evalnó, nó không an toàn (vâng, evalthật kinh khủng, nhưng nó là một phần của tiêu chuẩn và bạn không vứt bỏ tính tổng hợp tiêu chuẩn để tối ưu hóa) và nó không giúp ích gì trong việc giảm lưu lượng - bạn vẫn sẽ gửi tập tin đầy đủ.

4
Tôi thường thấy các nhà phát triển tranh luận về lợi thế của tên biến ngắn. Đừng nghe họ nói. Điều này gần như luôn luôn là một cái cớ cho "Tôi quá ngón tay cái để phát minh ra một cái tên hay" hoặc "Tôi quá lười để gõ nhiều ký tự đó".
Doc Brown

@DocBrown: Ngay cả tôi cũng không thích nó. Vì tôi không phải là một chuyên gia về JavaScript muốn biết cách thực hành tốt nhất.
ManuPK

Vào cuối ngày, người ta đã nói về dữ liệu bổ sung có lẽ trị giá 50 - 100KB để sử dụng tên phương thức có ý nghĩa? Nếu 100KB gây ra vấn đề về tốc độ thì không đáng để cố gắng giải quyết, bởi vì không có một nhóm người dùng đủ lớn sẽ gặp phải vấn đề đó.
Ramhound

Câu trả lời:


26

Bạn sẽ thấy rằng chính các nhà phát triển không sử dụng tên biến ngắn. Trong khi phát triển, họ đang sử dụng các tên biến có ý nghĩa và chi tiết.

Sau đó , trong quá trình xây dựng / phát hành, mã họ đã viết được chạy qua một công cụ khai thác / obfuscator với mục đích giảm thiểu kích thước của tệp, như một cách tốt nhất để tăng tốc trang web. Đây là một tùy chọn bước nếu bạn quan tâm nhiều về hiệu suất. Hầu hết các trang web nhỏ không làm điều này.

Bạn , với tư cách là một nhà phát triển, không nên quan tâm đến quá trình thu nhỏ / che giấu; viết mã của bạn để nó có thể đọc được, có ý nghĩa, tài liệu tốt và có cấu trúc tốt. Sau đó, nếu bạn quan tâm rất nhiều đến hiệu suất (tùy chọn, đừng quên!), Hãy giới thiệu công cụ khai thác / obfuscator vào quy trình phát hành của bạn để thu nhỏ mã (xóa khoảng trắng, dòng mới, nhận xét, v.v.) và làm mờ nó (ví dụ rút ngắn biến tên). Một bài viết tốt giải thích obfuscation vs minifying có thể được tìm thấy ở đây .

Ngoài ra, Desktop FireFox sẽ không rút ngắn thời gian tên biến . Việc cắt bớt tên biến là có để tăng tốc độ tải xuống trang. Vào thời điểm FireFox nhận được tệp, nó đã được tải xuống, do đó không cần phải làm như vậy. Bạn của bạn có thể chạy một plugin đang làm điều này; trong trường hợp đó, hãy bảo anh ta gỡ cài đặt nó, vì nó vô dụng.

Để hoàn tất, một số trình duyệt (di động) có tùy chọn sử dụng máy chủ trung gian, chặn các phản hồi của tài nguyên bạn yêu cầu và nén chúng cho bạn ( có thể bao gồm thu nhỏ tệp JavaScript). Lưu ý rằng việc nén được thực hiện trên máy chủ (tức là trước khi bạn đã tải xuống trang), do đó lợi ích tiềm năng của việc tải xuống một tệp nhỏ hơn là trong trình duyệt khi bạn đã tải xuống tệp (như được đề xuất trong câu hỏi). Các trình duyệt di động như vậy bao gồm Opera Mini và các phiên bản Google Chrome mới hơn (ít nhất là trên iOS; không chắc chắn về Android). Để biết thêm thông tin, xem tại đây .


11

Không, không phải tất cả các trình duyệt sẽ tự động rút ngắn JavaScript để giúp thực hiện.

Tuy nhiên, trong trường hợp JavaScript, bạn không nên hy sinh khả năng đọc / duy trì mã để tăng tốc độ xử lý hoặc bảo mật vì có các công cụ gọi là obfuscators và các công cụ khác gọi là shinkers (hoặc máy nén) được thiết kế cho mục đích này.

Hãy nhớ, không tối ưu hóa trước. Nếu trang của bạn tải đủ nhanh và bạn không có bất kỳ nội dung quá nhạy cảm nào trong JavaScript, đừng lo lắng về điều đó. Đặt tên cho biến của bạn với tên có ý nghĩa. Khả năng đọc mã rất quan trọng đối với khả năng bảo trì và hiếm khi, nếu có, phải được hy sinh.

Nếu bạn muốn tham khảo một số quy ước mã hóa JavaScript tốt, tôi khuyên bạn nên sử dụng các quy ước này .


2

Đừng lo lắng về kích thước tập tin sớm. Trong khi nó luôn luôn là một mối quan tâm, khả năng đọc và bảo trì là quan trọng hơn.

Với những gì đã nói, bạn có lẽ nên được servining minified (ví dụ, thông qua YUI Compressor ) phiên bản của kịch bản của bạn anyway.

Nếu bạn quan tâm đến các thực tiễn tốt nhất để phát triển web nói chung, tôi khuyên bạn nên đọc Mọi lập trình viên nên biết gì về phát triển web?


1

Tôi đã làm việc trong JavaScript trong một thời gian rất dài.

Chúng tôi đã có một tiêu chuẩn đặt tên mà bạn phải sử dụng Ký hiệu Hungary cho tất cả các biến.

Nó dường như hoạt động tốt. Tôi biết rằng có những trường hợp chống lại việc sử dụng đó, nhưng nó đã làm việc tốt cho chúng tôi. Đặc biệt là khi bạn có các tệp JavaScript lớn, nơi bạn cần tìm nội dung.

Tôi sẽ thận trọng chống lại tối ưu hóa sớm. Bạn rất có khả năng kết thúc với mã lộn xộn không thực sự chạy nhanh hơn nhiều.


5
Ký hiệu Hungary? Đó là trường học cũ. Ký hiệu Hungary là một bản phát triển cũ và trong thời gian không còn được khuyến khích nữa.
Khói chân

2
Tôi có xu hướng sử dụng nó một chút, nhưng chỉ với các giá trị được bao bọc bởi jquery, những giá trị tôi sẽ bắt đầu bằng $. Vấn đề với ký hiệu Hungary là mọi người thường nói với bạn gõ theo "int" so với "String" chứ không phải về mặt sơ đồ của một chương trình
Zachary K

"Đặc biệt là khi bạn có các tệp JavaScript lớn, nơi bạn cần tìm nội dung." -- Tôi nghe bạn. Nhưng ký hiệu Hungary chỉ là một thạch cao gắn bó ... về lâu dài nó sẽ không giúp ích gì, nó sẽ chỉ gây nhầm lẫn khi bạn cần thay đổi loại thứ gì đó nhưng không có thời gian để thay đổi tất cả các tiền tố biến đổi. Tự động hóa tất cả những gì mà GWT đi vào IMO của chính nó.
funkybro

1
Tôi không nhất thiết phải mua bằng cách sử dụng ký hiệu là "phá vỡ" các khía cạnh được đánh máy lỏng lẻo của ngôn ngữ. Chắc chắn, bạn sẽ phải thay đổi tên khi bạn thay đổi loại, nhưng dù sao đó cũng là một việc nên làm để bạn có thể theo dõi những gì bạn đang làm. Tôi biết có những khía cạnh của nó là xấu xí. Nhưng, nếu bạn đã từng làm việc trong một dự án LỚN (tôi đang nói hàng trăm ngàn dòng mã) bằng một ngôn ngữ được gõ lỏng lẻo, nó có thể giúp bạn tìm đường nhanh hơn trong một số trường hợp nhất định. Nói rằng đó là ngày, vv thực sự không giải quyết vấn đề cốt lõi mà OP đang cố gắng yêu.
Alan Delimon

1
Ký hiệu Hungary là một trong những điều mà mọi người bỏ qua ngay lập tức mà không thực sự hiểu tại sao. Nó được tìm thấy theo cùng một thể loại khi gotomọi người vô thức lặp lại câu thần chú 'không sử dụng goto ... không sử dụng goto ...' . Thực tế là nó chỉ là một công cụ trong bộ công cụ của bạn. Giống như bất kỳ công cụ nào, nó có các tình huống hữu ích và các tình huống không hữu ích (hoặc thậm chí có hại). Giống như ai đó đã có một trải nghiệm tồi tệ khi cố gắng nhìn thấy một mảnh gỗ bằng búa, và sau đó tuyên bố 'đừng sử dụng búa bao giờ, cưa tốt hơn nhiều!' . Quét khái quát luôn luôn sai
MattDavey

1

Chiều dài định danh không quan trọng. Như đã nói, những người khác có thể sử dụng Giảm thiểu sản xuất để giảm thời gian tải xuống tập lệnh. Trên thực tế, cần tuân thủ quy ước đặt tên / mã hóa có thể chấp nhận được, đặc biệt vì JavaScript là ngôn ngữ kỳ quặc và từ lâu JavaScript đã bị bỏ qua vì chỉ là một việc để hoàn thành công việc. Nếu bạn đang tìm kiếm một nơi để đặt tên cho quy ước, Google JavaScript Style Guide là một nơi tốt. Nó cho thấy,

  • functionNamesLike This, ví dụ, getCashbackData () {}
  • biếnNamesLike This, ví dụ: var alertInterval = 10;
  • ClassNamesLike This, ví dụ: var CustomerOrder = {getOrderLines: function () {}}
  • EnumNamesLike This, ví dụ: var ColorOfChoice = {White: "#FFFFFF"}
  • methodNamesLike This, vd, var CustomerOrder = {getOrderLine: function () {}}
  • SYMBOLIC_CONSTANTS_LIKE_THIS, ví dụ: var EPOCH_UNIX = "01011970"

Bạn có bất cứ điều gì thêm để thêm sau đó một loạt các liên kết? Ý tôi là bạn thậm chí không giải thích Douglas Crockford là ai.
Ramhound

0

Bực mình bởi triết lý "nhà phát triển mã sạch" (và bây giờ bạn đã biết từ các bài đăng ở trên rằng do việc thu nhỏ kích thước tên biến của bạn sẽ không ảnh hưởng đến hiệu suất) tôi chỉ có thể khuyên:

  1. Tìm IDE tốt nhất cho nhu cầu phát triển cá nhân của bạn có tính năng tự động hoàn thành và tính năng tự động tốt, chẳng hạn như aptana, netbeans, nhật thực (tất cả miễn phí) hoặc bất kỳ sản phẩm thương mại nào (nếu tôi có trò chơi miễn phí, tôi sẽ nhìn vào sản phẩm của JetBrains)
  2. Viết mã của bạn theo cách làm cho bất kỳ bình luận nào là thừa. Điều đó có nghĩa là, thay vì viết

    getXy(e) { return [e.pageX, e.pageY ] }

    điều đó có thể thực sự có nghĩa là bất cứ điều gì (đặc biệt là trong một ngôn ngữ được gõ lỏng lẻo như js;) bạn làm cho mã thể hiện chính nó

    getPageCoordinatesFromEvent(event) { 
        return [event.pageX, event.pageY ];
    }

    Trong một IDE tốt, thông thường bạn sẽ không bao giờ nhập bất kỳ tên biến nào dài hai lần - giây bạn nhập một vài chữ cái và chỉ cần nhấn enter từ tự động hoàn thành. Nếu bạn khăng khăng gõ từng ký tự, một IDE tốt sẽ vẫn nhận ra bạn về một lỗi đánh máy. Đây chỉ là một ví dụ rất hời hợt, do đó tôi rất khuyến nghị (không phải là một hình thức phê bình mà là một khuyến nghị trung thực) rằng bạn

  3. Nhận sách "Mã sạch" của Robert C.Martin và hoặc "Lập trình viên thực dụng" của Hunt / Thomas và không bao giờ tự hỏi mình loại câu hỏi này nữa - bạn sẽ quá bận rộn khi làm việc trên máy chủ tích hợp liên tục để tự động kiểm tra nhàm chán -, & xây dựng các phần của quy trình phát triển (bao gồm giảm thiểu) và tập trung vào phần thú vị, viết mã rõ ràng dễ hiểu, thực hiện công cụ tuyệt vời!

PS Nếu bạn cần tăng tốc với việc phát triển mã javascript tiên tiến, hãy xem cuốn sách của John "Mr. jQuery" Resig về "Kỹ thuật Javascript Pro" ngay sau hoặc cùng với những điều trên.

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.