Có sử dụng cờ rất thường xuyên trong mã khuyến khích không?

Question

Tôi đã xem qua rất nhiều cờ khi đọc mã của người khác,

if (condition1) 
    var1 = true 
else 
    var1 = false 

sau đó,

if (var1 == true) 
    // do something. 

Có rất nhiều cờ như thế này. Tôi mong muốn biết, đang sử dụng cờ rất thường xuyên trong mã khuyến khích?

Answer 1

này:

if (condition1) 
    var1= true; 
else 
    var1 = false; 

là một mã nặng bằng văn bản cổ điển.
Thay vào đó bạn nên viết:

var1 = condition1; 

Và vâng, cờ rất hữu ích cho việc mã được dễ đọc hơn và có thể hơn, nhanh hơn.

Answer 2

Điều này khá chủ quan và phụ thuộc vào phần còn lại của mã. "Flags" khi bạn gọi họ có vị trí của họ.

Answer 3

Nên dùng nếu condition1 là một thứ khá phức tạp - như if (A && (B || C) && !D) hoặc chứa nhiều chi phí (if (somethingTimeConsumingThatWontChange())) thì lưu trữ kết quả đó thay vì sao chép mã.

Nếu condition1 chỉ là một so sánh đơn giản thì không, tôi sẽ không sử dụng cờ.

Answer 4

Trước hết, mã này nên đọc như thế này:

var1 = condition1; 

if(var1) 

// No need to compare *true* to *true* when you're looking for *true* 

Đối với số lá cờ, có nhiều cách thanh lịch hơn nhánh mã của bạn. Ví dụ, khi sử dụng javascript bạn có thể làm những thứ như thế này:

var methodName = someFunctionThatReturnsAString(); 

// assuming you name the method according to what's returned 
myObject[ methodName ](); 

thay vì

if(someFunctionThatReturnsAString === 'myPreferedMethod'){ 
    myObject.myPreferedMethod(); 
}else{ 
    myObject.theOtherMethod(); 
} 

Nếu bạn đang sử dụng một ngôn ngữ mạnh mẽ gõ, đa hình là bạn của bạn. Tôi nghĩ rằng kỹ thuật này được giới thiệu đến như văn đa hình

Answer 5

Tôi nhớ điều này Replace Temp var with Query method từ sách tái cấu trúc. Tôi nghĩ việc tái cấu trúc này sẽ làm cho mã dễ đọc hơn, nhưng tôi đồng ý rằng nó có thể ảnh hưởng đến hiệu suất khi phương thức truy vấn tốn kém ... (Nhưng, có thể phương thức truy vấn có thể được đặt trong lớp riêng của nó và kết quả có thể được lưu vào lớp đó).

Answer 6

Đây là câu hỏi chung chung một chút. Câu trả lời phụ thuộc vào những gì bạn muốn làm và với ngôn ngữ mà bạn muốn nó làm. Giả sử một bối cảnh OO hơn có thể có cách tiếp cận tốt hơn.

Nếu điều kiện là kết quả của một số trạng thái đối tượng hơn "cờ" nên có thể là thuộc tính của đối tượng. Nếu nó là một điều kiện của ứng dụng đang chạy và bạn có rất nhiều thứ này thì có lẽ bạn nên nghĩ về một máy trạng thái/trạng thái.

Answer 7

Nếu có thể đọc được và thực hiện công việc thì không có gì sai với nó.Chỉ cần sử dụng tiền tố "có" và "là" để làm cho nó dễ đọc hơn:

var $isNewRecord; 
var $hasUpdated; 

if ($isNewRecord) 
{ 
} 

if ($hasUpdated) 
{ 
} 

Answer 8

Điều đó tùy thuộc vào điều kiện và số lần sử dụng. Dù sao, refactoring vào chức năng (tốt nhất là bộ nhớ đệm kết quả nếu điều kiện là chậm để tính toán) có thể cung cấp cho bạn rất nhiều mã dễ đọc hơn.

Hãy xem xét ví dụ này:

def checkCondition(): 
    import __builtin__ as cached 
    try: 
     return cached.conditionValue 
    except NameError: 
     cached.conditionValue = someSlowFunction() 
     return cached.conditionValue 

---

Đối với mã hóa phong cách:

if (condition1) 
    var1= true 
else 
    var1 = false 

Tôi ghét rằng loại mã. Nó phải là một trong hai đơn giản:

var1 = condition1 

hoặc nếu bạn muốn đảm bảo đó là kết quả là boolean:

var1 = bool(condition1) 

---

if (var1 == true)

Again . Kiểu mã hóa không hợp lệ. Đó là:

if (var1) 

Answer 9

Mang trong tâm trí rằng mã mà có thể được readably hơn viết như

var1 = condition1 

