รูปแบบการเข้ารหัสในองค์กรเป็นตัวเลือกหรือไม่


30

เอกสารสไตล์การเขียนโปรแกรมนี้มีกฎทั่วไปที่ระบุว่า:

กฎอาจถูกละเมิดหากมีการคัดค้านอย่างรุนแรงต่อพวกเขา

สิ่งนี้ขัดแย้งกับวิธีที่ฉันคิดและมีหลายบทความที่บอกว่ารูปแบบการเข้ารหัสนั้นสำคัญจริง ๆ เช่นนี้พูดว่า:

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

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


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

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

แต่ถ้าคำพูดนั้นถูกต้องแล้วการใช้เอกสารสไตล์การเข้ารหัสคืออะไรถ้าใครสามารถทำอะไรก็ได้ที่พวกเขาต้องการ


คำตอบที่ชัดเจนคือมันขึ้นอยู่กับ คำตอบทั้งหมดด้านล่างเหมาะสำหรับทีมต่าง ๆ ใน บริษัท ต่าง ๆ ที่มีวัฒนธรรมที่แตกต่างกัน สิ่งที่คุณเสนอควรเหมาะสมกับสิ่งที่ทีมจะทำ - และคุณควรมีความคิดเกี่ยวกับเรื่องนี้เพราะแน่นอนว่าคุณจะต้องพูดคุยกันอย่างไม่เป็นทางการกับสมาชิกในทีมไม่ว่าจะเป็นรายบุคคลหรือเป็นกลุ่มย่อย โดยส่วนตัวแล้วฉันชอบก) อะไรก็ตามที่ฉันสามารถตั้งค่าตัวเลือกสำหรับใน Emacs, Visual Studio และ IntelliJ IDEA และ b) ไม่มีแท็บยาก ๆ ในไฟล์ภายใต้สถานการณ์ใด ๆ ! สำหรับทุกอย่างไม่ว่าอะไรก็ตามที่ทีมต้องการก็โอเค
davidbak

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

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

"กฎอาจถูกละเมิดหากมีการคัดค้านอย่างรุนแรงต่อพวกเขา" บางครั้งเป็นการพิจารณาทางการเมือง: ระยะที่ 1 เลือกเข้าร่วม หากไม่มีผู้ร่วมงานอาวุโสในโรงเรียนเก่าอาจฆ่าความคิดเกี่ยวกับมาตรฐานรหัสได้อย่างสมบูรณ์
brian_o

คำตอบ:


12

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

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

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

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

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

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

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

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


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

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


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

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


ให้ใช้วิธีนี้: ทีมของเรามีขนาดเล็กและกระบวนการของเราไม่ได้รวมใครเลยเหนือกว่าหัวหน้าของฉัน (ซึ่งเป็นเพียงหัวหน้าทีม) ดังนั้นเกมอย่างที่คุณอธิบายไว้ข้างต้นจะไม่เกิดขึ้น
BЈовић

@BЈовићในกรณีที่วิธีการท้าทาย / การแก้ปัญหามีลักษณะเป็นผู้ชนะที่ชัดเจน
gnat

53

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

ดูเหมือนว่าคำพูดในคำถามของคุณจะช่วยให้นักพัฒนาซอฟต์แวร์เพียงแค่พูดว่า "ฉันจะไม่ใช้สไตล์นี้เพราะฉันไม่ชอบ"

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

ฉันยอมรับว่าเอกสารสไตล์ที่มีคำสั่งดังกล่าวอาจไม่มีจุดหมาย

อย่างไรก็ตามมีความยืดหยุ่นในการปฏิบัติตามแนวทางสไตล์ที่แนะนำ:

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

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


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

1
การตรวจสอบ nitpick สไตล์อัตโนมัติอาจมีประโยชน์: แต่ถ้ารวมกับปุ่มง่าย ๆ ที่จะใช้การเปลี่ยนแปลงที่แนะนำทั้งหมดและวิธีที่จะพูดว่า "ไม่ฉันทำผิดกฎนั้นด้วยเหตุผล" ขึ้นอยู่กับระดับของกระบวนการหลังอาจเป็นสิ่งที่ต้องมีการพิสูจน์ในการตรวจสอบรหัส / ฯลฯ
Dan Neely

