โปรแกรมเมอร์ทุกคนควรรู้อะไรเกี่ยวกับการเขียนโปรแกรม?

52

โปรดหลีกเลี่ยงปัญหาทางเทคนิคหลีกเลี่ยงพฤติกรรมวัฒนธรรมอาชีพหรือปัญหาทางการเมือง

experience  self-improvement  programming-practices 
— bigown
แหล่งที่มา
7
— pramodc84
คำถามประเภทนี้ทำให้ฉันรำคาญจริงๆ มันสามารถเกิดขึ้นจากความคิดของคนที่เห็นโลกในแง่ของสีดำและสีขาว ไม่ใช่โปรแกรมเมอร์ทุกคนที่มีงานเหมือนกันและหากเป็นตัวหารร่วมที่เล็กที่สุดที่คุณกำลังมองหาคำตอบด้านล่างแสดงว่าคุณเพิ่งจบด้วยรายการของสัตว์เลี้ยง
— Captain Sensible

คำตอบ:

92

  1. จุดบกพร่องอยู่ในรหัสของคุณไม่ใช่คอมไพเลอร์หรือไลบรารีรันไทม์

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

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

  4. การเขียนเอกสารเป็นส่วนหนึ่งของงานของคุณในฐานะโปรแกรมเมอร์ อย่าปล่อยให้ "คนอื่น" ทำ

แก้ไข

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

ย้อนกลับไปในวันที่ฉันพัฒนา C / C ++ ฉันจำกรณีที่ควรเพิ่ม "บั๊ก" ของ optimizer กลายเป็นเพราะฉัน / โปรแกรมเมอร์คนอื่น ๆ ทำสิ่งต่าง ๆ ที่สเป็คภาษาบอกว่ามีผลลัพธ์ที่ไม่ได้กำหนด สิ่งนี้ใช้ได้กับภาษาที่ปลอดภัยอย่างจาวาเช่น; เช่นลองดูรูปแบบหน่วยความจำ Java (JLS ตอนที่ 17) อย่างละเอียด

— Stephen C
แหล่งที่มา
17
ฉันชอบพูดว่า "ข้อผิดพลาดน่าจะอยู่ในรหัสของคุณ" เนื่องจากฉันเจอข้อผิดพลาดในไลบรารีรันไทม์สองสามครั้ง ฉันยังไม่ได้เจอข้อบกพร่องของคอมไพเลอร์ +1 อยู่ดี
— Chinmay Kanchi
29
หากคุณไม่เคยพบข้อผิดพลาดที่แท้จริงในคอมไพเลอร์แสดงว่าคุณไม่ได้ผจญภัยมากพอกับการเข้ารหัสของคุณ ;)
— Mason Wheeler
8
@Chinmay, @ spudd86, @Mason - ใช่ ... และฉันก็ได้พบส่วนแบ่งคอมไพเลอร์และข้อบกพร่องของไลบรารีในการเขียนโปรแกรมกว่า 30 ปี แต่จากประสบการณ์ของฉัน 99 +% ของข้อบกพร่องกลายเป็น (อย่างน้อยในส่วน) ความผิดของรหัสของฉัน คำตอบของฉันจงใจ overstates นี้จะได้รับในจุดที่คุณควรเสมอสงสัยว่ารหัสของคุณครั้งแรก
— สตีเฟ่นซี
5
ฉันไม่ได้รับความกลัวอย่างไม่มีเหตุผลที่ผู้คนมีกับการเขียนโปรแกรมแบบมัลติเธรด ฉันสงสัยว่าคนที่ขยายเวลามุมมองนี้อย่าตั้งโปรแกรมโค้ดหลายเธรด มันไม่ใช่เรื่องยาก +1 สำหรับทุกอย่างอื่นว่า
— Steven Evers
4
หากคุณกำลังทำงานบนคอมไพเลอร์แล้วข้อผิดพลาดน่าจะเป็นทั้งในรหัสและคอมไพเลอร์ของคุณ;)
— Legooolas
84
  • วิธีอ่านรหัสของคนอื่น
  • ไม่มีรหัสหากไม่มีการตรวจสอบในระบบควบคุมเวอร์ชัน
