2010-11-06 33 views
5

Nếu bạn ghét các nhà điều hành có điều kiện ternary ở nơi đầu tiên, không có cần phải trả lời;)ternary (Conditional) điều hành và Phong cách

Tôi thường thấy điều này được sử dụng trong song song với một biểu hiện phân công như:

var foo = (some_condition) ? then_code : else_code; 

Tuy nhiên, tôi muốn sử dụng nó để thay thế mã đơn giản như:

if(some_condition) { 
    do_something_simple; 
} else { 
    do_something_else; 
} 

và thay vào đó làm:

(some_condition) ? do_something_simple : do_something_else; 

Tôi có khả năng làm điều này bằng JavaScript. Ở trên nó trả về undefined do đó nó không yêu cầu gán. Tôi thích không gian được lưu nhưng tự hỏi mọi người nghĩ gì về loại hình sử dụng này, một lần nữa, tôi thường chỉ thấy ternary được sử dụng với một bài tập.

EDIT: Tôi đã thấy các câu trả lời ám chỉ đến "ý định ẩn". Mặc dù cổ điển được sử dụng trong các biểu thức, làm thế nào là ẩn mục đích này nữa sau đó sử dụng trong một biểu thức? Đặc biệt là trong một ngôn ngữ năng động, nơi người ta có thể nhìn thấy việc sử dụng các toán tử ternary trên khắp nơi?

+0

Câu hỏi trùng lặp. Vui lòng luôn xem xét các câu hỏi đã được hỏi và trả lời trước đây. Đây là liên kết, xem liệu nó có giúp ích không: http://stackoverflow.com/questions/3622244/full-if-else-statement-vs-conditional-operator –

+2

Mẹo: Lưu ý rằng toán tử ternary này thường được gọi là điều hành có điều kiện. Toán tử "ternary" chỉ là toán tử với 3 toán hạng, do đó từ "ternary". Không có nhiều toán tử bậc ba, nhưng trong các ngôn ngữ có nhiều, toán tử có điều kiện chỉ là một trong số chúng. –

+0

@Mazhar: câu hỏi đó là về cách sử dụng '?:' Theo cách thông thường, được chấp nhận như là một lựa chọn mức biểu thức. Đây là về sự lạm dụng của '?:' Để thực hiện các tác dụng phụ đang hoạt động, để thay thế 'if-else'. Cá nhân tôi ghét thực hành này rất nhiều. – bobince

Trả lời

3

Toán tử điều kiện thường được sử dụng trong biểu thức - biểu thức tạo giá trị - và tốt nhất không được dùng làm thay thế cho câu lệnh 'if/then/else'. Đôi khi được sử dụng, sẽ không có vấn đề cụ thể; được sử dụng một cách có hệ thống, tôi nghĩ nó sẽ che giấu ý định của mã từ độc giả.

+0

vì vậy không có lý do kỹ thuật tại sao nó không thể được sử dụng sau đó. – dewd

+0

Phân biệt giá trị, giữa (1) thành ngữ chức năng của JavaScript, trong đó giá trị khóa của biểu thức điều kiện là chúng ** soạn ** theo cách mà câu lệnh có điều kiện không, và (2) kiểu bắt buộc, trong đó các biểu thức không phải lúc nào cũng được yêu cầu, và các câu lệnh thường đủ. – houthakker

2

Đây là sở thích cá nhân của tôi:

Trong trường hợp này, tôi nghĩ rằng nó rơi vào suy nghĩ "mã được viết cho mọi người đọc, không phải cho máy". Bởi vì hầu hết mọi người không viết if then else theo cách này, điều này có thể gây nhầm lẫn, tăng thời gian để hiểu mã và có thể giới thiệu lỗi - nếu ai đó thấy điều đó và nghĩ, không có nhiệm vụ gì, phải "bị bỏ qua" mã và chúng ta hãy loại bỏ nó, sau đó mã sạch sẽ trở thành giới thiệu lỗi.


