มาตรฐานการเข้ารหัสมีความสม่ำเสมอมากเกินไปหรือไม่?

12

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

ตัวอย่างเช่นการเขียนifคำสั่งในหลายบรรทัดกับหนึ่งบรรทัดโดยใช้ตัวดำเนินการ c # ??null-coalescing แทนที่จะพูด== nullจำนวนระยะห่างสำหรับการเยื้องเป็นต้น

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

programming-practices team coding-standards

— Gratzy
แหล่งที่มา

2

สวัสดี Gratzy, Programmers.SE คือไม่กระดานสนทนา ; เราอยู่ที่นี่เพื่อแก้ปัญหาจริงที่คุณอาจต้องเผชิญ คุณมีปัญหาจริงที่คุณพยายามแก้ไขหรือไม่? ถ้าเป็นเช่นนั้นคุณสามารถตั้งคำถามใหม่เพื่อรักษาคำตอบที่สร้างสรรค์และไม่ให้เกิดข้อผิดพลาดในการอภิปรายได้หรือไม่?

1

@Gratzy ที่จะนำมันไปอีกทางหนึ่งในสถานการณ์ที่คุณกำลังเผชิญอยู่เป็นส่วนตัวเกณฑ์ในการตอบที่ถูกต้องคืออะไร?

2

@ Mark Trapp ตามคำถามที่พบบ่อยเหล่านี้เป็นเกณฑ์สำหรับคำถามที่คาดว่าจะเป็นคำถามเชิงอัตนัยทั้งหมด เราจะกำหนดสิ่งนั้นได้อย่างไร คำถามเชิงอัตวิสัย… 1. สร้างแรงบันดาลใจคำตอบที่อธิบาย“ ทำไม” และ“ อย่างไร” 2. มักจะมีคำตอบยาวไม่สั้น 3. มีน้ำเสียงที่สร้างสรรค์ยุติธรรมและเป็นกลาง 4. เชิญแบ่งปันประสบการณ์ผ่านความคิดเห็น 5. ยืนยันว่าความคิดเห็นจะได้รับการสนับสนุนด้วยข้อเท็จจริงและการอ้างอิง 6. เป็นมากกว่าแค่ความสนุกสนานในสังคม ฉันเชื่อว่าคำถามของฉันครอบคลุม 4 ข้อแรกอย่างน้อยที่สุด

— Gratzy

2

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

2

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

— Gratzy

16

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

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

— นิโคล
แหล่งที่มา

1

ฉันเคยไปที่นั่น

+1 พูดในสิ่งที่ฉันตั้งใจ แต่ดีกว่า!

— FrustratedWithFormsDesigner

@ เปียโนนั่นเป็นเหตุผลว่าทำไมคุณถึงเป็นอิสระตอนนี้ :)

— Nicole

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

7

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

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

— FrustratedWithFormsDesigner
แหล่งที่มา

ใช่คุณอาจติดสคริปท์มดอยู่ตรงนั้นก็ได้

— Michael K

1

อย่างน้อย IntelliJ มีตัวเลือกในการฟอร์แมตโค้ดใหม่ก่อนเช็คอิน

— Nicole

3

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

ท้อใจgotoแม้ในภาษาเช่น C โดยไม่ต้อง...trycatch
โดยใช้InitialCapsชื่อ (ในขณะที่ไมโครซอฟท์เอ็มเอฟและ C #) ใน JavaScript initialLowerCaseที่ห้องสมุดมาตรฐานคือ

— dan04
แหล่งที่มา

2

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

— JohnFx
แหล่งที่มา

2

@Tungano ฉันไม่สามารถตกลงเพิ่มเติม ความขัดแย้งของมาตรฐานการเข้ารหัสคือพวกเขามีค่าพอสมควร แต่พวกเขาก็ไม่ควรเถียง

— Charles E. Grant

3

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

— JohnFx

1

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

— Charles E. Grant

1

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

— JohnFx

1

ฉันทำงานกับรหัสจากทีมเยอรมันของเราสองสามโครงการ OSS และรหัสโบราณบางอย่างที่เรามีรวมถึงสิ่งที่เรามีอยู่ในปัจจุบัน บางอันคือ C บาง C ++ บาง C # ดังนั้นฉันต้องทำงานกับสไตล์โค้ดที่แตกต่างกันหลายตลอดเวลา เมื่อคุณทำเช่นนั้นคุณจะรู้ว่าแนวทางสไตล์ที่ได้รับคำสั่งในมาตรฐานเป็นเพียงเล็กน้อย หากฉันสามารถเปลี่ยนจากโครงการหนึ่งเป็นโครงการอื่นได้ฉันสามารถจัดการคนที่ใส่ {} ในที่ต่าง ๆ ได้ นี่คือเหตุผลที่ฉันคิดว่ามาตรฐานเดียวที่คุ้มค่าแก่การสาปแช่งคือกฎข้อ 1 ข้อ: "ความสอดคล้องภายในแต่ละโครงการ"

— gbjbaanb

2

ฉันมี 2 ข้อโต้แย้งเพื่อความเท่าเทียม:

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

— JB King
แหล่งที่มา