— pramodc84
แหล่งที่มา
8
+10000 ถ้าฉันทำได้สำหรับความคิดเห็นในการควบคุมเวอร์ชัน ประวัติและการบันทึกการเปลี่ยนแปลงนั้นเป็นสิ่งที่ขาดไม่ได้อย่างแน่นอนและเป็นเหตุผลที่คุณควรใส่ทุกอย่างไว้ในการควบคุมเวอร์ชันตั้งแต่เริ่มต้น
— Legooolas
2
... และที่เก็บข้อมูลถูกซิงโครไนซ์กับตำแหน่งอื่นอย่างน้อยหนึ่งแห่ง สำคัญกับ DVCS แต่รวมถึง VCS จากส่วนกลางด้วย
สำหรับเรื่องนั้นไม่มีรหัสเว้นแต่ว่าจะมีรายการงานที่อนุญาตให้นักพัฒนาเขียนได้
— Jesse C. Slicer
2
ฉันจะบวกหนึ่งสำหรับการเรียนรู้วิธีการอ่านรหัสของคนอื่น มันยากกว่าที่พวกเราส่วนใหญ่ตระหนัก แต่เป็นส่วนสำคัญของการเขียนโปรแกรมที่ประสบความสำเร็จ
— bogeymin
บวกหนึ่งสำหรับการเรียนรู้วิธีการอ่านรหัสของผู้อื่น
— itsaboutcode
76

การคำนวณจุดลอยตัวนั้นไม่แม่นยำ

— Chinmay Kanchi
แหล่งที่มา
22
— Adam Paynter
หากไม่มีใครรู้ว่าฉันกำลังพูดถึงอะไรให้อ่านลิงค์ของ @ Adam มันเป็นบทสรุปที่ยอดเยี่ยมเกี่ยวกับข้อผิดพลาดของการคำนวณจุดลอย
— Chinmay Kanchi
1
และหากพวกเขาไม่ทราบว่าพวกเขาสามารถอยู่ในกลุ่มคนที่ถามเกี่ยวกับ stackoverflow ทุกวัน
— Brian R. Bondy
1
@Brian: จริง ฉันหวังว่าจะมีวิธีการระบุคำถามที่อธิบายโดยการคำนวณจุดลอยตัว คุณสามารถสร้างแอปสแต็คที่แสดงคำถามจุดลอยตัวที่แตกต่างกันทุกวัน!
— Adam Paynter
63

อย่าหยุดเรียน

— จ่ายเงินให้หมด
แหล่งที่มา
1
ที่เกี่ยวข้อง: อย่าหยุดเชื่อ
— Fishtoaster
3
ที่เกี่ยวข้อง: อย่าหยุดคิดเกี่ยวกับวันพรุ่งนี้
— ocodo
7
ที่เกี่ยวข้อง: อย่าหยุดเพลง
— adamk
1
ที่เกี่ยวข้อง: อย่าหยุด movin '! มันคือชีวิตของคุณเดินหน้าต่อไปทำให้ถูกต้องคุณต้องทำให้ถูกต้อง!
— ocodo
44

สิ่งที่คุณสามารถทำได้อันดับหนึ่งในการเพิ่มคุณภาพและความสามารถในการบำรุงรักษาโค้ดของคุณคือลดการซ้ำซ้อน

— Chris Holmes
แหล่งที่มา
4
แห้งใช่! ฉันจะลืมได้อย่างไร ;-)
— Maniero
นี้เป็นสิ่งสำคัญดังนั้นผมจึงตอบกับมันอีกครั้ง
ฉันอยากจะบอกว่า: ลดเงื่อนไข แต่ละ while / if / for เป็นบั๊กที่เป็นไปได้
— zvrba
1
คุณจะรู้ว่าสิ่งที่ตลกเกี่ยวกับ DRY คือมันซ้ำแล้วซ้ำอีกทุกที่ :) +1
— Billy ONeal
39

การแก้ไขปัญหาและทักษะการแก้จุดบกพร่อง

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

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

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