Được trích dẫn từ: Chương trình phải được viết để mọi người đọc và chỉ tình cờ cho máy thực thi.

- từ "Cấu trúc và Giải thích chương trình máy tính" bởi Abelson và Sussman

Charlie Martin nói Is Code For Computers or for People?:

Nếu máy tính không chạy nó, nó bị hỏng. Nếu mọi người không đọc được, nó sẽ bị hỏng. Sớm.

Và tôi nghĩ có, mã được viết cho máy để hiểu (và chạy đúng cách) và điều quan trọng là mọi người phải hiểu. (trừ khi nó được viết cố ý khó hiểu để kiếm phí tư vấn, nhưng họ có thể thuê người khác sau hoặc cho dự án tiếp theo hoặc viết khó hiểu về bảo mật công việc nếu mọi người không thể hiểu rõ mã của bạn, họ có thể ' t cháy bạn lo sợ người khác không thể duy trì mã ... có thể có 2 mặt để một điều ... tôi thấy nhiều trường hợp hơn như vậy)

+0

Chà, nếu họ xóa nó theo suy nghĩ thì mã "còn sót lại" có vẻ IMO khá tích cực. Trích dẫn là thú vị nhưng giả định rằng việc sử dụng đề xuất là trong thực tế gây nhầm lẫn cho người đọc của mã. Tuy nhiên, thực tế là nó ít dòng làm cho nó thực sự dễ đọc hơn? Không chắc chắn;) – Rob

+0

hm ... ít dòng không nhất thiết làm cho nó dễ đọc hơn. Ví dụ, một chương trình có 35 dòng có thể trông phức tạp hơn nếu nó là 3 dòng, nhưng một số trong những mã-golf 1-lót có thể rất khó hiểu. –

0

Câu hỏi là ngớ ngẩn vì bạn đang nói về JavaScript cho phép những điều kỳ lạ.

Toán tử điều kiện bậc ba, bằng ngôn ngữ lập trình cổ điển, yêu cầu cả hai trường hợp đều là biểu thức chứ không phải là câu lệnh. Bằng cách này, bạn có thể sử dụng nó để lựa chọn giữa hai biểu thức theo một điều kiện boolean nhưng không phải là một nhánh bình thường nếu/else ..

bằng ngôn ngữ như JavaScript sự khác biệt này biến mất do tuyên bố thực sự trả về giá trị để bạn có thể sử dụng số ba và chỉ cần hủy giá trị undefined được trả về bởi bảng sao kê của bạn.

Theo quan điểm của tôi, nó nằm ở ngôn ngữ lập trình khác, điều này cũng có thể dẫn đến nhầm lẫn nếu bạn tiết kiệm không gian nhưng tôi nghĩ đó là vấn đề ưu tiên. Chỉ cần không quá quen với nó vì chỉ vài ngôn ngữ lập trình cho phép kiểu sử dụng này của toán tử bậc ba!

+0

> ngớ ngẩn - Tôi nghĩ đây chính xác là lý do tôi hỏi nó. Tôi không quen với việc xem nó bằng nhiều ngôn ngữ cổ điển hơn nhưng có, nó được cho phép trong JS. – Rob

0

Toán tử bậc ba là tốt cho các chương trình trưởng thành/ổn định, nhưng không phải trong môi trường thay đổi liên tục. Giả sử bạn phải thêm một số mã phụ vào bất kỳ nhánh nào - nó dễ dàng hơn nhiều khi bạn có cú pháp if/then/else.

+0

Tôi không nghĩ rằng trưởng thành có liên quan gì đến nó. Tôi muốn nghỉ ngơi để tranh luận rằng nó là tốt cho các điều kiện rất đơn giản IMO – Rob

+0

Điều kiện rất đơn giản đó có thể cần thiết để mở rộng tại một số thời điểm bất ngờ. – Thevs

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