แก้ไขข้อคิดเห็นเพื่อใส่อาร์กิวเมนต์ของฟังก์ชันบูลีนที่เป็น“ false” หรือไม่

จากโครงการโอเพนซอร์สบางโครงการฉันรวบรวมสไตล์การเข้ารหัสต่อไปนี้

void someFunction(bool forget);

void ourFunction() {
  someFunction(false /* forget */);
}    

ฉันมีข้อสงสัยเสมอเกี่ยวกับความfalseหมายของที่นี่ มันหมายถึง "ลืม" หรือ "ลืม" อ้างถึงพารามิเตอร์ที่เกี่ยวข้อง (เช่นในกรณีข้างต้น) และ "false" มีไว้เพื่อลบล้างหรือไม่

มีการใช้รูปแบบใดบ่อยที่สุดและวิธีใดดีที่สุด (หรือวิธีที่ดีกว่า) เพื่อหลีกเลี่ยงความคลุมเครือ

ในโค้ดตัวอย่างที่คุณโพสต์ดูเหมือนว่าforgetจะเป็นอาร์กิวเมนต์ธง (ฉันไม่แน่ใจเพราะฟังก์ชั่นนั้นเป็นสมมุติฐานล้วนๆ)

อาร์กิวเมนต์ธงเป็นกลิ่นรหัส พวกเขาระบุว่าฟังก์ชั่นทำมากกว่าหนึ่งอย่างและฟังก์ชั่นที่ดีควรทำสิ่งเดียวเท่านั้น

เพื่อหลีกเลี่ยงอาร์กิวเมนต์แฟล็กแบ่งฟังก์ชันออกเป็นสองฟังก์ชันที่อธิบายความแตกต่างในชื่อฟังก์ชัน

อาร์กิวเมนต์ตั้งค่าสถานะ

serveIceCream(bool lowFat)

ไม่มีอาร์กิวเมนต์ธง

serveTraditionalIceCream()
serveLowFatIceCream()

แก้ไข: เป็นการดีที่คุณไม่จำเป็นต้องใช้ฟังก์ชั่นด้วยพารามิเตอร์ flag เลย มีหลายกรณีตามสิ่งที่ฟาวเลอร์เรียกว่าการใช้งานแบบพันกันซึ่งการแยกฟังก์ชั่นทั้งหมดจะสร้างรหัสซ้ำ อย่างไรก็ตามยิ่งความซับซ้อนของฟังก์ชันแปรผันมากขึ้นเท่าไรก็ยิ่งมีความรุนแรงมากขึ้นเท่านั้น

ในคำพูดของคนธรรมดา:

• false เป็นตัวอักษร
• คุณกำลังผ่านตัวอักษร false
• คุณกำลังบอกที่someFunctionจะไม่ลืม
• คุณกำลังบอกsomeFunctionว่าพารามิเตอร์ที่ลืมคือfalse
• คุณกำลังบอกsomeFunctionให้จำ

ในความคิดของฉันมันจะดีกว่าถ้าฟังก์ชั่นเป็นเช่นนี้:

void someFunction(bool remember);

คุณสามารถเรียกมันว่า

void ourFunction() {
  someFunction(true);
} 

หรือเก็บชื่อเดิมไว้ แต่เปลี่ยนฟังก์ชั่น wrapper ของคุณเป็น

void ourFunctionWithRemember() {
  someFunction(false);
} 

แก้ไข:

ตามที่ @Vorac ระบุให้พยายามใช้คำพูดในเชิงบวกเสมอ การปฏิเสธสองครั้งทำให้เกิดความสับสน

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

การใช้ชื่อตัวแปรเชิงบวก (แนะนำในCode Complete ) อาจเป็นการเปลี่ยนแปลงที่ง่ายที่สุดที่จะทำให้ตัวอย่างข้อมูลนี้อ่านง่ายขึ้นเช่น

void someFunction(boolean remember);

จากนั้นourFunctionกลายเป็น:

void ourFunction() {
    someFunction(true /* remember */);
}

อย่างไรก็ตามการใช้ enum ทำให้การเรียกใช้ฟังก์ชันเข้าใจง่ายยิ่งขึ้นโดยมีค่าใช้จ่ายของรหัสสนับสนุนบางตัว:

public enum RememberFoo {
    REMEMBER,
    FORGET
}

...

void someFunction(RememberFoo remember);

...

void ourFunction() {
    someFunction(RememberFoo.REMEMBER);
}

หากคุณไม่สามารถเปลี่ยนลายเซ็นของsomeFunctionไม่ว่าด้วยเหตุผลใดก็ตามการใช้ตัวแปรชั่วคราวจะทำให้โค้ดอ่านง่ายขึ้นเช่นกันเรียงลำดับของเงื่อนไขที่ทำให้เข้าใจง่ายขึ้นโดยการแนะนำตัวแปรโดยไม่มีเหตุผลอื่นนอกจากทำให้โค้ดง่ายขึ้นในการแยกวิเคราะห์โดยมนุษย์ .

