Quy ước mã hóa trong Javascript: sử dụng khoảng cách giữa các khoảng trống

Question

Theo JSHint, một lập trình viên javascript không nên sử dụng để thêm dấu cách sau dấu ngoặc đầu tiên và trước dấu ngoặc cuối cùng. tôi đã nhìn thấy rất nhiều thư viện javascript tốt mà sử dụng không gian như thế này:

Cách thứ nhất (số lượng nhiều hơn):

(foo === bar) // bad way according JSHint 

thay vì, Cách thứ hai:

(foo === bar) // good way for JSHint 

Thẳng thắn mà nói, tôi thích cách đầu tiên, nhiều không gian hơn, bởi vì nó làm cho mã dễ đọc hơn.

Có lý do chính đáng nào để thích cách thứ hai được JSHint đề xuất không?

Answer 1

Có rất ít nếu có bất kỳ lý do kỹ thuật nào kỹ thuật thích cái kia - lý do gần như hoàn toàn là chủ quan.

Trong trường hợp của tôi, tôi sẽ sử dụng định dạng thứ hai, đơn giản chỉ vì:

1. Nó hoàn toàn có thể đọc được, và sau đại đa số các công ước định dạng trong ngôn ngữ tổ tiên Javascript của

2. JS tập tin tải về kích thước các vấn đề [mặc dù việc rút gọn tất nhiên có thể khắc phục được điều đó]

3. Tôi luôn thực hiện theo cách đó.

Answer 2

Trích dẫn Code Conventions for the JavaScript Programming Language:

