ช่วงเวลาสั้น ๆ ที่ไม่ได้เป็นคุณธรรมอีกต่อไปคืออะไร?

การแก้ไขข้อผิดพลาดเมื่อเร็ว ๆ นี้ทำให้ฉันต้องใช้รหัสที่เขียนโดยสมาชิกในทีมคนอื่นซึ่งฉันพบสิ่งนี้ (เป็น C #)

return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0;

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

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

แน่นอนว่านี่เป็นเรื่องของสไตล์ แต่มีอะไรที่เขียนหรือค้นคว้าเกี่ยวกับการตระหนักถึงจุดที่ความพยายามในการกระชับรหัสหยุดที่มีประโยชน์และกลายเป็นอุปสรรคต่อความเข้าใจ?

_{สาเหตุของการปลดเปลื้องคือ Entity Framework db จำเป็นต้องเก็บสิ่งเหล่านี้เป็นชนิดที่ไม่สามารถใช้ได้ ทศนิยม? ไม่เทียบเท่ากับทศนิยมใน C # และจำเป็นต้องร่าย}

เพื่อตอบคำถามของคุณเกี่ยวกับการวิจัยที่ยังมีอยู่

แต่มีอะไรที่เขียนหรือค้นคว้าเกี่ยวกับการตระหนักถึงจุดที่ความพยายามในการกระชับรหัสหยุดที่มีประโยชน์และกลายเป็นอุปสรรคต่อความเข้าใจ?

ใช่มีการทำงานในพื้นที่นี้

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

ความซับซ้อนของวงจร ÷ Source Lines of Code ( SLOC )

ในตัวอย่างรหัสของคุณอัตราส่วนนี้สูงมากเนื่องจากทุกอย่างถูกบีบอัดไว้ในบรรทัดเดียว

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

ลิงค์

นี่คือการอ้างอิงบางอย่างถ้าคุณมีความสนใจ:

McCabe, T. และ A. Watson (1994), ความซับซ้อนของซอฟต์แวร์ (CrossTalk: วารสารวิศวกรรมซอฟต์แวร์ป้องกัน)

วัตสัน, AH, & McCabe, TJ (1996) การทดสอบแบบมีโครงสร้าง: วิธีการทดสอบโดยใช้การวัดความซับซ้อนของวัฏจักร (NIST Special Publication 500-235) สืบค้น 14 พฤษภาคม 2011 จากเว็บไซต์ McCabe Software: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

Rosenberg, L. , ค้อน, T. , Shaw, J. (1998) ตัวชี้วัดและความน่าเชื่อถือของซอฟต์แวร์ สืบค้นเมื่อ 14 พฤษภาคม 2554 จากเว็บไซต์มหาวิทยาลัยแห่งรัฐ Penn: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.4041&rep=rep1&type=pdf

ความเห็นและการแก้ปัญหาของฉัน

โดยส่วนตัวฉันไม่เคยเห็นคุณค่าของความกะทัดรัดอ่านง่ายเท่านั้น บางครั้งความกะทัดรัดช่วยให้อ่านได้ง่าย แต่บางครั้งก็ไม่เป็นเช่นนั้น สิ่งที่สำคัญกว่าคือการที่คุณกำลังเขียนCode ที่ชัดเจนจริงๆ (ROC)แทนที่จะเป็น Write-Only Code (WOC)

เพื่อความสนุกนี่คือวิธีที่ฉันจะเขียนมันและขอให้สมาชิกในทีมของฉันเขียนมัน:

if ((costIn <= 0) || (costOut <= 0)) return 0;
decimal changeAmount = costOut - costIn;
decimal changePercent = changeAmount / costOut * 100;
return changePercent;

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

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

ในกรณีพิเศษนี้มันจะปลดเปลื้องdecimalซ้ำไปซ้ำมา; มันอาจจะเป็นภาพรวมที่ดีกว่าถ้าจะเขียนใหม่เหมือน:

var decIn = (decimal)CostIn;
var decOut = (decimal)CostOut;
return decIn > 0 && CostOut > 0 ? (decOut - decIn ) / decOut * 100 : 0;
//                  ^ as in the question

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

ในขณะที่ฉันไม่สามารถอ้างอิงงานวิจัยใด ๆ ในเรื่องนี้ได้ฉันขอแนะนำให้ผู้ที่ปลดเปลื้องภายในรหัสของคุณละเมิดหลักการอย่าทำซ้ำตัวเอง สิ่งที่รหัสของคุณดูเหมือนจะพยายามทำคือแปลงcostInและcostOutพิมพ์Decimalแล้วทำการตรวจสอบสติบางอย่างเกี่ยวกับผลลัพธ์ของการแปลงดังกล่าวและการดำเนินการเพิ่มเติมเกี่ยวกับค่าที่แปลงหากการตรวจสอบผ่าน ในความเป็นจริงรหัสของคุณดำเนินการตรวจสอบสติอย่างใดอย่างหนึ่งเกี่ยวกับค่าที่ไม่กลับกันทำให้เกิดความเป็นไปได้ที่ costOut อาจเก็บค่าที่มากกว่าศูนย์ แต่น้อยกว่าครึ่งหนึ่งของขนาดที่ไม่ใช่ศูนย์ที่เล็กที่สุดที่Decimalสามารถเป็นตัวแทนได้ รหัสจะชัดเจนกว่านี้หากกำหนดตัวแปรประเภทDecimalเพื่อเก็บค่าที่แปลงแล้วดำเนินการกับตัวแปรเหล่านั้น

ดูเหมือนอยากรู้ว่าคุณจะสนใจอัตราส่วนของการDecimalแทนcostInและcostOutมากกว่าอัตราส่วนของค่าจริงของcostInและcostOutยกเว้นว่ารหัสนั้นจะใช้การแทนค่าทศนิยมเพื่อจุดประสงค์อื่น หากรหัสกำลังจะใช้ประโยชน์เพิ่มเติมจากการเป็นตัวแทนเหล่านั้นนั่นจะเป็นข้อโต้แย้งเพิ่มเติมสำหรับการสร้างตัวแปรเพื่อเก็บการรับรองเหล่านั้นแทนที่จะมีลำดับการปลดเปลื้องอย่างต่อเนื่องตลอดทั้งรหัส

ฉันดูรหัสนั้นและถามว่า "ราคาจะเป็น 0 (หรือน้อยกว่า) ได้อย่างไร" มีกรณีพิเศษอะไรบ้างที่บ่งบอก? รหัสควรเป็น

bool BothCostsAreValidProducts = (CostIn > 0) && (CostOut > 0);
if (!BothCostsAreValidProducts)
  return NO_PROFIT;
else {
   // that calculation here...
}

ฉันคาดเดาชื่อที่นี่: เปลี่ยนBothCostsAreValidProductsและNO_PROFITตามความเหมาะสม

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

1. เติมเต็มความต้องการทางธุรกิจด้วยปริมาณงานที่น้อยที่สุด

2. หลีกเลี่ยงข้อบกพร่อง

3. อนุญาตให้เราทำการเปลี่ยนแปลงในอนาคตซึ่งยังคงเติมเต็ม 1 และ 2

นี่คือเป้าหมาย หลักการหรือวิธีการออกแบบใด ๆ (ไม่ว่าจะเป็น KISS, YAGNI, TDD, SOLID, หลักฐาน, ระบบประเภท, metaprogramming แบบไดนามิกและอื่น ๆ ) มีคุณธรรมเพียงเท่าที่พวกเขาช่วยให้เราบรรลุเป้าหมายเหล่านี้

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

บรรทัดมีข้อกังวลสามประการ: ทหารรักษาพระองค์ (ปลอกพิเศษ 0), การคัดเลือกนักแสดงและการคำนวณ ข้อกังวลแต่ละข้อนั้นค่อนข้างเรียบง่ายเมื่อแยกออก แต่เนื่องจากมีการรวมกันในการแสดงออกเดียวกันจึงเป็นการยากที่จะติดตาม

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

เนื่องจากCostInถูกส่งก่อนทำการเปรียบเทียบกับ 0 ฉันถือว่ามันเป็นค่าทศนิยม (ถ้ามันเป็น int จะไม่มีเหตุผลที่จะร่าย) แต่ถ้าCostOutเป็นแบบลอยตัวรหัสอาจซ่อนข้อผิดพลาดการหารด้วยศูนย์ที่ไม่ชัดเจนเนื่องจากค่าจุดลอยตัวอาจมีขนาดเล็ก แต่ไม่เป็นศูนย์ แต่เป็นศูนย์เมื่อโยนเป็นทศนิยม (อย่างน้อยฉันเชื่อว่ามันจะเป็นไปได้)

ดังนั้นปัญหาจะไม่สั้นหรือขาดปัญหาปัญหาคือตรรกะซ้ำและ conflation ของความกังวลที่นำไปสู่รหัสยากต่อการบำรุงรักษา

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

ความกะทัดรัดไม่ได้เป็นคุณธรรมเลย การอ่านเป็นคุณธรรม

ความกะทัดรัดสามารถเป็นเครื่องมือในการบรรลุคุณธรรมหรือในตัวอย่างของคุณอาจเป็นเครื่องมือในการบรรลุสิ่งที่ตรงกันข้าม ไม่ว่าจะด้วยวิธีนี้หรืออย่างอื่นก็แทบไม่มีคุณค่าของมัน กฎที่รหัสควร "สั้นที่สุด" สามารถถูกแทนที่ด้วย "เป็นลามกอนาจารที่สุด" เช่นกัน - พวกเขาทั้งหมดมีความหมายเท่า ๆ กันและอาจเป็นอันตรายหากพวกเขาไม่ให้บริการวัตถุประสงค์มากขึ้น

นอกจากนี้โค้ดที่คุณโพสต์ไม่ได้เป็นไปตามกฎของความกะทัดรัด ได้คงที่ได้รับการประกาศที่มี M ต่อท้ายส่วนใหญ่ของที่น่ากลัว(decimal)บรรยากาศอาจจะหลีกเลี่ยงเป็นคอมไพเลอร์จะส่งเสริมเหลือไปint decimalฉันเชื่อว่าคนที่คุณกำลังอธิบายเป็นเพียงการใช้เวลาสั้น ๆ เป็นข้อแก้ตัว ส่วนใหญ่มีแนวโน้มที่จะไม่จงใจ แต่ก็ยัง

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

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

decimal dIn = (decimal)CostIn;
decimal dOut = (decimal)CostOut;
return dIn > 0 && CostOut > 0 ? ((dOut - dIn) / dOut) * 100 : 0;

(แก้ไข: นี่คือรหัสเดียวกับคำตอบอื่น ๆ ดังนั้นคุณไป)

ฉันเป็นแฟนตัวยงของผู้ประกอบการที่สาม? :ดังนั้นฉันจะปล่อยมันไว้

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

return ((decimal)CostIn > 0 && CostOut > 0) ?
       100 * ( (decimal)CostOut - (decimal)CostIn ) / (decimal)CostOut:
       0;

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

สำหรับฉันดูเหมือนว่าปัญหาใหญ่ที่มีความสามารถในการอ่านได้อยู่ที่การจัดรูปแบบที่ไม่ครบถ้วน

ฉันจะเขียนแบบนี้:

return (decimal)CostIn > 0 && CostOut > 0 
            ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 
            : 0;

ขึ้นอยู่กับว่าประเภทของCostInและCostOutเป็นประเภทจุดลอยตัวหรือประเภทที่สำคัญบางส่วนของ casts อาจไม่จำเป็น ซึ่งแตกต่างfloatและค่านิยมที่สำคัญได้รับการส่งเสริมโดยปริยายdoubledecimal

รหัสสามารถเขียนได้อย่างรวดเร็ว แต่โค้ดข้างต้นในโลกของฉันควรเขียนด้วยชื่อตัวแปรที่ดีกว่ามาก

และถ้าฉันอ่านรหัสอย่างถูกต้องแล้วก็พยายามทำการคำนวณขั้นต้น

var totalSales = CostOut;
var totalCost = CostIn;
var profit = (decimal)(CostOut - CostIn);
var grossMargin = 0m; //profit expressed as percentage of totalSales

if(profit > 0)
{
    grossMargin = profit/totalSales*100
}

ฉันสมมติว่า CostIn * CostOut เป็นจำนวนเต็ม
นี่คือวิธีที่ฉันจะเขียนมัน
M (เงิน) เป็นทศนิยม

return CostIn > 0 && CostOut > 0 ? 100M * (CostOut - CostIn) / CostOut : 0M;

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

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

ความกะทัดรัดไม่ได้เป็นคุณธรรมอีกต่อไปเมื่อ

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

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

เห็นได้ชัดว่าข้อผิดพลาดในรหัสแสดงให้เห็นว่ามีปัญหาอื่นกับ Q / A ซึ่งเป็นการกำกับดูแลดังนั้นความจริงที่ว่ามีข้อผิดพลาดที่ไม่ได้ถูกจับได้นั้นเป็นสาเหตุของความกังวล

เมื่อจัดการกับข้อกำหนดที่ไม่สามารถใช้งานได้เช่นโค้ด "readbility" จะต้องมีการกำหนดโดยผู้จัดการฝ่ายพัฒนาและจัดการโดยนักพัฒนานำและเป็นที่เคารพของนักพัฒนาเพื่อให้แน่ใจว่าการใช้งานที่เหมาะสม

พยายามทำให้แน่ใจว่ามีการนำมาตรฐานของรหัสไปปฏิบัติ (มาตรฐานและแบบแผน) เพื่อให้มั่นใจใน "ความสามารถในการอ่าน" และความง่ายในการ "บำรุงรักษา" แต่ถ้าคุณสมบัติคุณภาพเหล่านี้ไม่ได้ถูกกำหนดและบังคับใช้คุณจะต้องจบด้วยรหัสเช่นตัวอย่างด้านบน

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