it-swarm-vi.com

Kiếm nhiều tiền từ == đúng không?

Có một đồng nghiệp của tôi liên tục viết:

if (someBool == true)

Nó đẩy tôi lên tường! Tôi nên làm cho một vấn đề lớn của nó hoặc chỉ cần bỏ nó?

105
JoelFan

Đó chỉ là mã thừa, không phải là sống hay chết. Tuy nhiên....

Nếu nó xảy ra nhiều, nó có thể là một vấn đề với cách someBool được đặt tên. Một cái tên hay có thể đi một chặng đường dài hướng tới việc loại bỏ nhu cầu về ==true

if(IsSomeCondition)

hoặc là

if(hasCondition)

hoặc là

if(somethingExists)

ví dụ.

126
Robert Harvey

Khi tôi thấy someBool == true, Tôi không thể không cảm thấy như lập trình viên chưa tiếp thu ý tưởng của đánh giá, đó là một thiếu sót khá cơ bản.

Tuy nhiên, quan điểm của tôi bị sai lệch bởi vì tôi đã dành nhiều mùa hè trong chương trình giảng dạy đại học cho trẻ em, những người thường xuyên viết các biểu thức như thế này vì họ thực sự đã không thành thạo bài tập tinh thần để đánh giá một biểu thức. Một khi họ mò mẫm khái niệm, sự dư thừa trở nên rõ ràng.

Đối với một lập trình viên chuyên nghiệp có thẩm quyền khác, điều này có lẽ không phải là trường hợp. Có lẽ đó chỉ là một thói quen xấu mà họ đã phát triển trong những ngày đầu lập trình và chưa bao giờ bị lung lay. Nhưng nó vẫn sẽ làm tôi sợ một chút nếu đó là điều đầu tiên tôi thấy ai đó làm trong một cuộc phỏng vấn.

71
Tim Goodman

Điều đó cũng khiến tôi phát điên, nhưng tôi muốn đề cập đến sự dư thừa cho họ theo cách xây dựng và sau đó bỏ nó ngay cả khi họ không đồng tình.

Hoặc bạn có thể thử phương pháp này:
[.__.] Bạn : Bạn có thể bắt đầu sử dụng quy ước mã sau để đánh giá Booleans không?

if (someBool==true)&&(true==true) {}

Họ : Tại sao chúng ta sẽ làm điều đó? Nửa sau của tuyên bố đó là dư thừa, nó sẽ luôn luôn đánh giá là đúng.

Bạn : George, bạn đúng. Tôi ngớ ngẩn quá. Chúng ta hãy đi với một phiên bản mà không có tất cả sự dư thừa sau đó. Làm thế nào về?

if (someBool) {}
58
JohnFx

Tôi nghĩ rằng, nếu một cái gì đó quá tầm thường là vấn đề lớn nhất của bạn với đồng nghiệp, bạn nên xem mình là người khá may mắn.

45
GrandmasterB

Bạn chắc chắn nên dừng thói quen xấu này. Dịu dàng...

Thật dễ dàng để quên viết hai dấu bằng, biến mã thành:

if (someBool = true)

Trong C # chẳng hạn, điều này sẽ chỉ tạo ra một cảnh báo, không phải là một lỗi. Vì vậy, trừ khi bạn coi các cảnh báo là lỗi, mã sẽ chạy, đặt biến thành đúng và luôn nhập điều kiện.

42
Guffa

Tôi đồng ý với bạn, nhưng tôi sẽ đóng vai người ủng hộ quỷ dữ ở đây:


Tùy thuộc vào ngôn ngữ và tên của biến, x == true là phù hợp:

Xem xét tình huống sau đây trong một ngôn ngữ với kiểu gõ tĩnh và kiểu ép buộc đối với các kiểu tích phân:

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

Ai đó đọc phần mã này có thể không nhận ra ngay lập tức rằng các hành động ALLowed là một biến boolean - nó cũng có thể là một số nguyên, đại diện cho số lượng hành động được phép. Vì vậy, bằng cách thêm == true, rõ ràng x là một boolean và không phải là một số nguyên bị ép buộc thành boolean:

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}
21
Cam