void someFunction(boolean remember);

...

void ourFunction() {
    boolean remember = false;
    someFunction(remember);
}

เปลี่ยนชื่อตัวแปรเพื่อให้ค่าบูลสมเหตุสมผล

นี่เป็นล้านเท่าดีกว่าการเพิ่มความคิดเห็นเพื่ออธิบายการขัดแย้งกับฟังก์ชั่นเพราะชื่อไม่ชัดเจน

สร้างบูลีนแบบโลคัลที่มีชื่อที่สื่อความหมายมากกว่าและกำหนดค่าให้กับมัน วิธีนั้นความหมายจะชัดเจนยิ่งขึ้น

void ourFunction() {
    bool takeAction = false;  /* false means to forget */
    someFunction( takeAction );
}    

หากคุณไม่สามารถเปลี่ยนชื่อตัวแปรได้ความคิดเห็นควรมีความหมายมากกว่านี้เล็กน้อย:

void ourFunction() {
    /* false means that the method should forget what was requested */
    someFunction( false );
}    

มีบทความที่ดีที่กล่าวถึงสถานการณ์ที่แน่นอนนี้เนื่องจากอ้างถึง Qt-Style API ตรงนี้มันเรียกว่าThe Boolean Parameter Trapและมันก็คุ้มค่าที่จะอ่าน

ส่วนสำคัญของมันคือ:

1. การใช้ฟังก์ชั่นมากเกินไปจนไม่ต้องการบูลดีกว่า
2. การใช้ enum (ตามที่ Esailija แนะนำ) ดีที่สุด

นี่คือความคิดเห็นที่แปลกประหลาด

จากมุมมองของคอมไพเลอร์someFunction(false /* forget */);เป็นจริงsomeFunction(false);(ความคิดเห็นถูกปล้น) ดังนั้นทุกสิ่งที่สายจะเป็นสายsomeFunctionแรก (และ) falseอาร์กิวเมนต์ชุด

/* forget */เป็นเพียงชื่อของพารามิเตอร์ อาจไม่มีอะไรมากไปกว่าการเตือนความจำ (และสกปรก) ที่ไม่จำเป็นต้องอยู่ที่นั่นจริงๆ เพียงใช้ชื่อพารามิเตอร์ที่ไม่ชัดเจนและคุณไม่จำเป็นต้องแสดงความคิดเห็นเลย

คำแนะนำอย่างหนึ่งของรหัส Cleanคือการลดจำนวนความคิดเห็นที่ไม่จำเป็น¹ (เพราะพวกเขามีแนวโน้มที่จะเน่า) และการตั้งชื่อฟังก์ชั่นและวิธีการอย่างถูกต้อง

หลังจากนั้นฉันจะลบความคิดเห็น ท้ายที่สุดแล้ว IDEs ที่ทันสมัย ​​(เช่น eclipse) จะปรากฏกล่องพร้อมรหัสเมื่อคุณวางเมาส์ไว้เหนือฟังก์ชัน การดูรหัสควรล้างความคลุมเครือ

^{1 การคอม}เม้นท์รหัสที่ซับซ้อนบางอย่างก็โอเค

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

หากคุณไม่สามารถเปลี่ยน API ได้ฉันเลือกใช้ตัวเลือก 2 ตัว

• เปลี่ยนความคิดเห็นเพื่อให้เป็นจริงเสมอโดยไม่คำนึงถึงรหัส ถ้าคุณเรียกสิ่งนี้เพียงครั้งเดียวนี่เป็นวิธีแก้ปัญหาที่ดี

     someFunction (false / * true = forget, false = Remember * /); `

• ใช้ #defines โดยเฉพาะถ้าคุณโทรหามากกว่าหนึ่งครั้ง

     #define FORGET จริง
     #demine REMEMBER false
     someFunction (จำ);

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

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

ใน C # ฉันใช้พารามิเตอร์ที่มีชื่อเพื่อให้ชัดเจนขึ้น

someFunction(forget: false);

หรือenum:

enum Memory { Remember, Forget };

someFunction(Memory.Forget);

หรือเกินพิกัด:

someFunctionForget();

หรือความแตกต่าง `:

var foo = new Elephantine();

foo.someFunction();

การตั้งชื่อควรแก้ไขความกำกวมสำหรับบูลีนเสมอ ฉันมักจะตั้งชื่อบูลีนบางอย่างเช่น 'isThis' หรือ 'shouldDoThat' เช่น:

void printTree(Tree tree, bool shouldPrintPretty){ ... }

และอื่น ๆ แต่เมื่อคุณอ้างถึงรหัสของคนอื่นมันเป็นการดีที่สุดที่จะแสดงความคิดเห็นเมื่อผ่านค่า