ทำให้เป็นเรื่องใหญ่ == จริงหรือ

มีเพื่อนร่วมงานของฉันที่เขียนอยู่ตลอดเวลา:

if (someBool == true)

มันทำให้ฉันติดกำแพง! ฉันควรทำเรื่องใหญ่หรือทำหล่น?

เป็นรหัสซ้ำซ้อนไม่ใช่ชีวิตหรือความตาย แต่ ....

ถ้ามันเกิดขึ้นมากมายมันอาจเป็นปัญหากับการsomeBoolตั้งชื่อ ชื่อที่ดีสามารถไปได้ไกลโดยไม่จำเป็นต้องใช้==true

if(IsSomeCondition)

หรือ

if(hasCondition)

หรือ

if(somethingExists)

ตัวอย่างเช่น.

เมื่อฉันเห็นsomeBool == trueฉันไม่สามารถช่วยได้ แต่รู้สึกว่าโปรแกรมเมอร์ไม่ได้ทำให้แนวคิดการประเมินผลเป็นข้อบกพร่องขั้นพื้นฐาน

อย่างไรก็ตามมุมมองของฉันเบ้เพราะฉันใช้เวลาหลายฤดูร้อนในการเขียนโปรแกรมการเรียนการสอนในวิทยาลัยให้กับเด็ก ๆ ที่มักเขียนการแสดงออกเช่นนี้เพราะพวกเขาไม่เข้าใจการออกกำลังกายทางจิตของการประเมินการแสดงออก เมื่อพวกเขาจับกลุ่มแนวคิดความซ้ำซ้อนก็ชัดเจน

สำหรับโปรแกรมเมอร์มืออาชีพที่มีความสามารถเป็นอย่างอื่นอาจไม่ใช่กรณีนี้ อาจเป็นเพียงนิสัยที่ไม่ดีที่พวกเขาพัฒนาในช่วงแรก ๆ ของการเขียนโปรแกรมและไม่เคยสั่นคลอนเลย แต่มันจะทำให้ฉันตกใจเล็กน้อยถ้ามันเป็นสิ่งแรกที่ฉันเห็นใครบางคนทำในการสัมภาษณ์

นั่นทำให้ฉันบ้าเหมือนกัน แต่ฉันจะพูดถึงความซ้ำซ้อนกับพวกเขาด้วยวิธีที่สร้างสรรค์และจากนั้นก็วางมันแม้ว่าพวกเขาจะไม่เห็นด้วยก็ตาม

หรือคุณอาจลองใช้วิธีนี้:
คุณ:คุณสามารถเริ่มใช้ระเบียบรหัสต่อไปนี้สำหรับการประเมิน Booleans ได้หรือไม่?

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

พวกเขา:ทำไมเราจะทำอย่างนั้น? ในช่วงครึ่งหลังของคำแถลงนั้นซ้ำซ้อนมันจะประเมินเป็นจริงเสมอ

คุณ:โดยจอร์จคุณพูดถูก โง่ฉัน ลองไปกับรุ่นที่ไม่มีความซ้ำซ้อนทั้งหมดแล้ว เกี่ยวกับ?

if (someBool) {}

ฉันคิดว่าถ้าสิ่งเล็ก ๆ น้อย ๆ เป็นปัญหาใหญ่ที่สุดของคุณกับเพื่อนร่วมงานของคุณคุณควรพิจารณาตัวเองว่าโชคดีมาก

คุณควรหยุดนิสัยที่ไม่ดีนี้อย่างแน่นอน เบา ๆ ...

มันง่ายที่จะลืมที่จะเขียนเครื่องหมายเท่ากับสองเท่าเปลี่ยนรหัสเป็น:

if (someBool = true)

ใน C # เช่นนี้จะสร้างคำเตือนเท่านั้นไม่ใช่ข้อผิดพลาด ดังนั้นหากคุณปฏิบัติต่อคำเตือนว่าเป็นข้อผิดพลาดรหัสจะทำงานให้ตั้งค่าตัวแปรเป็นจริงและป้อนเงื่อนไข

