เราควรส่งเสริมรูปแบบการเขียนโปรแกรมเพื่อประโยชน์ของนักพัฒนาหรือไม่สนับสนุนให้สอดคล้องกัน?

นักพัฒนาเขียนif/elseบล็อกด้วยคำสั่งโค้ดหนึ่งบรรทัดเช่น:

if (condition)
   // Do this one-line code
else
   // Do this one-line code

อีกอย่างใช้วงเล็บปีกกาสำหรับพวกเขาทั้งหมด:

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

ผู้พัฒนาสร้างวัตถุขึ้นมาก่อนแล้วจึงใช้มัน

HelperClass helper = new HelperClass();
helper.DoSomething();

นักพัฒนาซอฟต์แวร์สร้างอินสแตนซ์ใหม่และใช้วัตถุในหนึ่งบรรทัด:

new HelperClass().DoSomething();

นักพัฒนาง่ายขึ้นด้วยอาร์เรย์และforลูป:

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

อีกเขียน:

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

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

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

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

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

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

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

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

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

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

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

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

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

สไตล์ไม่สำคัญ

ที่นั่นฉันพูดมัน

หลังจาก 30 ปีและไซต์ลูกค้านับร้อยและรหัสจาก (ประมาณ) 500 สมาชิก (หรือมากกว่า) สมาชิกทีมในช่วงหลายปีที่ผ่านมาฉันพบว่ารูปแบบนั้นไม่สำคัญ

ไปทำงานก่อน

ทำให้มันใช้ปริมาณทรัพยากรที่เหมาะสม (เช่นโครงสร้างข้อมูลที่เหมาะสมอัลกอริธึมที่เหมาะสม)

เอะอะกับ "สไตล์" หลังจากแก้ไขทุกอย่างแล้ว เอะอะ "สไตล์" ด้วยเครื่องมือเท่านั้นไม่ต้องด้วยตนเอง

มีรูปแบบการเข้ารหัสและมีการเข้ารหัสกลิ่น ไม่ใช่สักครั้งที่ฉันได้พบ:

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

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

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

นี่เป็นผลมาจากข้อผิดพลาดเช่นเดียวกับที่ฉันแสดงไว้ด้านบนซึ่งใช้เวลาสองสามชั่วโมงเพื่อหาหน้าหลักของพอร์ทัลให้หยุด

มีหลายสิ่งที่คุณควรทำเสมอ ไลค์switch():

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

ในขณะเดียวกันให้พิมพ์:

     case 1:
         something();
     case 2:
         something();
     break;

โดยไม่ต้องปิดcaseด้วย//fallthroughถือเป็นข้อผิดพลาด

โดยทั่วไปมีมาตรฐานการเข้ารหัสซึ่งเป็นแนวทางที่สามารถเพิกเฉยตีความอย่างสร้างสรรค์หรือแก้ไขตามความต้องการที่กำหนด และก็มีหัวข้อเรื่อง "กลิ่น" และจะต้องเชื่อฟังอย่างจริงจัง

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

การออกแบบนี้ยังช่วยให้ฉันมอบหมายรายละเอียดการใช้งานให้กับนักพัฒนาอื่น ๆ วิธีนี้พวกเขาเติมลงในช่องว่างแทนที่จะสร้างการออกแบบระบบทั้งหมด

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

คุณสามารถวาดไดอะแกรมที่ค่อนข้างง่ายของการออกแบบระบบโดยรวมของคุณได้หรือไม่? การออกแบบที่อธิบายองค์ประกอบ / เอนทิตีที่เกี่ยวข้องกับนักพัฒนาทีมใหม่ หากคุณทำไม่ได้หรือมีส่วนเกี่ยวข้องสูงการออกแบบก็ไม่เพียงพอ

IMHO มันขึ้นอยู่กับ ...

สองตัวอย่างแรกของคุณไม่ใช่แค่เรื่องของรสนิยมส่วนตัวสำหรับฉัน

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(ไม่มีเครื่องหมายวงเล็บ) = เพิ่มข้อผิดพลาดได้ง่ายขึ้นหากมีการเพิ่มรหัสเพิ่มเติมในภายหลัง:

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

และนี่สะดวกกว่าในการดีบัก:

new HelperClass().DoSomething(GetSomeData()); // etc.

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

สำหรับตัวอย่างที่สามของคุณ (สำหรับ vs foreach) ฉันเห็นว่าเป็นเรื่องของรสนิยม

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

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