— JohnFx
แหล่งที่มา
2
ฉันกำลังจะโพสต์สิ่งนี้ งานของโปรแกรมเมอร์ส่วนใหญ่กำลังแก้ไขข้อบกพร่องและผู้คนจำนวนมากมักจะไม่สามารถทำเช่นนั้นได้ (โดยเฉพาะอย่างยิ่งในรหัสของผู้อื่น)
— Dov
+1 ฉันไปจาก javascript / php ถึง C # และตกหลุมรักกับการก้าวผ่านโค้ด ฉันหวังว่าภาษาที่พิมพ์แบบไดนามิกสามารถทำสิ่งนี้ได้ดีกว่ามาก
— Evan Plaice
อีกพฤติกรรมที่แปลกคือโปรแกรมเมอร์ยืนยันว่าทุกส่วนของโปรแกรมนั้นถูกต้องในขณะที่ผลถ้าผิดพลาด "- คุณไม่จำเป็นต้องพิมพ์อาเรย์บนคอนโซลเพื่อตรวจสอบว่ามันถูกเรียงเพราะบรรทัดด้านบนคือ array.sort ()" "- ดี ... คุณรู้ไหมมันไม่ทำงานต้องมีบางอย่างผิดปกติคุณไม่สามารถป้องกันรหัสของคุณได้ในตอนนี้!"
— gawi
2
ฉันคิดว่าจุดบกพร่องในการตรวจสอบสมมติฐานของคุณในโปรแกรมของคุณ บางครั้งคุณต้องไปตกปลาเพื่อหาเบาะแส สิ่งนี้จะต้องทำอย่างเป็นระบบ การลองสิ่งที่อาจบอกอะไรใหม่แก่คุณได้อย่างสมบูรณ์ ฉันทำมันบ่อย
— gawi
37
  1. อย่าฉลาด ชัดเจน
  2. ใช้ก่อนนำมาใช้ซ้ำ
  3. ชื่อเรื่อง
  4. ฟังก์ชั่นทำ 1 สิ่งและทำได้ดี
  5. เล็กดีกว่าใหญ่
— KevBurnsJr
แหล่งที่มา
2
คุณช่วยอธิบาย "ใช้ก่อนนำมาใช้ใหม่" ได้ไหม ฉันไม่เคยได้ยินเรื่องนี้มาก่อน
— Tjaart
34

พื้นฐาน. โปรแกรมเมอร์ในปัจจุบันเรียนรู้เทคโนโลยีไม่ใช่แนวคิด มันผิด.

— clrod
แหล่งที่มา
ใช่และไม่. คุณฟังเหมือนทุก ๆ ศาสตราจารย์ที่ฉันเคยมีในมหาวิทยาลัย ... ทุกคนไม่เคยทำซอฟต์แวร์มาตลอดชีวิต ความรู้ที่ไม่มีทักษะนั้นไร้ประโยชน์ในอาชีพของเรา
— Steven Evers
4
+1 จริง ใช่นี่คือหอคอยประเภทงาช้างที่อยากพูด แต่มันไม่ได้ทำให้ความจริงของเราที่เหลืออยู่ในสนามเพลาะลดลง
— MAK
2
พื้นฐานเช่นการสะกดคำ? Its wrongควรเป็นit's wrongตัวอย่าง
— Konerak
2
ไม่ข้อมูลพื้นฐานเช่นไม่สนใจเกี่ยวกับการพิมพ์ผิด แต่ใส่ใจเกี่ยวกับปัญหาการเขียนโปรแกรม
— clrod
5
เป็นการง่ายที่จะเรียนรู้ขั้นตอนในการทำบางสิ่งบางอย่างและบ่อยครั้งที่จะรู้ว่าคุณควรใช้เมื่อไรและที่สำคัญกว่าเมื่อคุณสามารถใช้ แต่ไม่ควรทำ หนังสือเรียนไม่ดีโดยเฉพาะอย่างยิ่งในการแสดงว่าทำไม แต่ไม่ใช่ (และทำไมไม่)
— HLGEM
27

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

และเขาควรรู้ว่าเขาควรเตรียมตัวเมื่อสมมติฐานเหล่านั้นแตก

