มีการศึกษาหลักการสไตล์การเข้ารหัสอย่างเข้มงวดทางวิทยาศาสตร์หรือไม่? [ปิด]

หลักการสไตล์การเข้ารหัส - เช่นเดียวกับหลักการทางออกเดียว - เป็นสิ่งที่ดีจริงเหรอ? เสมอหรือบางครั้ง มันแตกต่างกันมากแค่ไหน?

ไม่ว่าความคิดเห็นของคุณจะเป็นคำถามแบบอัตนัย หรือว่าพวกเขา?

มีใครพยายามที่จะทำให้วัตถุประสงค์การศึกษาหลักการสไตล์การเข้ารหัสอย่างเข้มงวดทางวิทยาศาสตร์หรือไม่?

ฉันไม่สามารถจินตนาการได้ว่าทุกคนจะทำการศึกษาแบบ double-blind ของความสามารถในการอ่านได้ แต่อาจเป็นไปได้ที่จะไม่รู้ตัว - ใช้นักเรียนที่ไม่รู้เกี่ยวกับหลักการที่ถูกศึกษาเป็นวิชาและผู้ที่ไม่ใช่โปรแกรมเมอร์

ฉันสะท้อน deadalnix ของความคิดเห็น: อ่านรหัสเสร็จสมบูรณ์ 2 ผู้เขียน (Steve McConnell) กล่าวถึงรูปแบบการเข้ารหัสในเชิงลึกและการอ้างอิงบ่อยครั้งของเอกสารและข้อมูล

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

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

มันเหมือนกันกับรูปแบบการพิมพ์ QWERTY ที่ใช้กันทั่วไป - มันง่ายที่จะพิสูจน์ว่ามันค่อนข้างไม่ดีในแง่ของการยศาสตร์ (คุณคิดว่าตัวอักษรทั้งหมดของคำว่า TYPEWRITER อยู่ในแถวบนสุดด้วยความสะดวกสบายในชีวิตประจำวันของเราหรือไม่?) .

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

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

คำตอบคือไม่แน่นอน! `การแตก 'และ` การปฏิบัติการแบบไม่ดีต่อการเขียนโปรแกรมหรือไม่? เป็นส่วนหนึ่งของคำถามนี้ดังนั้นฉันจะเริ่มต้นด้วยคำตอบที่แก้ไขแทบจะไม่ไปที่ ...

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

มีผลลัพธ์ทางวิทยาศาสตร์คอมพิวเตอร์ที่เรียกว่าลำดับชั้นของโครงสร้างการควบคุมของ Kosaraju ซึ่งมีอายุย้อนไปถึงปี 1973 และได้มีการกล่าวถึงในการเขียนโปรแกรมเชิงโครงสร้างที่มีชื่อเสียงของ Knuth (เพิ่มเติม) เอกสารเกี่ยวกับงบจากปี 1974 สิ่งที่ S. Rao Kosaraju พิสูจน์ในปี 1973 คือ เป็นไปได้ที่จะเขียนโปรแกรมทั้งหมดที่มีการแบ่งหลายระดับความลึกของnลงในโปรแกรมที่มีความลึกแบ่งน้อยกว่าnโดยไม่ต้องแนะนำตัวแปรเสริม แต่สมมุติว่านั่นเป็นเพียงผลลัพธ์ทางทฤษฎีเท่านั้น (เพียงเพิ่มตัวแปรพิเศษสองสามอย่าง! แน่นอนคุณสามารถทำเช่นนั้นเพื่อรู้สึกเป็นกลุ่มกับผู้ใช้ 3K + บน stackexchange ... )

สิ่งที่สำคัญกว่าจากมุมมองด้านวิศวกรรมซอฟต์แวร์คือกระดาษล่าสุดของ Eric S. Roberts ในปี 1995 ชื่อเรื่องการออกจากวนรอบและการเขียนโปรแกรมเชิงโครงสร้าง: เปิดการอภิปรายอีกครั้ง (ดอย: 10.1145 / 199688.199815) โรเบิร์ตส์สรุปการศึกษาเชิงประจักษ์หลายครั้งโดยคนอื่น ๆ ตัวอย่างเช่นเมื่อกลุ่มของนักเรียนประเภท CS101 ถูกขอให้เขียนรหัสสำหรับฟังก์ชั่นที่ใช้การค้นหาตามลำดับในอาร์เรย์ผู้เขียนของการศึกษากล่าวว่าต่อไปนี้เกี่ยวกับนักเรียนที่ใช้ตัวแบ่ง / ส่งคืนเพื่อออกจากลำดับ ค้นหาวนขวาเมื่อพบองค์ประกอบ:

ฉันยังไม่พบคนเดียวที่พยายามใช้โปรแกรมโดยใช้ [ลักษณะนี้] ที่สร้างโซลูชันที่ไม่ถูกต้อง

โรเบิร์ตส์ยังบอกด้วยว่า:

นักเรียนที่พยายามแก้ปัญหาโดยไม่ใช้ผลตอบแทนที่ชัดเจนจาก for for fared น้อยกว่ากันมาก: มีนักเรียนเพียงเจ็ดจาก 42 คนที่พยายามใช้กลยุทธ์นี้เพื่อสร้างโซลูชันที่ถูกต้อง ตัวเลขดังกล่าวแสดงถึงอัตราความสำเร็จน้อยกว่า 20%

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

และมีปัญหาที่ใหญ่กว่าหนึ่งที่นี่นอกเหนือจากคำสั่ง return / break-type ดังนั้นคำถามนี้กว้างกว่าหนึ่งเล็กน้อยเกี่ยวกับการพัก กลไกการจัดการข้อยกเว้นยังเป็นการละเมิดกระบวนทัศน์จุดทางออกเดียวตามบางส่วน

• http://msmvps.com/blogs/peterritchie/archive/2008/03/07/single-entry-single-exit-should-it-still-be-applicable-in-object-oriented-languages.aspx
• http://pragprog.com/magazines/2012-04/the-pragmatic-defense

ดังนั้นโดยพื้นฐานแล้วใครก็ตามที่ถกเถียงกันอยู่ข้างต้นว่าหลักการ singe-exit ยังคงมีประโยชน์ในทุกวันนี้ก็เถียงกับข้อยกเว้นการจัดการกระบวนทัศน์เว้นแต่จะใช้วิธีที่ จำกัด อย่างมากที่อธิบายไว้ในลิงค์สุดท้าย; แนวทางเหล่านั้นโดยทั่วไปจะ จำกัด ข้อยกเว้นทั้งหมดจากฟังก์ชั่นที่จะโยน () เช่นไม่มีการอนุญาตให้ใช้ข้อยกเว้นระหว่างฟังก์ชัน เพลิดเพลินไปกับ Pascal ใหม่ของคุณด้วย C ++ - เช่นเดียวกับไวยากรณ์

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

http://dl.acm.org/citation.cfm?id=1241526

http://www.springerlink.com/content/n82qpt83n8735l7t/

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=661092

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

เป็นหลักการสไตล์การเข้ารหัส - เช่นหลักการออกทางเดียว

ผู้ที่ยังคงสงสัยว่าจะออกทางเดียวหรือหลายทางออกยังคงติดอยู่ในปลายปี 1960 ย้อนกลับไปการอภิปรายดังกล่าวมีความสำคัญเนื่องจากเราอยู่ในช่วงวัยเด็กของโปรแกรมเมอร์ที่มีโครงสร้างและมีค่ายจำนวนมากที่ประกาศว่าการค้นพบที่อยู่เบื้องหลังทฤษฎีโครงสร้างของโปรแกรม

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

สำหรับคำตอบที่เหลือของฉันมันคือทั้งหมดที่เกี่ยวข้อง (สิ่งที่ไม่ได้อยู่ในซอฟต์แวร์?):

• เป็นสิ่งที่ดีจริงเหรอ?

ใช่. เวลาส่วนใหญ่สำหรับเคสทั่วไปโดยมีข้อ จำกัด เฉพาะสำหรับเคสเคสและการสร้างโปรแกรมเฉพาะภาษา

เสมอหรือบางครั้ง

เวลาส่วนใหญ่.

มันแตกต่างกันมากแค่ไหน?

ขึ้นอยู่กับ

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

ในท้ายที่สุดมันเป็นทักษะที่ได้รับจากคน / ชั่วโมงหลังแป้นพิมพ์ บางครั้งมันก็โอเคที่จะมีคำสั่งคืนหลายรายการเช่นที่นี่ (ในบาง Pascal'esque pseudocode):

function foo() : someType
  begin
  if( test1 == true )
  then
    return x;
  end
  doSomethignElseThatShouldnHappenIfTest1IsTrue();
  return somethingElse();
end;

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

บางครั้งมันก็ไม่ได้ (ที่นี่ใช้รหัสเทียม C เหมือน):

switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
   doSomething(); // no return statement yet
}

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

บางทีอัลกอริทึมนั้นถูกต้อง แต่เขียนได้ไม่ดี

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

บางทีมันผิด

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

สมมติว่าข้อมูลโค้ดที่คิดว่าถูกต้อง:

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

2. คำสั่งส่งคืนเดียวเพิ่มความสามารถในการอ่านและความเรียบง่ายของชิ้นส่วนของรหัสหากค่าส่งคืนถูกคำนวณตลอดการดำเนินการของอัลกอริทึมหรือถ้าขั้นตอนในอัลกอริทึมที่รับผิดชอบในการคำนวณสามารถรวมกลุ่มกันในที่ตั้งเดียว .

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

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

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

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

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

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

หนึ่งอาจดูที่ทั้งหมดนี้และแนะนำว่าเมื่อผู้คนต่อสู้กับปัญหาของผลตอบแทนเดียวหรือหลายผลตอบแทนเป็นเพราะ - ไม่ชำนาญ, ความโง่เขลาหรือขาดจรรยาบรรณในการทำงาน - พวกเขาไม่ได้เขียนโค้ดที่สะอาดและมีแนวโน้มที่จะเขียน ฟังก์ชั่นมหึมาที่ไม่สนใจมาตรการ cyclomatic และ halstead อย่างสมบูรณ์