Những gì về bool nullable?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 
15
Steve Wellens

Thông thường, bạn không muốn thực hiện một thỏa thuận lớn từ các quy ước mã hóa trừ khi quy ước nói bằng cách nào đó cản trở dự án theo một cách quan trọng. Tôi đã thấy nhiều cuộc tranh cãi nảy lửa leo thang trên những thứ nhỏ như vùng mã và dấu gạch dưới hàng đầu.

Điều đó đang được nói, tôi thấy không có vấn đề gì với việc thêm == true đến một tuyên bố có điều kiện. Thực tế, tôi có thói quen sử dụng == false trái ngược với dấu chấm than hàng đầu khi kiểm tra các điều kiện tiêu cực. Tôi nghĩ nó dễ đọc hơn.

Nếu có một quy ước được thiết lập, tôi nói hãy tuân theo nó trừ khi có lý do để thay đổi. Tuy nhiên, nó không thực sự đáng để gây ra một mùi hôi thối lớn.

11
Casey

Ack. Tôi là người đó. Sự xấu hổ, xấu hổ. Đó là cách tôi học và đó là cách tôi "tự động định dạng" trong đầu. Lần duy nhất tôi sử dụng cú pháp ưa thích của Joel là khi biến bool có tiền tố động từ như "is." Tôi cần động từ, là "là", "có thể", đã làm "hoặc nếu không tôi cần == để cung cấp động từ" bằng ". Tôi có thể không bao giờ bỏ thói quen đó, vì vậy tôi sẽ hiểu nếu bạn không nói 'xin chào' với tôi trên đường phố.

11
Scott Fletcher

nhắc nhở tôi về "mã điên boolean", nó giống như thế này

if(someBool == true)
   otherBool = false;
else
   otherBool = true

Thay vì:

 otherBool = !someBool
11
Marcelo de Aguiar

Cá nhân, tôi không thích cách nói "không" trong các ngôn ngữ dựa trên C. Dấu chấm than nhỏ đó là quá dễ dàng để bỏ qua.

Do đó tôi viết nó ra đầy đủ:

if (someCondition == false) {

Sau khi đọc nó một lúc, tôi cũng muốn đối xứng với

if (someCondition == true) {

Vì vậy, hãy coi nó là một tạo tác của C bằng cách sử dụng ! thay vì not.

8
user1249

Nó phụ thuộc vào ngôn ngữ, nhưng nó thường là một ý tưởng tồi ...

Trong C, không bao giờ làm điều này. Thật quá dễ dàng để tìm thấy một tình huống trong đó giá trị bạn đang kiểm tra không sai (khác không), nhưng cũng không bằng giá trị đơn được xác định là "đúng".

Trong Ruby, chỉ làm điều này nếu bạn hoàn toàn chắc chắn rằng bạn muốn thất bại với mọi thứ trừ Boolean true.

Trong C++ và các ngôn ngữ tĩnh khác có kiểu bool, nó thừa và có thể dẫn đến lỗi lập trình khi bạn gõ sai = thay vì ==, hoặc lỗi quảng cáo như được đề cập trong các bình luận.

6
AShelly

Bạn nghĩ đó là xấu? Làm thế nào về:

if(someCondition) {
  return true;
} else {
  return false;
}
5
Sverre Rabbelier

Tôi thích

if (bVal)

hoặc là

if (!bVal)

cũng vậy, nhưng tôi sợ rằng việc đưa nó lên sẽ khiến mọi người khó chịu, vì vậy lời khuyên của tôi là hãy quên nó đi. Lấy làm tiếc!

4
grokus

bạn nên nói với anh ta rằng anh ta đang làm sai.

nó là

if (true == someBool) {

}

nếu anh ta quên một người = anh ta đang gặp rắc rối lớn trong phong cách viết của mình.

4
Display Name

Làm thế nào về

if (x == "true")

TẠI SAO IS ĐÓ LÀ MỘT CHIẾN LƯỢC?!

3
atfergs

Trên thực tế, nếu nó là null, việc kiểm tra x == true sẽ là cần thiết. :)

3
Matt Sherman

Tôi viết mã như thế!

Đây là lý do tại sao:

"if bla == true" đọc như một câu, trong đó "if bla" không có trong nhiều trường hợp. Nó chỉ nghe sai, khi đọc mã thực tế.

Ngoài ra trình biên dịch cảnh báo về các bài tập trong các khối if, vì vậy thực sự không có nguy hiểm khi sử dụng == true. (nhầm lẫn với =)

Ngoài ra, những người không viết "== true", sử dụng "! ()" Cho "== false"? Tôi thấy nó thực sự xấu xí. Và nếu bạn sử dụng "== false", thì cũng chỉ nhất quán sử dụng "== true", thay vì có hai cách khác nhau để xác minh sự thật.

3
Ronny Brendel

Hãy nhớ rằng bạn đang làm việc như là một phần của một nhóm, vì vậy bạn cần phải làm việc cùng nhau. "Chơi đẹp với người khác" vẫn là một đặc điểm tính cách quan trọng ngay cả sau khi học tiểu học :)