, nhiệm vụ này có một số đặc tính hữu ích nếu sử dụng tốt. Một trường hợp sử dụng là đến tên một tính toán phức tạp mà không phá vỡ nó ra thành một chức năng:

user_is_on_fire = condition_that_holds_when_user_is_on_fire 

đó cho phép một để giải thích những gì người ta đang sử dụng các điều kiện để có nghĩa là, mà thường là không rõ ràng từ tình trạng trần.

Nếu đánh giá điều kiện là tốn kém (hoặc có tác dụng phụ), bạn cũng có thể muốn lưu kết quả cục bộ thay vì đánh giá lại điều kiện.

Một số cảnh báo: Cờ được đặt tên kém sẽ có xu hướng làm cho mã ít đọc được hơn. Vì vậy, cờ sẽ được đặt xa nơi chúng được sử dụng. Ngoài ra, thực tế là người ta muốn sử dụng cờ là một mùi mã cho thấy rằng một trong những nên xem xét vi phạm điều kiện ra thành một chức năng.

D'A

Answer 10

Gọi cờ khi bạn làm việc bằng ngôn ngữ trước OO. Chúng rất hữu ích để tham số hóa hành vi của một đoạn mã.

Tuy nhiên, bạn sẽ sớm thấy mã khó theo dõi. Việc đọc/thay đổi/duy trì dễ dàng hơn khi bạn trừu tượng hóa các khác biệt bằng ví dụ: cung cấp tham chiếu đến chức năng có thể thay đổi.

Trong các ngôn ngữ có chức năng là các loại viêm đầu tiên (ví dụ: Javascript, Haskell, Lisp, ...), điều này thật dễ dàng.

Trong ngôn ngữ OO, bạn có thể triển khai một số mẫu thiết kế như Abstract Factory, Strategy/Policy, ...

Quá nhiều thiết bị chuyển mạch mà cá nhân tôi coi là mùi mã.

Answer 11

Cờ rất hữu ích - nhưng cung cấp cho họ tên hợp lý, ví dụ: sử dụng "Có" hoặc tương tự trong tên của họ.

Ví dụ, so sánh:

if(Direction) {/* do something */} 
if(PowerSetting) {/* do something else */} 

với:

if(DirectionIsUp) {/* do something */} 
if(PowerIsOn)  {/* do something else */} 

Answer 12

gì tôi không thích về cờ, là khi chúng được gọi là cờ, không có bình luận nào.

ví dụ

void foo(...){ 

    bool flag; 

    //begin some weird looking code 

    if (something) 
     [...] 
     flag = true; 
} 

Họ cố gắng chống lại các mã redeability. Và người đàn ông nghèo, người phải đọc nó hàng tháng/năm sau khi lập trình ban đầu đã biến mất, sẽ có một số khó khăn thời gian cố gắng để hiểu những gì mục đích của nó ban đầu được.

Tuy nhiên, nếu biến cờ có tên đại diện, thì tôi nghĩ chúng ổn, miễn là được sử dụng một cách khôn ngoan (xem các câu trả lời khác).

Answer 13

Vâng, đó chỉ là mã vô nghĩa ngớ ngẩn.

Bạn có thể đơn giản hóa tất cả những gì xuống:

if (condition1) 
{ 
    // do something 
} 

Answer 14

Dưới đây là quan điểm của tôi. Mã sử ​​dụng cờ:

... 
if (dogIsBarking && smellsBad) { 
    cleanupNeeded = true; 
} 
doOtherStuff(); 
... many lines later 
if (cleanupNeeded) { 
    startCleanup(); 
} 
... 

Rất ô uế. Các lập trình viên chỉ đơn giản là xảy ra để mã trong bất cứ thứ tự tâm trí của mình nói với anh ta. Ông chỉ cần thêm mã tại một nơi ngẫu nhiên để nhắc nhở bản thân rằng dọn dẹp là cần thiết sau này ... Tại sao ông không làm điều này:

... 
doOtherStuff(); 
... many lines later 
if (dogIsBarking && smellsBad) { 
    startCleanup(); 
} 
... 

Và, sau lời khuyên từ Robert Martin (Mã sạch), có thể cấu trúc luận vào phương thức có ý nghĩa hơn:

... 
doSomeStuff(); 
... many lines later 
if (dogTookADump()) { 
    startCleanup(); 
} 
... 
boolean dogTookADump() { 
    return (dogIsBarking && smellsBad); 
} 

Vì vậy, tôi đã thấy rất nhiều quy tắc đơn giản như trên có thể được theo dõi, nhưng mọi người vẫn không thêm lý do và cờ nào! Bây giờ, có những trường hợp hợp pháp, nơi cờ có thể là cần thiết, nhưng đối với hầu hết các trường hợp, họ là một trong những phong cách mà các lập trình viên đang tiếp quản từ quá khứ.