2016-03-12 23 views
7

Đọc qua Invoking a function without parentheses nó được ghi nhiều lần trong các ý kiến ​​và câu trả lời để không sử dụng mã như vậy trong quá trình sản xuất. Làm ơn đi, tại sao?Tại sao việc sử dụng hàm không có dấu ngoặc đơn trong sản xuất là xấu?

Tôi là người mới bắt đầu ở JavaScript như bạn có thể đoán từ câu hỏi. Nếu ai đó có thể cụm từ câu trả lời của họ trong điều khoản của giáo dân đó sẽ là tuyệt vời, mặc dù xin vui lòng truy cập cho các folks JS có kinh nghiệm trong số bạn có thể cần một chi tiết hơn và kỹ thuật trả lời chi tiết.

Ví dụ về những gì có thể hoặc không ổn với việc sử dụng các hàm không có dấu ngoặc đơn trong sản xuất sẽ là một bổ sung tuyệt vời cho câu trả lời.

Dưới đây là mã ví dụ về hàm gọi mà không có dấu ngoặc đơn được lấy từ câu trả lời cho câu hỏi đó.

var h = { 
    get ello() { 
    alert("World"); 
    } 
} 

Chạy kịch bản này chỉ với:

h.ello // Fires up alert "world" 

hoặc

var h = { 
    set ello (what) { 
    alert("Hello " + what); 
    } 
} 

h.ello = "world" // Fires up alert "Hello world" 
+3

Phù hợp hơn cho trang web [programmers.se]. – JJJ

+3

Nếu bạn cố tình tạo các hàm không có dấu ngoặc đơn chỉ vì mục đích thực hiện nó, thì đừng. Tuy nhiên, nếu bạn có lý do hợp lệ, tôi không thấy lý do gì * không *. – Hatchet

+2

Getters và setters được cho là * chỉ * nhận và đặt giá trị, nhưng điểm của chúng là mã gọi sử dụng chúng như thể chúng là các thuộc tính thuần túy. – nnnnnn

Trả lời

7

Nó không thực sự quan trọng cho dù đó là trong sản xuất hay không.

Đó là vì nó không giống như cuộc gọi chức năng và điều đó gây nhầm lẫn cho các nhà phát triển khác.

Hãy tưởng tượng việc theo dõi hành vi phức tạp trong một ứng dụng lớn có khó khăn như thế nào khi bất kỳ quyền truy cập và chuyển nhượng thuộc tính nào có thể gọi ra một số mã tùy ý.

Mặc dù có sử dụng hợp lệ cho getters, setters và cuối cùng proxy, chúng phù hợp với hành vi rất cụ thể trong API bề mặt nhỏ. Họ có lẽ không bao giờ nên được sử dụng như một kỹ thuật lập trình chung.

+3

'... gây nhầm lẫn cho các nhà phát triển khác.' - thật sự như thế nào. Bảo trì là thời gian và do đó tiền! – pasty

+3

Tôi đồng ý với Dan - Xem lại mã mà bạn đã viết một hoặc hai năm trước đây có thể chứng minh một thách thức khi luồng chương trình ít rõ ràng hơn. Nó có thể được thực hiện khó khăn hơn cho người khác để hỗ trợ mã của bạn. Lợi thế về hiệu năng có thể không đáng kể, nhưng nhức đầu có thể gây phiền toái khi bạn có các vòng lặp lồng nhau bên trong các hàm và cố gắng triển khai một tính năng bổ sung mà không phá vỡ chức năng hiện có. –

+1

Mã chúng tôi viết ngày hôm nay có thể được xem xét và duy trì bởi các nhà phát triển khác, vì vậy, tại sao không viết nó rõ ràng và dễ đọc để làm cho công việc của họ dễ dàng hơn? Hãy bắt đầu suy nghĩ cho người khác! –

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