3
cdkMoose

Nói chung sẽ bỏ qua '== true', nhưng hầu như không đáng để thảo luận về nó trừ khi bạn đưa nó vào tiêu chuẩn mã hóa của nhóm.

2
FinnNk

Mặc dù tôi đồng ý với tư cách là nhà phát triển chủ yếu của C #, tôi không thể nói điều này luôn đúng như vậy. Chẳng hạn, trong Javascript, === sẽ thực hiện kiểu kết hợp. Vì vậy, giả sử var x = thì:

if(x) --> true

trong khi

if (x === true) --> false

Tôi đoán điều đó khác với == kể cả trong JS tôi sẽ không sử dụng if (x == true) nhưng chỉ là một cái gì đó để suy nghĩ.

Kiểu này chạm vào một điểm khác mặc dù đã xuất hiện trong văn phòng của tôi:

bool b = false;

Trong C #, bool b; sẽ là đủ và sẽ vô hiệu hóa b thành false. Tuy nhiên, rõ ràng hơn là viết dòng trên và dù sao cũng nên được trình biên dịch tách ra trong quá trình tối ưu hóa.

Vì vậy, tôi đoán rằng quan điểm của tôi là không phải lúc nào cũng rõ ràng là gì và không phải là thông lệ tốt và rất nhiều trong số đó tập trung vào sở thích cũng như các tính năng/vấn đề ngôn ngữ.

2
statichippo

À đúng, nhưng nếu biến là nullable thì sao? (bool?)

Một số ngôn ngữ (C #) sẽ yêu cầu và bỏ hoặc so sánh với 'true'.

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}
2
Jared G

Người trẻ biết các quy tắc, nhưng người già biết các ngoại lệ;)

Mới nhất C#, nếu bạn đang xử lý một null-able bool, Sau đó bạn phải:

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

Nếu tristate không phải là vấn đề, thì thường không nên có lý do để so sánh một cái gì đó với true/True. Tuy nhiên, trong Python và một số ngôn ngữ khác như C/C++ bạn có thể thực hiện if trên biểu thức không phải là bool. Các ngôn ngữ này có các quy tắc duy nhất để diễn giải các số nguyên, con trỏ, danh sách, v.v ... là đúng hoặc sai. Đôi khi bạn không muốn điều đó. Ví dụ: trong đoạn này Python đoạn:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

Ở đây z nên là True, nhưng z2 nên là False. Bây giờ, một ngôn ngữ Clojure tiếp cận điều này theo một cách khác - có chức năng and không nhất thiết phải đánh giá một bool, nhưng if có thể xử lý điều đó.

Bất kể ngôn ngữ là gì, bất cứ khi nào bạn thấy mình so sánh một cái gì đó với True hoặc False, nó có thể đáng để nhận xét.

2
Job