1
การยึดมั่นในสไตล์ของรหัสเป็นสิ่งสำคัญสำหรับ บริษัท ของฉันเรามี PyLint บังคับใช้มาตรฐาน PEP8 ในรหัสของเราซึ่งเป็นส่วนหนึ่งของขั้นตอนการสร้างของเรา ความมุ่งมั่นที่ลดความสมบูรณ์ของรหัสนั้นถูกปฏิเสธโดยอัตโนมัติ
sethmlarson

1
ตรวจสอบกฎให้เพียงพอเพื่อให้ได้ผลลัพธ์ที่คุณต้องการ ละเว้นอัปเดตหรือสละสิทธิ์ใด ๆ ที่ทำให้เกิดปัญหา ใช้สามัญสำนึกในปริมาณที่เหมาะสมเพื่อแลกเปลี่ยนความสุขและผลผลิต
Sean Houlihane

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

13

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

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

จำไว้ว่าทุกอย่างและฉันเครียดทุกอย่างตั้งแต่การเขียนโปรแกรม OO ไปจนถึงกระบวนทัศน์การทำงานไปจนถึงโมเดลการทำงานพร้อมกันที่หลากหลายมีเหตุผลเพียงประการเดียวที่ช่วยให้ผู้คนจัดการกับความซับซ้อน

คนโง่ ๆ สามารถเขียนโค้ดที่คอมพิวเตอร์สามารถเข้าใจได้ โปรแกรมเมอร์ที่ดีเขียนโค้ดที่มนุษย์เข้าใจได้ - Martin Fowler, 2008


คำตอบของคุณไม่ชัดเจนใช่หรือไม่ใช่ ดังนั้นคุณจะบอกว่ามันเป็นตัวเลือกจริงเหรอ? พร้อมพักผ่อน - ฉันเห็นด้วย
BЈовић

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

3
@ BЈовићสิ่งที่นักพูดพูดถึงก็คือคุณมีสมาธิผิด กฎไม่ใช่เวทมนตร์ คุณจะไม่ทำให้ทุกอย่างดีขึ้นอย่างน่าอัศจรรย์โดยยึดมั่นกับกฎอย่างเคร่งครัด ดังนั้นคุณต้องคิดว่า "กฎเหล่านี้คืออะไรที่ควรจะทำให้สำเร็จ" แทนและคุณมุ่งสู่เป้าหมายนั้นแทน กฎบอกคุณว่าควรเริ่มต้นของคุณคืออะไร; หากการปฏิบัติตามกฎนั้นขัดกับเป้าหมายที่วางไว้เพื่อให้บรรลุเป้าหมายพวกเขาก็ไม่ควรทำตามในกรณีนั้น
jpmc26

6

รูปแบบการเข้ารหัสในองค์กรเป็นตัวเลือกหรือไม่

องค์กรเลือกที่จะมีรูปแบบการเข้ารหัส - ไม่จำเป็นต้องมีในครั้งแรก

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

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

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


1
Re: "แฮ็กเกอร์ระดับซุปเปอร์ส่วนใหญ่ที่ฉันรู้จักมาพร้อมกับอัตตาขนาดใหญ่พอ ๆ กับทักษะของพวกเขา": ฉันไม่คิดว่ามันเป็นเรื่องจริง ดูเหมือนว่าพวกเขาจะมีอัตตาขนาดใหญ่เพราะพวกเขาไม่ยอมฟังความคิดเห็นของคนอื่นโดยอัตโนมัติ แต่คนที่ฉันรู้จักรู้ดีว่าเปิดกว้างหากคุณสามารถทำสิ่งที่ดีสำหรับสิ่งที่คุณทำ (แม้ว่าฉันไม่แน่ใจว่า "อัตตา" เป็นสิ่งที่ตรงกันข้ามกับความสอดคล้องกันจริง ๆ )
ruakh

2
"แฮ็กเกอร์ระดับซุปเปอร์ส่วนใหญ่ที่ฉันรู้จักมาพร้อมกับอัตตาที่มีขนาดใหญ่พอ ๆ กับทักษะของพวกเขาและพวกเขาต้องการให้องค์กรปรับตัวเข้ากับพวกเขาไม่ใช่วิธีอื่น ๆ " ฉันสงสัยว่านักพัฒนาซอฟต์แวร์รายใดดีมากจนเกินดุลค่าใช้จ่ายของทัศนคติเช่นนี้และฉันสงสัยว่าวิศวกรดังกล่าวจะถูกว่าจ้างมานานมาก
แอนดี้