ใช้เครื่องมือการทำป้ายมาตรฐานอุตสาหกรรม (เห็นได้ชัดว่าFxCopสำหรับ C #) แม้ว่าจะไม่ใช่จุดจบทั้งหมด แต่ความมั่นคงเป็นสิ่งสำคัญในโครงการขนาดใหญ่ที่มีผู้คนจำนวนมากทำงานอยู่

หากคุณเพียงแค่ทำงานในโครงการของคุณเองหรือทีมเล็ก ๆ หลายคนอาจแย้งว่ามันเกินความจริง ฉันเชื่ออย่างอื่น (ฉันใช้PEP8สำหรับ Python แม้ในโครงการผู้พัฒนาเดี่ยวส่วนบุคคลของฉัน)

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

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

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

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

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

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

if() {}
else() {}

หรือแม้กระทั่ง:

if() {} else () {}

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

Object.method();
Object.method2();

จากนั้นคุณลงเอยด้วยการเรียกเมธอด constuctor ของวัตถุสองครั้งเมื่อมันสามารถหลีกเลี่ยงได้โดยการวางวัตถุลงไปจนสุด

เมื่อพูดถึง foreach และ for loops มันยังเกี่ยวกับ lanauge lanauges บางอย่างที่ช่วยให้คุณควบคุมได้ดีขึ้นเมื่อดูที่ array ใน foreach loop ดังนั้นคุณจึงมีคีย์และค่าในอาร์เรย์ temp และฉันรู้ว่าบาง lanagues มีการเพิ่มประสิทธิภาพบางอย่างเนื่องจากพวกเขาสามารถดูวนรอบและรู้ว่ากี่ครั้งที่จะได้รับการเรียก

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

หลังจากที่ทำงานกับรหัสสมาชิกในทีมคนอื่น ๆ git blameบางครั้งเป็นเพียงไม่กี่เดือนก็เป็นหลักจะเริ่มสายการทำงานในสายการผลิต หลังจากอยู่ที่ บริษัท ของฉันมานานกว่า 10 ปีฉันอาจบอกคุณได้ว่ามีความแม่นยำ 80% + ผู้เขียนชั้นเรียนใดก็ตามในรหัสบรรทัด 500k ของเราเพียงแค่ดูที่นี่

ในขณะที่มี "ramp time" เล็กน้อยเมื่อคุณเริ่มดูโค้ดที่ใช้สไตล์ที่คุณไม่เห็นด้วยสิ่งที่คุณกำลังทำในเวลานั้นกำลังพูดว่า "โอ้นี่ดูเหมือนโค้ดของ John Doe (เพราะ เขาใช้สไตล์ X แต่ไม่ใช่สไตล์ Y เป็นต้น) " และนั่นนำมาซึ่งบริบททั้งหมด ในการประมาณครั้งแรกคุณรู้ว่าจะคาดหวังอะไรจากโค้ดของ John - ส่วนอื่น ๆ ของ codebase ที่เขาเข้าใจดีและส่วนใดที่เขาทำไม่ได้ไม่ว่าเขาจะเป็นกูรู SQL หรือ GUI สามเณร GUI เป็นต้น

การเรียกใช้รหัสของทุกคนผ่านตัวจัดรูปแบบจะดึงข้อมูลนี้ซ่อนอยู่หลัง git blameซึ่งคุณอาจไม่ต้องกังวล

สิ่งนี้ขึ้นอยู่กับประเภทขององค์กรเป็นอย่างมาก

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

มาตรฐานสากลมักจะดีที่สุดสำหรับการทำให้ทุกคนเป็นผู้เล่น B + ฮีโร่ของคุณจะถูกทำลายโดยสิ่งนี้ แต่ถ้าคุณต้องการผู้เล่น A และผู้เล่น B ครึ่งโหลและผู้เล่น C โหลครึ่งถึงเฉลี่ย B + แล้วคุณต้องการมาตรฐานที่สอดคล้องกัน ในตัวอย่างนี้คุณต้องการให้ทุกคนทำสิ่งเดียวกันเพื่อให้ผู้เล่น A สามารถอ่านรหัสของทุกคนได้โดยเร็วที่สุด

พวกคุณหลายคนพูดว่า "แต่เดี๋ยวก่อนทำไมไม่ทำกับผู้เล่น B และ C"

ความจริงก็คือมีฮีโร่ไม่มาก แม้ว่าอาจจะจ่ายเพื่อค้นหาและบำรุงเลี้ยงที่ Google แต่การวางระบบการเรียกเก็บเงินใหม่สำหรับ Ma Bell อาจจะคุ้มค่ากว่ากับทีมหลัง (และถ้าคุณมีฮีโร่จริง ๆ พวกเขา 4 หรือ 5 คนนั้นจะแพงเป็นสองเท่าของจูเนียร์โหล)