Mã hóa như vậy cũng đã cọ xát tôi sai cách trước đây. Mặc dù số nhận dạng ví dụ của bạn được đặt tên là "someBool", việc sử dụng kiểu mã hóa đó vô tình vào một biến không được đảm bảo là boolean có thể có hành vi ngoài ý muốn. Nếu giá trị của "someBool" không chính xác là "đúng" hoặc "sai", kết quả sẽ là sai.

Tôi đã gặp một lỗi rất tinh vi trong năm vừa qua gây ra bởi một phong cách mã hóa như vậy rất khó xác định bởi vì đôi mắt của họ phủ lên các cấu trúc như vậy. Bạn sẽ nghĩ, "Làm thế nào nó có thể sai?" Điều tương tự cũng đúng đối với các biểu thức được hiểu rõ như "(var)" hoặc "(! Var)", rằng bạn đọc hoặc mã chúng mà không cần xác minh hành vi của chúng.

Vì vậy, tôi đã giới thiệu một vài tiêu chuẩn mã hóa để giảm sự tồn tại của các lỗi như vậy trong cơ sở mã và khả năng các lỗi tinh vi như vậy sẽ vô tình xuất hiện trong tương lai.

  1. Tất cả các biểu thức phải được ngoặc đơn theo ý định của họ.
  2. Tất cả các bài kiểm tra boolean phải được thể hiện bằng cách phủ định, như "suchBool! = False".

Bằng cách dọn sạch mã không tuân theo kiểu mới, tôi đã xác định và sửa một vài trường hợp lỗi tinh vi như vậy.

1
Huperniketes

Phải sử dụng điều này mọi lúc trong ActionScript 2 (phải thừa nhận là ngôn ngữ chết), bởi vì:

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

Vì vậy, nó hầu như luôn luôn là tốt nhất để được cụ thể.

1
bburbank

Tôi đồng ý. Đây là một công trình dự phòng, đặc biệt là các ngôn ngữ được đánh máy mạnh.

Để thêm một sự lạm dụng khác của booleans, tôi đã tìm thấy kiểu xây dựng này rất nhiều lần trong Javascript, (đặc biệt tại một số hàm quái vật giống như spaghetti, như trong hơn 100 dòng):

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

Dường như, do thiếu một định nghĩa loại nghiêm ngặt trong ngôn ngữ này, một số lập trình viên không muốn phải loay hoay với false|undefined giá trị.

1
Tomas Narros

Tôi có một đồng nghiệp sẽ có một số mã như thế này:

if(something == true)

Và sau đó, đối với một số loại thử nghiệm/gỡ lỗi, anh ta sẽ không muốn gọi khối này để anh ta đổi nó thành:

if(something == true && false)

Và rồi thỉnh thoảng anh sẽ đổi nó thành:

if(false)

Điều tồi tệ nhất là, loại gỡ lỗi này đôi khi đã làm tôi thất vọng và thực sự rất tệ cho các nhà phát triển khác đọc!

1
ingh.am

Tôi muốn nói tính nhất quán là vua trong một cơ sở mã. Vì vậy, bạn nên sử dụng kiểu, đó là chủ yế được sử dụng trong tổ chức của bạn. Cố gắng làm cho phong cách ưa thích của bạn là một phần của hướng dẫn mã hóa công ty chính thức. Nếu nó đã có trong hướng dẫn, chỉ cần làm theo nó.

(Điều đó đã được nói, nó cũng sẽ thực sự làm tôi khó chịu - nhưng có lẽ không đủ để tạo ra một vấn đề lớn từ nó).

0
driis

Tôi không thích đặt thêm == true, nhưng đôi khi tôi vô tình đưa nó vào và không để ý đến nó. Người có thể không nhận thấy và vô tình đặt chúng. Tôi đọc lại mã của mình và đôi khi nhận thấy rằng tôi đã đặt thêm == true để tôi xóa mã đó == true. Đôi khi tôi không nhận thấy điều đó và vui vẻ chào đón ai đó nói với tôi rằng tôi đã đặt nó một cách dư thừa.

0
sange

Đồng nghiệp của tôi được gọi là if a loop. Tôi sống để kể về nó.