1
"และงานสร้างไม่ได้ล้มเหลวและการตรวจสอบโค้ดไม่ได้ล้มเหลวโดยอัตโนมัติเนื่องจากมีการละเมิดรูปแบบที่ทุก บริษัท " จริงๆแล้วฉันทำงานให้กับ บริษัท ที่ทำไปตามเส้นทางจริง มาตรฐาน
แอนดี้

3

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

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

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

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

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


1
เพื่อตอบคำถามสุดท้าย: มันเป็นการตัดสินใจของผู้บริหารระดับสูงในการหาแหล่งที่มาของห้องสมุดบางแห่ง และทีมของฉันไม่มีอิทธิพลต่อผู้ที่ทำงานอยู่ที่นั่น รูปแบบการเข้ารหัสของพวกเขาแตกต่างอย่างสิ้นเชิง
BЈовић

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

@ dan1111 - แน่นอน ฉันหมายความว่าพวกเขาอาจจะเดือดร้อนถึง "อย่าฉี่เพื่อนร่วมทีมของคุณออกไป" แต่คำถามที่ถามเกี่ยวกับเอกสารและการเผยแพร่โดยเฉพาะ
Telastyn

2

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

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

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

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


ดังนั้นข้อเสนอแนะของคุณคือปรับใช้งานในเจนกินส์ซึ่งจะทำการฟอร์แมตไฟล์ใหม่ทันทีที่มีคนตรวจสอบบางอย่าง BTW "ห้องกระดิก" คือผมคิดว่าบางสิ่งบางอย่างที่คล้ายกันในขณะนี้คำตอบ
BЈовић

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

2

จากการแก้ไขของคุณการเล็งเป้าหมายที่ถูกต้อง

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

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

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

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

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


0

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

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

ในสมัยก่อนคุณเพิ่งจะโต้วาทีที่ท้ายโต๊ะนักพัฒนาและอ้างบทและข้อว่าทำไมรหัสของเขา / เธอจึงละเมิดมาตรา 34.5.5767

ตอนนี้เรามีการวิเคราะห์โค้ดแบบสแตติกและเครื่องมือเอกสารอัตโนมัติซึ่งทำให้มาตรฐานโค้ดน่าเบื่อหน่ายไปมาก

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


สมมติว่าสไตล์การเขียนโค้ดนั้นเหมาะสมที่สุดและหากไม่เป็นเช่นนั้นผู้คนสามารถเปลี่ยนได้ คนที่อยู่ในกรณีนี้ได้รับอนุญาตให้เพิกเฉยหรือไม่
BЈовић

ยากที่จะพูด - โดยเฉพาะอย่างยิ่งหากไม่มีความเห็นเป็นเอกฉันท์ทั้งหมด ผมคิดว่านักพัฒนาอาวุโสและ / หรือการไกล่เกลี่ยจะเข้ามาเล่นที่นี่ ...
ร็อบบี้ดี

0

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

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

ดังนั้นคุณสามารถปรับความขัดแย้งทั้งสองที่ดูเหมือนกันนี้:

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

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


0

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

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

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


0

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

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

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

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

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

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

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

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

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

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


-1

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

มีเหตุผลอย่างสมบูรณ์ที่ต้องการจากนักพัฒนาทุกคนในการพัฒนานิสัยเพื่อใช้ฟอร์แมตเตอร์กับส่วนที่สร้างขึ้นใหม่ของรหัส

ที่แย่ที่สุดที่คุณสามารถทำได้คือต้องการสไตล์การเขียนโค้ดที่กำหนดเองซึ่งฟอร์แมตโค้ดที่มีอยู่ไม่รองรับ

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

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


เศร้านี้ไม่ตอบคำถามโดยตรง +1 ต่อไปสำหรับคำแนะนำที่ดีและวิธีแก้ปัญหาที่ใช้งานได้จริงโดยไม่มีจุดหมายเกี่ยวกับสไตล์ กำหนดค่าตัวจัดรูปแบบและดำเนินการด้วย
Bruno Schäpper

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

-1

ทางออกที่แท้จริง (ไม่ใช่แค่ปรัชญา)

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.