— LennyProgrammers
แหล่งที่มา
6
ระบุเฉพาะผู้ที่มีassert()- ทุกที่ assert()จะช่วยคุณจัดทำเอกสารสมมติฐานและช่วยคุณประหยัดเมื่อคุณผิด
— ดัสติน
@Dustin +1 ไม่มีทางที่คุณจะสามารถจดจำสมมติฐานทั้งหมดของคุณได้ - จัดทำเอกสารตามโปรแกรมและคุณจะได้รับการบอกกล่าวอย่างแน่นอนเมื่อพวกเขากลายเป็นข้อสันนิษฐานที่ผิด
— Skilldrick
1
... เว้นแต่จะรวบรวมด้วย NDEBUG
17

เรียนรู้แนวคิด คุณสามารถ Google ไวยากรณ์

— pramodc84
แหล่งที่มา
ดีมากในทางทฤษฎียกเว้น Google เป็นสิ่งที่แย่มากในการค้นหาไวยากรณ์ที่เฉพาะเจาะจง : การค้นหาคำเช่น "การอ้างอิงวัตถุ" หรือ "สิ่งนี้" ได้รับผลลัพธ์ที่มีมูลค่ามหาศาลถึงพันล้านและการค้นหาสำนวนเช่น "$" ไม่ให้ผลลัพธ์เลย
— l0b0
16

การคิดเชิงวิพากษ์และเชิงตรรกะ คุณไม่สามารถทำสิ่งที่ดีได้หากไม่มีมัน

— Mladen Prajdic
แหล่งที่มา
14

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

— btlog
แหล่งที่มา
13

มันยากกว่าที่คุณคิด

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

จากนั้นคุณต้องทำให้แอปพลิเคชันดูดีเช่นกัน

— ChrisF
แหล่งที่มา
3
ฉันคิดว่านี่เป็นที่มาของคำว่า '90% ของงานใช้เวลา 90% ของเวลา 10% สุดท้ายใช้เวลา 90% ของเวลา '
— GSto
ฉันคิดว่าผู้คนจำนวนมากมักจะประเมินความซับซ้อนไม่สม่ำเสมอ "X จะยากขนาดไหน" - คำพูดสุดท้ายที่มีชื่อเสียง: /
— Roman Starkov
@ GS ฉันไม่ต้องการทำงาน 180% ของเวลา 100% ก็ดีสำหรับฉัน!
— adamk
13

ความรู้เกี่ยวกับโดเมน สเป็คไม่เคย 100%; การรู้ว่าโดเมนที่คุณกำลังพัฒนาต้องการจะเพิ่มคุณภาพของผลิตภัณฑ์

— Steven Evers
แหล่งที่มา
13

สัญลักษณ์ Big O และความหมายของมัน

อ้างอิงที่มีประโยชน์บางอย่าง

— Slomojo
แหล่งที่มา
ฉันพบสัญกรณ์ Big O เป็นหนึ่งในสิ่งสำคัญที่นักวิทยาศาสตร์คอมพิวเตอร์ส่วนใหญ่มีปัญหา (รวมอยู่ด้วยตัวเอง)
— Richard
11

พอยน์เตอร์เห็นได้ชัด :)