ฉันเห็นด้วยกับคุณ แต่ฉันจะเล่นผู้สนับสนุนของปีศาจที่นี่:

ขึ้นอยู่กับภาษาและชื่อของตัวแปร x == จริงเหมาะสม:

พิจารณาสถานการณ์ต่อไปนี้ในภาษาที่มีการพิมพ์แบบคงที่และการบีบบังคับประเภทสำหรับประเภทอินทิกรัล:

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

บางคนที่อ่านส่วนนี้ของรหัสอาจไม่เข้าใจทันทีว่าการกระทำที่อนุญาตเป็นตัวแปรบูลีน - อาจเป็นจำนวนเต็มแทนจำนวนการกระทำที่อนุญาต ดังนั้นโดยการเพิ่ม == จริงมันจะกลายเป็นที่ชัดเจนว่า x เป็นบูลีนและไม่ใช่จำนวนเต็มที่ถูกรวมเข้ากับบูลีน:

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

bools nullable เป็นอย่างไร

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

โดยทั่วไปแล้วคุณไม่ต้องการที่จะทำเรื่องใหญ่จากการเขียนโปรแกรมการประชุมเว้นแต่ว่าการประชุมดังกล่าวเป็นอุปสรรคต่อโครงการอย่างมีนัยสำคัญ ฉันได้เห็นการถกเถียงกันอย่างดุเดือดที่ทวีความรุนแรงมากขึ้นเรื่อย ๆ เมื่อเทียบกับสิ่งต่าง ๆ ที่มีขนาดเล็กเท่ากับภูมิภาครหัสและขีดเส้นใต้ชั้นนำ

ที่ถูกกล่าวว่าฉันไม่เห็นปัญหากับการเพิ่ม== trueคำสั่งตามเงื่อนไข ตามความเป็นจริงฉันอยู่ในนิสัยของการใช้== falseซึ่งตรงข้ามกับเครื่องหมายอัศเจรีย์ชั้นนำเมื่อทดสอบเงื่อนไขเชิงลบ ฉันคิดว่ามันอ่านได้มากขึ้น

หากมีการประชุมที่กำหนดไว้ฉันพูดตามถ้าไม่มีเหตุผลที่จะเปลี่ยนแปลง อย่างไรก็ตามมันก็ไม่คุ้มที่จะสร้างปัญหาใหญ่

Ack ฉันเป็นผู้ชายคนนั้น ความอัปยศความอัปยศ มันเป็นวิธีที่ฉันเรียนรู้และเป็นวิธีที่ฉัน "จัดรูปแบบอัตโนมัติ" ในหัวของฉัน ครั้งเดียวที่ฉันใช้ไวยากรณ์ที่ชอบของ Joel คือเมื่อตัวแปร bool มีคำนำหน้ากริยาเหมือน "is." ฉันต้องการคำกริยาไม่ว่าจะเป็น "is" "can," "did" หรืออื่น ๆ ที่ฉันต้องการ == เพื่อให้คำกริยา "เท่ากับ" ฉันอาจไม่เคยหยุดนิสัยแบบนั้นดังนั้นฉันจะเข้าใจถ้าคุณไม่พูดว่า 'สวัสดี' กับฉันบนถนน

เตือนฉันเกี่ยวกับ "รหัสบ้าแบบบูลีน" มันเป็นแบบนี้

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

แทน:

 otherBool = !someBool

โดยส่วนตัวแล้วฉันไม่ชอบวิธีที่จะพูดว่า "ไม่" ในภาษาที่ใช้ภาษา C เครื่องหมายตกใจเล็ก ๆ น้อย ๆ นั้นมองข้ามได้ง่ายเกินไป

ดังนั้นฉันเขียนมันเต็ม:

if (someCondition == false) {

หลังจากอ่านมาระยะหนึ่งผมก็ต้องการความสมมาตรเช่นกัน

if (someCondition == true) {

ดังนั้นคิดว่ามันเป็นสิ่งประดิษฐ์ของ C ใช้แทน!not

มันขึ้นอยู่กับภาษา แต่โดยทั่วไปแล้วมันเป็นความคิดที่ไม่ดี ...

ใน C ไม่เคยทำเช่นนี้ มันง่ายเกินไปที่จะค้นหาสถานการณ์ที่ค่าที่คุณกำลังทดสอบไม่ใช่เท็จ (ไม่ใช่ศูนย์) แต่ก็ไม่เท่ากับค่าเดียวที่กำหนดเป็น "จริง"

ใน Ruby ให้ทำสิ่งนี้เฉพาะเมื่อคุณมั่นใจอย่างแน่นอนว่าคุณต้องการล้มเหลวในทุกสิ่งยกเว้นบูลีนจริง

ใน C ++ และภาษาสแตติกอื่น ๆ ที่มีประเภทบูลมันซ้ำซ้อนและสามารถนำไปสู่ข้อผิดพลาดในการเขียนโปรแกรมเมื่อคุณพิมพ์ผิด=แทนที่จะเป็น==หรือข้อผิดพลาดการส่งเสริมการขายตามที่ระบุไว้ในความคิดเห็น

คุณคิดว่าไม่ดีเหรอ? เกี่ยวกับ:

if(someCondition) {
  return true;
} else {
  return false;
}

ฉันชอบ

if (bVal)

หรือ

if (!bVal)

เหมือนกัน แต่ฉันเกรงว่าการนำขึ้นมาจะฉี่คนออกดังนั้นคำแนะนำของฉันคือลืมมัน ขออภัย!

คุณควรบอกเขาว่าเขาทำผิด

ของมัน

if (true == someBool) {

}

ถ้าเขาลืมไปหนึ่งข้อ = เขามีปัญหาใหญ่ในสไตล์การเขียน

เกี่ยวกับ

if (x == "true")

ทำไมถึงเป็นเงื่อนไข?!

จริง ๆ แล้วถ้ามันเป็นโมฆะการทดสอบสำหรับ x == จริงจะต้อง :)

ฉันเขียนโค้ดแบบนั้น!

นี่คือเหตุผล:

"if bla == true" อ่านเหมือนประโยคโดยที่ "if bla" ไม่ได้มีหลายกรณี มันฟังดูผิดเมื่ออ่านโค้ดจริง

คอมไพเลอร์ยังเตือนเกี่ยวกับการกำหนดถ้าบล็อกดังนั้นจึงไม่มีอันตรายใด ๆ ในการใช้ == จริง (ทำให้สับสนด้วย =)

พวกที่ไม่เขียน "== จริง" ใช้ที่ "! ()" สำหรับ "== false" ด้วยหรือไม่ ฉันคิดว่ามันน่าเกลียดจริงๆ และถ้าคุณใช้ "== false" มันก็สอดคล้องกันมากที่จะใช้ "== จริง" แทนการมีวิธีการตรวจสอบความจริงที่แตกต่างกันสองวิธี

จำไว้ว่าคุณกำลังทำงานเป็นส่วนหนึ่งของทีมดังนั้นคุณต้องทำงานร่วมกัน "เล่นได้ดีกับคนอื่น ๆ " ยังคงเป็นลักษณะบุคลิกภาพที่สำคัญแม้หลังจากโรงเรียนประถม :)

โดยทั่วไปแล้วจะไม่ใส่ '== จริง' แต่แทบจะไม่คุ้มค่าแม้แต่นาทีที่จะพูดคุยจนกว่าคุณจะรวมไว้ในมาตรฐานการเข้ารหัสของทีม

ในขณะที่ฉันเห็นด้วยในฐานะนักพัฒนา C # ส่วนใหญ่ฉันไม่สามารถพูดได้ว่าเป็นเช่นนี้เสมอไป ตัวอย่างเช่นใน Javascript เครื่องหมาย === จะดำเนินการเชื่อมโยงประเภท ดังนั้นสมมติว่าvar x = 3แล้ว:

if(x) --> true

ในขณะที่

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

ฉันเดาว่ามันแตกต่างจาก == ตั้งแต่ใน JS ฉันจะไม่ใช้ถ้า (x == จริง)แต่เป็นอะไรที่คิด

การสัมผัสเช่นนี้ในอีกจุดหนึ่งซึ่งเกิดขึ้นในสำนักงานของฉัน:

bool b = false;

ใน C #, bool b; จะเพียงพอและจะ initalize ขการเท็จ อย่างไรก็ตามมีความชัดเจนมากขึ้นในการเขียนบรรทัดด้านบนและควรเรียบเรียงโดยคอมไพเลอร์ในระหว่างการปรับให้เหมาะสม

ดังนั้นฉันจึงคิดว่าประเด็นของฉันคือมันไม่ชัดเจนเสมอไปว่าอะไรคืออะไรและไม่ใช่การฝึกฝนที่ดีและมีหลายสิ่งที่ทำให้ฉันพึงพอใจเช่นเดียวกับคุณสมบัติ / ภาษา

อ่าใช่ แต่ถ้าตัวแปรเป็นโมฆะ? (บูล?)

บางภาษา (C #) จะต้องใช้และคัดลอกหรือเปรียบเทียบกับ 'จริง'

bool? isAccepted = true;

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

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

หนุ่มรู้กฎ แต่เก่ารู้ข้อยกเว้น;)

ในล่าสุดC#หากคุณกำลังจัดการกับ a null-able boolแล้วคุณจะต้อง:

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.
}

หาก tristate ไม่ได้เป็นปัญหาแล้วมักจะมีไม่ควรมีเหตุผลที่จะเปรียบเทียบบางสิ่งบางอย่างไป/true Trueอย่างไรก็ตามในPythonและอีกหลายภาษาเช่นC/C++คุณสามารถดำเนินการifในการแสดงออกที่ไม่ใช่บูล ภาษาเหล่านี้มีกฎเฉพาะสำหรับการตีความจำนวนเต็มพอยน์เตอร์รายการ ฯลฯ ว่าเป็นจริงหรือเท็จ บางครั้งคุณไม่ต้องการที่ ตัวอย่างเช่นใน Python ตัวอย่างนี้:

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

นี่zควรจะเป็นTrueแต่ควรจะเป็นz2 Falseทีนี้Clojureภาษาเข้าใกล้สิ่งนี้ในอีกทางหนึ่ง - andฟังก์ชั่นไม่จำเป็นต้องประเมินถึง a boolแต่ifสามารถจัดการได้

ไม่ว่าจะใช้ภาษาใดเมื่อใดก็ตามที่คุณพบว่าตัวเองเปรียบเทียบอะไรกับมันTrueหรือFalseมันอาจจะคุ้มค่าที่จะแสดงความคิดเห็น

การเข้ารหัสเช่นนั้นจะทำให้ฉันผิดไปก่อน แม้ว่าตัวระบุตัวอย่างของคุณชื่อ "someBool" การใช้รูปแบบการเข้ารหัสนั้นโดยไม่ตั้งใจในตัวแปรที่ไม่รับประกันว่าจะเป็นบูลีนอาจมีพฤติกรรมที่ไม่ได้ตั้งใจ หากค่าของ "someBool" ไม่ตรงกับ "true" หรือ "false" ผลลัพธ์จะเป็นเท็จ

ฉันพบข้อผิดพลาดที่ลึกซึ้งมากในปีที่ผ่านมาซึ่งเกิดจากรูปแบบการเข้ารหัสซึ่งยากที่จะระบุได้ คุณคิดว่า "มันจะผิดอย่างไร" สิ่งเดียวกันถือเป็นจริงสำหรับนิพจน์ที่เข้าใจดีเช่น "(var)" หรือ "(! var)" ที่คุณอ่านหรือเขียนโค้ดโดยไม่ตรวจสอบพฤติกรรมของพวกเขา

