5

Trong sách JS Design Patterns của Stefanov, ông viết "bạn sử dụng một câu lệnh var và khai báo nhiều biến được phân tách bằng dấu phẩy", và sau đó đưa ra ví dụ về mẫu "var đơn" như sau:Nhược điểm của Javascript "mẫu var đơn"

function func() { 
    var a = 1, 
     b = 2, 
     sum = a + b, 
     myobject = {}, 
     i, 
     j; 

Stefanov bổ sung viết:

  • "đó là một thực hành tốt cũng để khởi tạo biến với một giá trị ban đầu tại thời điểm bạn khai báo nó."
  • "Bạn cũng có thể thực hiện một số công việc thực tế tại thời điểm khai báo, như trường hợp có tổng = a + b trong mã trước."

Bây giờ tôi có một số mã như sau, tuyên bố cùng một số biến với mô hình var duy nhất, nhưng làm nhiều hơn một chút "công việc thực tế tại thời điểm khai báo" khá:

var html = '{purchaseQty}<br>FR:&nbsp; {fromLoc}' 
    ,tpl = new Ext.XTemplate(html) 
    ,srcReqLoc = record.get('SRC_REQUEST_LOC').trim() 
    ,srcSupLoc = record.get('SRC_SUP_LOC').trim() 
    ,fromLoc = srcReqLoc ? srcReqLoc : srcSupLoc 
    ,tplCfg = { 
     purchaseQty: purchaseQty 
     ,fromLoc: fromLoc 
    }; 

Những bất lợi khi làm quá nhiều "công việc thực tế tại thời điểm khai báo" là gì? BTW Tôi không coi đây là một bản sao chính xác của Javascript single var pattern. Am I overloading it? vì tôi hỏi về những nhược điểm chung, thay vì những gì có thể sai với mã của tôi.

Tôi nghĩ rằng tôi có thể thấy rằng bất lợi chung sẽ không có khả năng kiểm tra lỗi, ví dụ trong ví dụ của tôi tôi gọi trim() trên chuỗi được mong đợi từ record.get, nhưng nếu undefined được trả về thay thế, "có thể 't gọi phương pháp trên đối tượng không xác định "(hoặc bất cứ điều gì nó là;) sẽ được ném. Ai có thể nghĩ ra bất cứ điều gì khác không?

+0

Đối với vấn đề với 'trim()', bạn luôn có thể viết hàm cắt của riêng bạn để kiểm tra xem những gì được truyền cho nó có phải là một chuỗi hay không. – slebetman

+3

@slebetman - Bạn không cần hàm: '(record.get ('SRC_SUP_LOC') ||" "). Trim()' (giả sử, theo câu hỏi, '.get()' trả về một chuỗi hoặc không xác định/null). – nnnnnn

Trả lời

4

Có ý nghĩa khi khai báo tất cả các biến ở đầu phạm vi, tức là ở đầu hàm hoặc đầu mã toàn cầu. Tôi đồng ý với điều đó.

Theo như cung cấp giá trị ban đầu tại thời điểm khai báo, tôi coi đó là một hướng dẫn. Nói chung nó một kế hoạch tốt, và chắc chắn hoạt động cho các giá trị đơn giản, nhưng đôi khi giá trị ban đầu không được biết cho đến sau một số phép tính phức tạp hơn - trong trường hợp này tôi sẽ không cung cấp một giá trị mặc định. cung cấp một số giá trị. Và đôi khi nó trở nên quá lộn xộn.

Ngoài ra tôi sẽ không cung cấp cho các biến chỉ số vòng lặp một giá trị ban đầu tại thời điểm khai báo - đối với tôi, nó rõ ràng hơn nhiều khi gán giá trị ở đầu vòng lặp.

Như bạn đã chỉ ra, nếu bạn cần xử lý ngoại lệ và do đó, bạn cũng sẽ cần thực hiện điều đó sau trong hàm.

Chỉ cần sử dụng một số ý thức chung: nếu bạn có nhiều biến, bạn có thể tìm thấy câu lệnh var của bạn sẽ không đọc được một chút, vì vậy bạn có thể di chuyển một số khởi tạo về sau trong hàm.

Đối với tôi mã ví dụ của bạn là OK, nhưng nếu bạn cần thêm nhiều thứ vào nó thì sẽ khó đọc vì có nhiều mã trong một khối dày đặc tôi không thể chọn tên biến dễ dàng , nhưng - và đây là, rõ ràng, một vấn đề của hương vị - bạn có thể thêm một số khoảng trắng:

var html  = '{purchaseQty}<br>FR:&nbsp; {fromLoc}' 
    ,tpl  = new Ext.XTemplate(html) 

    ,srcReqLoc = record.get('SRC_REQUEST_LOC').trim() 
    ,srcSupLoc = record.get('SRC_SUP_LOC').trim()  
    ,fromLoc = srcReqLoc ? srcReqLoc : srcSupLoc 

    ,tplCfg = { 
     purchaseQty: purchaseQty 
     ,fromLoc: fromLoc 
    }; 

5

Cá nhân tôi đứng về phía Douglas Crockford (mặc dù tôi đánh giá cao những người không làm điều này), việc tuyên bố các vars ở đầu hàm có ý nghĩa nhất vì JavaScript không có phạm vi chặn.

Từ JSLint site:

Trong các ngôn ngữ với phạm vi khối, nó thường được khuyến cáo rằng biến được khai báo tại trang web sử dụng đầu tiên. Nhưng vì JavaScript không có phạm vi khối, nên khôn ngoan hơn để khai báo tất cả các biến số của hàm ở đầu hàm. Chúng tôi đề nghị sử dụng một câu lệnh var var cho mỗi hàm.

Điểm bất lợi duy nhất là mã của bạn sẽ ít dễ đọc hơn đối với người đến từ nền C hoặc C.

Tôi cảnh giác rằng tôi có thể nghe như một người hâm mộ Crockford ở đây, nhưng tôi muốn recommend this talk on coding style và tại sao đôi khi bộ não của bạn nên thống trị trái tim của bạn với cấu trúc mã (tùy thuộc vào ngôn ngữ).

+2

+1 để đề cập đến "JavaScript, phong cách lập trình và bộ não của bạn". Tôi thích nói chuyện đó :-) –

+1

Đừng lo lắng về âm thanh như một fanboi Crockford với tôi. Tôi đã phát hiện ra JSON bằng cách theo một liên kết trong sig của mình trên comp.lang.javascript * vào năm 2003 * –

0

(Canh thẳng hàng các = dấu hiệu, hoặc các biến nhóm liên quan với dòng trống, hoặc cả hai.) Vì điều này khá cũ và không còn hoàn toàn phù hợp nữa, nên hữu ích khi chỉ ra những người đến đây từ thế giới es6 mà bây giờ chúng ta đã chặn ing. Tuy nhiên, tất cả các biến được khai báo ở trên cùng của phạm vi chức năng, nhưng đôi khi bạn nhận ra khi bạn mã hóa một biến chỉ được sử dụng trong một khối nhất định - trong trường hợp đó được ưu tiên - hoặc thậm chí biến đó đã thắng Không thay đổi tham chiếu trong trường hợp const là ý tưởng tốt nhất.

Các vấn đề liên quan