— Laurynas Biveinis
แหล่งที่มา
3
พอยน์เตอร์มีความจำเป็นจริงๆในชุดย่อยของภาษาสำหรับชุดย่อยของงาน สำหรับงานส่วนใหญ่คุณสามารถ (และควรจะ) โปรแกรมราวกับว่าแนวคิดของตัวชี้ไม่มีอยู่
— Chinmay Kanchi
14
@Chinay Kanchi ไม่ทุกคนควรเข้าใจตัวชี้
— ทางเลือก
5
ว่ามันขึ้นอยู่กับสิ่งที่คุณหมายถึงตัวชี้ หากคุณหมายถึงพอยน์เตอร์ C-style ที่คุณสามารถควบคุมได้ (ซึ่งเป็นสิ่งที่ฉันสันนิษฐาน) ฉันจะยืนยันว่าโปรแกรมเมอร์ Java / C # / Python ไม่จำเป็นต้องรู้อะไรเกี่ยวกับมัน หากคุณหมายถึงพอยน์เตอร์ใน "การอ้างอิง" ของ Java เช่นพอยน์เตอร์ที่ไม่สามารถเล่นกับดังนั้นใช่ความรู้บางอย่างของพวกเขามีความจำเป็นถ้าเพียงเพื่อป้องกันคุณจากการลื่นไถลขึ้น
— Chinmay Kanchi
@ คณิตศาสตร์คุณจะถูกเขย่าให้อยู่ในใจกลางของคุณหากคุณต้องเรียนรู้ว่ามีนักเรียน CS จำนวนเท่าไหร่ในแต่ละปีที่ไม่เข้าใจสิ่งแรกเกี่ยวกับพอยน์เตอร์ ถ้าฉันไม่ออกไปนอกบ้านเพื่อเข้ารับตำแหน่งในฤดูร้อนฉันจะไม่ได้รับการสอนเกี่ยวกับพอยน์เตอร์ใน C หรือการอ้างอิงใน Java ...
— Mike B
5
@Chinmay: โปรแกรมเมอร์ Python / Java / C # ที่ไม่เข้าใจแนวคิดของพอยน์เตอร์จะหายไป L = [[]] * 2; L[0].append(42) ภาษาที่แตกต่างกันใช้ชื่อแตกต่างกัน แต่ความร้ายเป็นสิ่งจำเป็นที่ทุก
11

รหัสสมบูรณ์ 2 - ครอบคลุมเพื่อปกปิด

— ไคล์บัลลาร์ด
แหล่งที่มา
คุณควรรู้เรื่องนี้จริงๆก่อนที่จะรับเงินเข้าโปรแกรม หากคุณพบสิ่งที่คุณไม่เคยรู้มาก่อนลองพิจารณาการเปลี่ยนอาชีพหรือช่วงเวลาที่เข้มข้นของการเรียนรู้ด้วยตนเอง แล้วขออภัยต่อเพื่อนร่วมงานของคุณ และครอบคลุมเฉพาะพื้นฐานการเขียนโปรแกรม
— ทิม Williscroft
11

ข้อมูลสำคัญกว่ารหัส

หากข้อมูลของคุณสมาร์ทรหัสสามารถเป็นใบ้

รหัสโง่ง่ายต่อการเข้าใจ ดังนั้นข้อมูลอัจฉริยะ

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

— กอนซาเล
แหล่งที่มา
2
คุณมีฉันตลอดทางจนกว่าคุณจะพูดว่า "ระบบพิมพ์"
10

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

— แดน Diplo
แหล่งที่มา
10

หารและพิชิต เป็นวิธีที่ดีที่สุดในการแก้ปัญหาเชิงปฏิบัติทุกประเภทตั้งแต่การตั้งเวลาไปจนถึงการแก้ไขข้อบกพร่อง

— Rick Minerich
แหล่งที่มา
8

ทักษะที่แท้จริงสะท้อนให้เห็นถึงความสามารถในการออกแบบที่เรียบง่ายได้ดีไม่ได้อยู่ในความสามารถในการออกแบบที่ซับซ้อนเลย

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

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

ในคำ: ความสง่างาม ทุกคลาสทุกวิธีทุกเงื่อนไขทุกบล็อคทุกชื่อตัวแปร: มุ่งมั่นเพื่อความสง่างาม

— ลิ่ม
แหล่งที่มา
8

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

— user8
แหล่งที่มา
6

โปรแกรมเมอร์ทุกคนควรรู้วิธีการใช้ดีบักและรู้วิธีการใช้งานได้ดี

— Brian R. Bondy
แหล่งที่มา
4

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

— Federico klez Culloca
แหล่งที่มา
4

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

— ผุดลุก
แหล่งที่มา
2
หรือเรียนรู้วิธีการเป็นแขกรับเชิญที่ดีและถ่ายทอดว่าคุณไม่ได้เป็นแขกรับเชิญ ... ;)
— Billy Coover
4

เรื่องสไตล์การเข้ารหัส:

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

... และเรื่องการออกแบบที่ดี

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

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