ดังนั้นฉันจึงแนะนำมาตรฐานการเขียนโค้ดสองสามข้อเพื่อลดการมีอยู่ของข้อบกพร่องดังกล่าวใน codebase และโอกาสที่ข้อผิดพลาดที่บอบบางเหล่านี้จะคืบคลานไปโดยบังเอิญในบางครั้งในอนาคต

1. การแสดงออกทั้งหมดจะต้องถูกวงเล็บตามความตั้งใจของพวกเขา
2. การทดสอบบูลีนทั้งหมดจะต้องแสดงในเชิงลบเช่น "suchBool! = false"

การล้างโค้ดไม่สอดคล้องกับรูปแบบใหม่ฉันได้ระบุและแก้ไขอินสแตนซ์ของข้อบกพร่องที่ละเอียดอ่อนอีกสองสามรายการ

ต้องใช้สิ่งนี้ตลอดเวลาใน ActionScript 2 (ตอนนี้ยอมรับว่าเป็นภาษาที่ตายแล้ว) เพราะ:

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)
{
}

ดังนั้นจึงเป็นการดีที่สุดที่จะเจาะจง

ฉันเห็นด้วย. มันเป็นโครงสร้างที่ซ้ำซ้อนโดยเฉพาะอย่างยิ่งในภาษาที่พิมพ์ได้ดี

เพื่อเพิ่มการใช้งานบูลีนในทางที่ผิดฉันได้พบการสร้างแบบนี้มาหลายครั้งใน Javascript (โดยเฉพาะอย่างยิ่งในฟังก์ชั่นมอนสเตอร์ที่มีลักษณะเหมือนปาเก็ตตี้อย่างเช่นใน 100+ บรรทัด):

//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
}

ดูเหมือนว่าเนื่องจากการขาดคำจำกัดความประเภทที่เข้มงวดในภาษานี้โปรแกรมเมอร์บางคนไม่ต้องการยุ่งกับfalse|undefinedค่า

ฉันมีเพื่อนร่วมงานที่จะมีรหัสเช่นนี้:

if(something == true)

จากนั้นสำหรับการทดสอบ / การดีบักบางประเภทเขาจะไม่เรียกบล็อกนี้ดังนั้นเขาจะเปลี่ยนเป็น:

if(something == true && false)

แล้วบางครั้งเขาก็เปลี่ยนเป็น:

if(false)

สิ่งที่แย่ที่สุดคือการดีบั๊กประเภทนี้ทำให้ฉันรู้สึกแย่ในบางโอกาส

ฉันจะบอกว่ามั่นคงเป็นกษัตริย์ในรหัสฐาน ดังนั้นคุณควรใช้สไตล์ที่ส่วนใหญ่ใช้ในองค์กรของคุณ พยายามทำให้สไตล์ที่คุณต้องการเป็นส่วนหนึ่งของแนวทางการเข้ารหัสของ บริษัท อย่างเป็นทางการ หากมีอยู่แล้วในหลักเกณฑ์เพียงทำตาม

(ที่ถูกกล่าวว่ามันจะรบกวนฉันจริง ๆ - แต่อาจไม่เพียงพอที่จะทำเรื่องใหญ่จากมัน)

ฉันไม่ต้องการวาง == จริง แต่บางครั้งฉันก็ใส่มันเข้าไปโดยไม่ตั้งใจ บุคคลนั้นอาจไม่ได้สังเกตและนำไปวางโดยไม่ตั้งใจ ฉันอ่านซ้ำรหัสของฉันและบางครั้งสังเกตว่าฉันวาง == จริงไว้ดังนั้นฉันจึงลบ == จริง บางครั้งฉันไม่สังเกตเห็นมันและยินดีต้อนรับใครบางคนอย่างมีความสุขบอกฉันว่าฉันวางมันซ้ำซ้อน

เกี่ยวกับ:

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

ใช่ฉันเห็นแล้ว