Tất cả các nhà khai thác nhị phân trừ . (giai đoạn) và ( (ngoặc trái) và [ (khung bên trái) nên được tách ra từ toán hạng của họ bởi một dấu cách.

và:

Không nên có khoảng trống giữa tên của một hàm và ( (ngoặc trái) của danh sách tham số của nó.

Answer 3

tôi đã sử dụng JSHint để lint đoạn mã này và nó đã không đưa ra một lời khuyên như vậy:

if(window) 
{ 
    var me = 'me'; 
} 

Answer 4

Tôi thích định dạng thứ hai. Tuy nhiên, cũng có những tiêu chuẩn về mã hóa ở đó mà nhấn mạnh vào đầu tiên. Do thực tế javascript thường được truyền dưới dạng nguồn (ví dụ: bất kỳ mã phía máy khách nào), người ta có thể thấy trường hợp hơi mạnh hơn so với các ngôn ngữ khác, nhưng chỉ có một chút.

Tôi tìm thấy chữ thứ hai dễ đọc hơn, bạn tìm thấy chữ đầu tiên dễ đọc hơn, và vì chúng tôi không làm việc trên cùng một mã nên chúng tôi nên dán theo ý muốn. Bạn và tôi cộng tác với nhau thì có lẽ tốt hơn là chúng tôi chọn một người hơn là trộn chúng (ít có thể đọc được hơn), nhưng trong khi đã có những cuộc chiến tranh thánh về những vấn đề như vậy từ lâu trước khi javascript xung quanh (bằng các ngôn ngữ khác với cú pháp tương tự chẳng hạn như C), cả hai đều có giá trị của chúng.

Answer 5

Tôi sử dụng kiểu thứ hai (không có dấu cách), nhưng đôi khi tôi đặt dấu cách nếu có các dấu ngoặc lồng nhau - đặc biệt là các dấu ngoặc vuông lồng nhau vì một số lý do tôi thấy khó đọc hơn các dấu ngoặc cong lồng nhau (dấu ngoặc đơn). Hay nói cách khác, tôi sẽ bắt đầu bất kỳ biểu hiện nào mà không có khoảng trắng, nhưng nếu tôi cảm thấy khó đọc, tôi chèn một vài khoảng trống để so sánh và để chúng ở lại nếu chúng giúp.

Về JS Gợi ý, tôi sẽ không lo lắng - đề xuất cụ thể này là vấn đề quan trọng hơn. Bạn không có khả năng giới thiệu lỗi vì điều này.

Answer 6

Đây là sở thích cá nhân của tôi với lý do tại sao.

Tôi sẽ thảo luận các mục sau trong câu trả lời được chấp nhận, nhưng theo thứ tự ngược lại.

ghi chú một không chọn trên Alnitak, những ý kiến ​​chung cho tất cả chúng ta ...

ghi chú hai ví dụ Mã không được viết dưới dạng khối mã, vì nổi bật cú pháp ngăn cản từ các câu hỏi thực tế chỉ khoảng trắng.

Tôi luôn thực hiện theo cách đó.

Không chỉ là thế này bao giờ là một lý do chính đáng để bảo vệ một thực tế trong chương trình, nó không bao giờ là một lý do chính đáng để bảo vệ BẤT CỨ ý tưởng thay đổi đối lập.

vấn đề JS tập tin tải về kích thước [mặc dù việc rút gọn không tất nhiên khắc phục điều đó]

Kích sẽ luôn luôn quan trọng đối với Bất kỳ file (s) được sẽ được gửi over-the-wire, mà là lý do tại sao chúng tôi có biện pháp rút gọn để xóa khoảng trống không cần thiết. Vì các tệp JS hiện có thể bị giảm, cuộc tranh luận về khoảng trắng trong mã sản xuất là moot.

moot: ít hoặc không có giá trị hoặc ý nghĩa thực tiễn; hoàn toàn học tập. moot definition

Bây giờ chúng tôi chuyển sang vấn đề cốt lõi của câu hỏi này. Những ý tưởng sau đây chỉ là của tôi, và tôi hiểu rằng cuộc tranh luận có thể xảy ra. Tôi không tuyên bố rằng thực hành này là chính xác, chỉ đơn thuần là nó hiện đang chính xác cho tôi. Tôi sẵn sàng thảo luận các lựa chọn thay thế cho ý tưởng này nếu nó được chứng minh là một sự lựa chọn tồi.

Nó hoàn toàn có thể đọc được, và sau đại đa số các công ước định dạng trong ngôn ngữ tổ tiên Javascript của

Có hai phần để tuyên bố này: "Đó là một cách hoàn hảo có thể đọc được"; "và tuân theo phần lớn các quy ước định dạng trong ngôn ngữ tổ tiên của Javascript"

Mục thứ hai có thể bị loại bỏ theo ý tưởng tương tự của Tôi luôn thực hiện theo cách đó.

Vì vậy, chúng ta hãy chỉ tập trung vào phần đầu của báo cáo kết quả Nó hoàn toàn có thể đọc được,"

Đầu tiên, chúng ta hãy thực hiện một vài báo cáo về mã.

1. Ngôn ngữ lập trình là không cho các máy tính để đọc, nhưng để con người đọc được
2. Trong tiếng Anh, chúng ta đọc từ trái sang phải, từ trên xuống dưới,
3. Thực hành được thiết lập sau đây trong ngữ pháp tiếng Anh sẽ dẫn đến việc đọc mã dễ dàng hơn bởi một số lượng lớn các lập trình viên viết mã bằng tiếng Anh.

LƯU Ý: Tôi đang thiết lập trường hợp của tôi chỉ bằng tiếng Anh, nhưng có thể áp dụng chung cho nhiều ngôn ngữ dựa trên latin.

Hãy giảm phát biểu đầu tiên bằng cách loại bỏ các trạng từ hoàn hảo vì nó giả định rằng không thể có sự cải thiện. Thay vào đó, hãy làm việc với những gì còn lại: "Có thể đọc được". Trong thực tế, chúng tôi có thể đi tất cả JS trên đó và tạo biến: "isReadable" dưới dạng boolean.

CÁC CÂU HỎI

Câu hỏi đặt ra cung cấp hai lựa chọn:

(foo === thanh)

(foo === thanh)

Thiếu bất kỳ bối cảnh, chúng tôi có thể lỗi về mặt ngữ pháp tiếng Anh và đi với tùy chọn thứ hai, loại bỏ khoảng trắng. Tuy nhiên, trong cả hai trường hợp "isReadable" sẽ dễ dàng đúng.

Vì vậy, hãy thực hiện việc này một bước xa hơn và loại bỏ tất cả các khoảng trắng ...

(foo === thanh)

thể chúng tôi vẫn khẳng định isReadable được đúng không? Đây là nơi mà một giá trị boolean có thể không áp dụng như vậy nói chung. Chúng ta hãy di chuyển đếnĐồng hồ nổi nơi là không đọc được và là hoàn toàn có thể đọc được.

Trong ba ví dụ trước, chúng tôi có thể giả định rằng chúng tôi sẽ thu thập các giá trị từ 0 - 1 cho mỗi ví dụ riêng lẻ, từ mỗi người chúng tôi hỏi "Trên thang điểm 0 - 1, đánh giá khả năng đọc của văn bản này? "

Bây giờ, hãy thêm một số ngữ cảnh JS vào các ví dụ ...

1. if (foo === bar) {};
2. nếu (foo === bar) {};
3. nếu (foo === bar) {};

Một lần nữa, đây là câu hỏi của chúng tôi: "Trên thang điểm 0 - 1, bạn đánh giá khả năng đọc của văn bản này như thế nào?"

Tôi sẽ đưa ra giả định ở đây là có một số dư để khoảng trắng: khoảng trắng quá nhỏ và phương pháp tiếp cận có thể đọc được 0; quá nhiều khoảng trắng và phương pháp tiếp cận có thể đọc được 0.

ví dụ: "Howareyou?" và "Bạn thế nào?"

Nếu chúng tôi tiếp tục đặt câu hỏi này sau nhiều ví dụ JS, chúng tôi có thể phát hiện giới hạn trung bình về khoảng trắng có thể chấp nhận, có thể gần với các quy tắc ngữ pháp bằng tiếng Anh.

Nhưng trước tiên, hãy chuyển sang ví dụ khác về dấu ngoặc đơn trong JS: hàm!

chức năng làĐọc (một, hai, ba) {};

chức năng inspectString (string) {};

Hai ví dụ chức năng tuân thủ tiêu chuẩn hiện tại không có khoảng trắng giữa() ngoại trừ sau dấu phẩy. Đối số tiếp theo bên dưới không liên quan đến cách khoảng trắng được sử dụng khi khai báo một hàm như các ví dụ ở trên, mà thay vào đó là phần quan trọng nhất của khả năng đọc mã: nơi mã được gọi!

hỏi câu hỏi này liên quan đến mỗi người trong số những ví dụ dưới đây ...

"Trên thang điểm từ 0-1, làm thế nào bạn sẽ đánh giá khả năng đọc văn bản này?"

1. kiểm traString (isReadable (string));

2. surveyString (isReadable (string));

Ví dụ thứ hai làm cho sử dụng quy tắc của riêng tôi

1. khoảng trắng ở giữa dấu ngoặc giữa các từ, nhưng không phải giữa mở hoặc dấu chấm câu đóng cửa. tức là không giống như this examString (isReadable (string)); nhưng giống như this examString (isReadable (string)); hoặc examineString này (isReadable ({string: string, điều: điều});

Nếu chúng ta sử dụng quy tắc ngữ pháp tiếng Anh, sau đó chúng tôi sẽ không gian trước "(" và mã của chúng tôi sẽ là ...

kiểm traString (isReadable (string));

Tôi không ủng hộ thực tiễn này vì nó phá vỡ chức năng gọi ra khỏi hàm, mà nó phải là một phần của.

surveyString(); // Vâng; inspectString(): // không;

Vì chúng tôi là không chính xác phản ánh đúng ngữ pháp tiếng Anh, nhưng ngữ pháp tiếng Anh không nói rằng nghỉ ngơi là cần thiết, thì có lẽ thêm khoảng trắng ở giữa dấu ngoặc đơn có thể đưa chúng ta gần gũi hơn với với isReadable?

Tôi sẽ để lại nó lên đến tất cả các bạn, nhưng hãy nhớ những câu hỏi cơ bản: "Thay đổi này làm cho nó dễ đọc hơn, hoặc ít hơn"

Dưới đây là một số ví dụ khác để hỗ trợ cho trường hợp của tôi.

// Assume functions and variables have already been declared... 

đầu vào $ setViewValue (setToUpperLimit (Giá trị Nhập)).

// Is this how we write a proper English sentence? 

đầu vào $ setViewValue (setToUpperLimit (Giá trị Nhập)). // gần hơn với 1?

config.urls ['pay-me-now']. Initialize (filterSomeValues) .then (magic);

// or 

config.urls [ 'pay-tôi-bây giờ'] .initialize (fitlerSomeValues) .Sau đó (ma thuật); // không gian giống như chúng tôi làm với các nhà khai thác

// Could you imagine no whitespace around operators? 

var hello = 'someting';

if (type === undefined) {};

var string = "I" + "could \ 't" + "read" + "this";

Tôi làm gì ...

Tôi khoảng cách giữa(), {} và []; như trong ví dụ sau

hàm hello (một, hai, ba) {

trở lại một;

}

hello (một);

hello ({key: value, thing1: thing2});

var array = [1, 2, 3, 4];

array.slice (0, 1);

chuỗi ['những thứ'] .together (vàKeepThemĐọc được, với dấu chấm câu vàWhitespace) .but (notTooMuch);

Answer 7

Tiêu chuẩn rất quan trọng và chúng ta nên theo dõi chúng, nhưng không phải là một cách mù quáng. Với tôi, câu hỏi này là về kiểu dáng cú pháp đó nên là tất cả về khả năng đọc.

this.someMethod(toString(value),max(value1,value2),myStream(fileName)); 

this.someMethod(toString(value), max(value1, value2), myStream(fileName)); 

Dòng thứ hai rõ ràng là dễ đọc đối với tôi.

Cuối cùng, nó có thể tùy thuộc vào sở thích cá nhân, nhưng tôi sẽ hỏi những người thích dòng thứ nhất nếu họ thực sự lựa chọn vì họ đã sử dụng nó hoặc vì họ thực sự tin rằng nó dễ đọc hơn.

Nếu đó là điều bạn đã quen, thì việc đầu tư ngắn hạn vào một sự khó chịu nhỏ cho lợi ích lâu dài có thể đáng để bạn chuyển đổi.