0
Daniel Mošmondor

Người ta có thể phát triển thói quen này khi thực hiện nhiều chương trình trong WPF. Nó sử dụng nhiều bool? Các biến (bool nullable) để bạn phải viết if (someBool == true) hoặc if (someBool ?? false)

0
Poma

Hy vọng rằng, bạn đang sử dụng một ngôn ngữ hợp lý, như VB.NET với Option Strict On, không cho phép ép buộc các loại khác đối với Boolean trong câu lệnh If. Sau đó, không cần phải thêm "== true" (hoặc "= True" trong VB), vì trường hợp cưỡng chế không thể xảy ra. Nếu bạn muốn kiểm tra khác không thì hãy viết rõ ràng (ví dụ: "Nếu x <> 0").

0
o. nate

làm thế nào về:

int j = 1;
for (int i=1; i>=j; i++) ...

Đúng, tôi đã nhìn thấy nó.

0
Dave

Đó là một mùi mã cho một nhà phát triển mới làm quen. Họ vẫn chưa thành thạo/nội hóa hóa điều kiện boolean và phải đánh giá rõ ràng với điều kiện đúng hay sai.

0
Chuck Conway

Trong JavaScript, tôi thích if(bool) khi tôi có đủ tài liệu giải thích phương thức mong đợi ... nhưng khi đánh giá của true có thể có nghĩa là biến tồn tại, bằng số 1 hoặc boolean đúng, nó khó khăn hơn.

Gõ mạnh vào JS cũng có nghĩa là kém linh hoạt. Cuộc gọi khó khăn. Ngôn ngữ gõ mạnh, nằm xuống búa. Nếu không, hỏi tại sao anh ta làm điều đó?

Trên thực tế, có câu trả lời của bạn: hỏi anh ta tại sao. Rồi sửa anh.

0
Clint

sử dụng nó như một cơ hội để dạy anh ta anh ấy sẽ tôn trọng bạn hơn nếu bạn làm. bạn sẽ không muốn ai đó làm điều tương tự cho bạn chứ?

0
Rush Frisby

Nghiên cứu cho thấy mã có nhiều dự phòng tương quan mạnh với lỗi. Đây là một bài báo thú vị về vấn đề này (cảnh báo PDF).

0
David Plumpton

So sánh booleans thực sự có thể gây ra vấn đề lớn. Gần đây tôi đã chạy vào một số mã thực tập có nội dung:

if(foo == false && bar == 2) {...}

Bây giờ, điều này có vẻ khá đơn giản, phải không? Chỉ cần đơn giản hóa nó xuống:

if(!foo && bar == 2) {...}

Sai lầm. Trong trường hợp này, thứ tự các thao tác ra lệnh rằng && được đánh giá đầu tiên, có nghĩa là điều này thực sự đánh giá:

if(foo == (false && bar == 2))

cũng được biết đến như là

if(!foo)

Đó là điều bổ sung mà chúng tôi phải kiểm tra, bar == 2, hoàn toàn biến mất. Đó là lý do tại sao tôi sẽ không bao giờ phê duyệt mã đánh giá có chứa someBool == [true|false].

(Bạn có thể thấy cách phát biểu ngược lại, == true||, cũng sẽ gây ra vấn đề.)

0
tghw

Vâng, đây là một loại lập trình tâm trí lập trình. Tất cả thời gian họ xem xét "nếu điều kiện" không tồn tại với biểu thức có ký hiệu =, <,> ... Tôi đã thấy tình huống mọi người thực sự gặp khó khăn như "trả lại chức năng"

if (RowsAffected> 0) {return true; } khác {trả về false; }

Các lập trình viên cần xem mã của họ từ góc độ thời gian thực .. :)

0
Krishna Prasad A

Một vấn đề trong C là có truyền thống sử dụng các giá trị khác 0 và 1 cho booleans.

typedef enum { WHATEVER = 1 << 4 } MyFlags;
if (flags & WHATEVER) {
}

hoặc thậm chí dựa vào -1 là đúng.

Vấn đề là bạn đang viết API:

struct foo { 
  unsigned int bar : 1;
};

void myapi_foo_set_bar(struct foo *foo, int bar) {
   foo->bar = bar;
}

Ở đây nếu thanh không được chuẩn hóa thành 0 hoặc 1 thì nó sẽ không vừa trong bitfield và nó bị vỡ:

myapi_foo_set_bar(foo, flags & WHATEVER); /* broken */

Bạn cũng có thể tìm thấy những cách khác để bool không chính tắc phá vỡ, chẳng hạn như so sánh chúng với TRUE hoặc FALSE như trong câu hỏi!

Dù sao những gì tôi đến xung quanh là nó thường có ý nghĩa để chuẩn hóa một bool:

foo->bar = bar != FALSE;

Đây là một sự kỳ lạ đặc thù C, tất nhiên.

0
Havoc P

Vâng, đó là một vấn đề lớn bởi vì tên của boolean sẽ nói rằng đó là boolean. Nói nếu bạn có đoạn mã này:

bool arrayIsEmpty = array.length == 0;
if (arrayIsEmpty) { ... }

Nó đã dễ đọc nên bạn sẽ không cần == true, ngay cả đối với người hoặc lập trình viên ít có ý thức đánh giá.

0
tia

Các quy ước lập trình không nhất thiết là "đúng" hay "sai". Chúng tồn tại để cung cấp cho chương trình một cấu trúc quen thuộc với những người đọc nó, do đó những sai lầm có thể sẽ nổi bật rõ ràng hơn - thật khó để "nhìn thấy" một vấn đề nếu mọi thứ hơi sai với bạn.

Điều quan trọng là các quy ước phải được xác định rõ ràng và được sự đồng ý của tất cả những người tham gia (ngay cả khi thỏa thuận giống như "Tôi đồng ý sử dụng quy ước này trong khi tôi làm việc ở đây" :), nếu không thì sẽ có hại hơn là có lợi.

Tất nhiên, trường hợp đặc biệt so sánh boolean với true là sai hoàn toàn và phải tránh bằng mọi giá. ;-)

0
Daniel C. Sobral

Tôi viết if (var == false) vì sau khi viết var tôi không cảm thấy muốn quay lại và viết! đằng sau nó. Ngoài ra tôi thích làm thế nào == false làm cho nó trông rõ ràng hơn.

Tuy nhiên == đúng là lạ. Tôi không biết có một điểm để làm cho một vấn đề lớn. Tôi sẽ không trừ khi anh ta đang thúc đẩy người khác sử dụng nó hoặc biến nó thành một tiêu chuẩn mã hóa.

0
user2528

Bạn có thể thử tiếp cận đồng nghiệp của mình với ví dụ sau:

if ((x == 3) == true) {
    ...
}

Anh ta nên nói rằng == true là dư thừa và nên được viết lại thành

if (x == 3) {
    ...
}

từ x == 3 đã là một biểu thức boolean.

Bây giờ trình bày cho anh ấy someBool == true ví dụ, nhưng viết lại một chút:

if ((someBool) == true) {
    ...
}

someBool đã là một boolean, nên so với ví dụ trước, giờ đây rõ ràng là == true là dư thừa trong ví dụ này, quá. Vì vậy, nó nên được viết lại như sau:

if (someBool) {
    ...
}
0
gablin

Buồn cười vì tôi luôn thay thế mã như:

if(foo) {

Với:

if(true == foo) {
if(false == foo) {

Nhưng tôi có thói quen này vì hầu hết thời gian mã tôi làm việc không có tên biến rõ ràng.

0
mhitza

Điều này có thể nhận được một số biệt danh của bạn trong một wad.

Chúng tôi có các phương thức mở rộng cho .IsTrue và .IsFalse cho loại bool.

Vì vậy, chúng tôi viết

if (someBool.IsTrue ())

-hoặc là-

if (someBool.IsFalse ())

Vâng! Và tôi yêu họ. Khi đọc mã, nó trở nên rõ ràng hơn đối với tôi.

0
ElGringoGrande