Tags:

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

  • อย่าพยายามทำเท่ห์ด้วยการใช้ left shift แทนการคูณด้วย 2 (อันนี้เคยเจอมากับตัว มันก็เท่ห์ดีนะ แต่งงอยู่นานเลยล่ะ)
  • ช่วยตั้งชื่อตัวแปรให้มันสื่อความหมายหน่อย ถ้าใช้ภาษาระดับสูง (Java, .Net, PHP, etc.) ก็ตั้งชื่อให้มันอ่านออกและมีความหมายไปเลย
  • วางแผนก่อนแล้วค่อยลงมือเขียนโค้ด เสียเวลาคิดสองนาที อาจจะช่วยไม่ให้คุณนั่งปวดหัวไปอีกหลายสัปดาห์
  • โค้ดที่ไม่ใช้ให้ลบออกไปเลย อย่าคอมเม้นต์ทิ้งไว้ มันรกหูรกตา ถ้ากลัวว่าโค้ดเก่าจะหายไป ก็หัดใช้ SVN หรือ CVS ซะบ้าง
  • อย่าคิดว่าทำแบบนี้ให้เสร็จไปก่อนวันหลังค่อยมาแก้ให้มันดี โค้ดที่คุณเขียนอาจถูกใช้งานนานกว่าที่คุณคิด (หรืออาจจะซับซ้อนจนไม่กล้าแก้!) ดังนั้นทำให้มันดีไปเลยดีกว่า
  • ...และข้อสุดท้ายอย่าขี้เกียจ!!!

ทิ้งท้ายด้วยประโยคเด็ดจากหนังสือเล่มนี้

programs must be written for people to read, and only incidentally for machines to execute

ที่มา: blog.onlysimpler.com

Comments

By: 0xffeeddaa
0xffeeddaa's blog
on 13/06/07 22:50 #24664 toggle
0xffeeddaa's picture

จะว่าไปผมก็ไม่เคยใช้ cvs เลย เคยแต่ลงทิ้งไว้เฉยๆ แต่ไม่ได้ใช้

By: althema
AndroidWindows
althema's blog
on 13/06/07 23:40 #24666 toggle
althema's picture

คนที่ใช้ left shift คงไม่ได้ใช้เพราะมันเท่ห์หรอกมั้งครับ แต่ใช้เพราะการ shift bit มันทำได้เร็วกว่าการใช้คำสั่งคูณ (ใช้ cpu cycles น้อยกว่า)

แต่ผมก็เห็นด้วยว่า ถ้าเขียนโปรแกรมทั่วๆ ไป ไม่ได้เน้นว่า จะต้องทำงานให้ได้เร็วที่สุด ก็ใช้คำสั่งคูณก็ดูจะเหมาะสมกว่า การใช้คำสั่ง left shift

By: smilelovehappiness
smilelovehappiness's blog
on 14/06/07 10:15 #24680 toggle
smilelovehappiness's picture

ไม่เคยใช้ left shift เลย!

By: mr_tawan
ContributoriPhoneAndroidWindows
mr_tawan's blog
on 14/06/07 11:28 #24694 toggle
mr_tawan's picture

คิดว่า คอมไพล์เลอร์ฉลาด ๆ ส่วนใหญ่ ถ้าเจอ *2 ปุ๊บมันคงแก้ให้เป็น <<1 เลยอ่ะครับ (ทำ Optimizeไง)

เคยมีเขียนไว้ว่า กฎการ Optimize ข้อหนึ่ง ไม่ทำการ Optimize ถ้าไม่จำเป็น ...


By: lew
FounderJusci's WriterMEconomicsAndroid
lew's blog
on 14/06/07 11:33 #24695 Reply to:24694 toggle
lew's picture

หนังสือ pthread ก็มีนะครับ ประมาณว่าอย่าใช้ thread ถ้าไม่รู้ว่ากำลังทำอะไรอยู่ ------ LewCPE


LewCPE's Google+

By: ipats
ContributorNOOBIn Love
ipats's blog
on 14/06/07 14:52 #24707 Reply to:24694 toggle
ipats's picture

ถ้าจำเป็นก็เขียน optimizer/compiler เอง เพื่อแปลงไฟล์ที่คนอ่านรู้เรื่อง ไปสู้โค้ดที่ทำงานได้เร็วขึ้นแต่อ่านยาก เวลาแก้ก็แก้ที่ไฟล์อ่านรู้เรื่อง แล้วสั่งแปลงโค้ด

เป็นวิธีที่ดี... ถ้ามั่นใจว่าจะเขียน optimizer ไม่มีบั๊ก ไม่งั้น ได้ปวดหัวไปอีกหลายวัยแน่ๆ :D

---------- iPAtS


iPAtS

By: ABZee
ABZee's blog
on 14/06/07 15:27 #24711 Reply to:24694 toggle
ABZee's picture

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


LongSpine.com

By: kaze
Writer
kaze's blog
on 14/06/07 17:23 #24721 toggle
kaze's picture

เฮอะๆ ประสบการณ์ที่เคยเจอนะครับ - เขียน C แล้ว include library ไม่ยอมเรียง A-z แล้ว include เป็นร้อย คนมาเขียนเพิ่มก็ดันใส่ซ้ำไปอีก... - เวลา link เป็น exe ก็ดัน link ทั้งหมด ทั้งๆที่ บาง link obj ก็ไม่ได้ถูกใช้ใน exe นี้ แต่ถูกใช้ใน exe อีกอัน - Function prototype ถ้าเป็น C แล้วมี output ก็จะ้เอาขึ้นก่อน เช่น strcpy(string_output, string_input); บางคนเขียนอันนึงขึ้นก่อน อันนึงไว้ด้านหลัง คือจะเอาอะไรขึ้นก่อนไม่ว่า ขอให้มัน follow standard library ของภาษาหน่อย

By: Bluegear
Bluegear's blog
on 14/06/07 18:01 #24722 toggle
Bluegear's picture

ประสบการณ์สุดปวดหัวของผมมีสองแบบ

- เจอโปรแกรมแบบกระโดดไปเรื่อยๆ เรียก function ไม่รู้จบ อ่านแล้วงงว่าตกลงที่กดตามเข้ามาแต่แรกมันตั้งใจจะทำอะไรกันแน่หว่า

- if ซ้ำ if ซ้อน ซ่อนเงื่อน เฉือนคม กว่าจะอ่านออกก็เหนื่อยแล้ว ที่เคยคิดจะแกะมาเขียนใหม่เป็นอันว่าช่างมันเหอะ ปล่อยมันไว้อย่างนี้แหละ แค่อ่านก็คลานแว้ววว

ปล. ไม่เคย optimize code เลยครับ

By: smilelovehappiness
smilelovehappiness's blog
on 14/06/07 18:33 #24725 Reply to:24722 toggle
smilelovehappiness's picture

กำลังตอ้งแก้โค๊ดแบบนี้ ขอบอกว่านรกมากๆ ทรมาณ............

By: somsak_sr
ContributorAndroidUbuntu
somsak_sr's blog
on 14/06/07 20:46 #24740 toggle
somsak_sr's picture

ผมว่าที่สำคัญที่สุดเลย คือต้องเขียนโค้ดให้ grep ได้ง่าย หลังๆเจอพวกเรียกฟังก์ชันโดยใช้ eval มั่ง pointer to function ไปเรียก pointer to member function อีกทีมั่ง ยิ่งพวก Python นี่มีแบบว่าสร้างชื่อฟังก์ชันเป็น string แล้วค่อย eval นี่เท่ชมัดแต่ไล่โค้ดลำบากจังเลย ถ้าจำเป็นต้องใช้ก็โอเคครับ แต่คิดก่อนใช้ก็ดี

By: Wintermute
Wintermute's blog
on 15/06/07 3:59 #24761 toggle
Wintermute's picture

อืม ใช้ทั้ง left shift กะ right shift เพื่อการคูณการหารเลย

แต่กลัวคนอื่นงงผมใช้ macro ช่วยหนะครับ แบบ

#define DOUBLE(var) var << 1 #define QUAD(var) var << 2 #define HALF(var) var >> 1

#define RESET(var) var ^ var

พอดีงานของผมมันอยู่บน Thin client หนะครับ แล้ว closs platform ด้วย ไม่รู้ว่า compiler ตัวไหนจะ optimize ให้ยังไงบ้างมั่ง

By: kaze
Writer
kaze's blog
on 15/06/07 16:34 #24803 Reply to:24761 toggle
kaze's picture

สงสัยครับว่า การใช้ left shift กับ right shift มันช่วยให้โปรแกรมทำงานเร็วขึ้นแค่ไหนครับ (ช่วยประมาณทีครับ)

By: thep
Writer
thep's blog
on 16/06/07 17:15 #24870 Reply to:24803 toggle
thep's picture

จำข้อมูลละเอียดไม่ได้ จำได้แค่คร่าว ๆ ตั้งแต่สมัยเขียน assembly ว่าต่างกันพอสมควรครับ ลอง search ดู ได้ความว่าอย่างนี้:

เปรียบเทียบ clock cycle ของ 80x86 instruction set คำสั่ง SHL/SAL/SAR (shift) สำหรับ register 8 บิต ใช้เพียง 3 clock ใน 486 ส่วนคำสั่ง MUL/IMUL (คูณ) สำหรับ register 8 บิตใน 486 จะใช้ถึง 13-18 clock, DIV ใช้ 16 clock และ IDIV ใช้ 19 clock

ส่วนใน Pentium การกระทำเดียวกัน คำสั่ง shift ใช้เพียง 1 clock ส่วน MUL ใช้ 8, IMUL ใช้ 10, DIV ใช้ 17 และ IDIV ใช้ 22 clock

แต่ผมคิดว่า เรื่องการคูณ/หารด้วยการ shift นี่ คอมไพเลอร์ส่วนใหญ่น่าจะ optimize ให้อยู่แล้วนะครับ

By: thep
Writer
thep's blog
on 16/06/07 17:37 #24871 toggle
thep's picture

เกี่ยวกับการ optimize.. ไม่ควรพยายาม optimize หยุมหยิมขณะเขียนโค้ด ร้อยทั้งร้อย มันไม่ช่วยอะไรหรอก นอกจากทำให้โค้ดอ่านยากขึ้นเท่านั้นแหละ

optimize ในระดับอัลกอริทึมจะเห็นผลชัดกว่า วิเคราะห์ Big-O function ให้ดีตั้งแต่ขั้น design (หรือ redesign) แล้วค่อยโค้ด

การ optimize ผิดที่ ก็ไม่ช่วยอะไร บางครั้ง จุดที่เป็นคอขวด อาจไม่ใช่จุดที่คิดไว้ก็ได้ เชื่อ profiler ดีกว่า

เมื่อพบคอขวดแล้ว optimize loop (เช่น ใส่ cut-off เพื่อตัดการวิ่ง loop เปล่าที่ไม่จำเป็น) ดีกว่า optimize expression

การ optimize expression จะให้ผลดีต่อเมื่อทำที่จุดที่วิกฤตที่สุดของโปรแกรมเท่านั้น

ปล. คำว่า "เท่" ไม่มี ห การันต์ นะครับ

By: IceDagger
IceDagger's blog
on 17/06/07 4:00 #24881 toggle
IceDagger's picture

สำหรับผมไม่มีอะไรจะปวดหัวไปกว่าไล่โคดของโปรแกรมเมอร์ที่กำลังบ้าเห่อ OOP โปรแกรมแทนที่จะเขียนให้ไล่ง่าย ๆ กลายเป็นว่ามี class อะไรก็ไม่รู้ที่ไม่จำเป็นเยอะแยะไปหมด โคดเรียกซ้อนลงไปไม่รู้ตั๊งกี่ชั่นกว่าจะเจอส่วนที่ทำงานจริง ๆ เดี๋ยวก็ Manager นั้น Manager นี้ เพียบไปหมด เขียนเป็น structural ก็เสร็จไปนานแล้ว

By: Bluegear
Bluegear's blog
on 17/06/07 17:09 #24893 Reply to:24881 toggle
Bluegear's picture

ถ้า OOP ได้ถูกต้องจริงๆ มันจะไม่ปวดหัวหรอกครับ ผมเองก็ต้องพยายามเตือนตัวเองเสมอเหมือนกัน ว่าอย่าสร้างคลาสใหม่ถ้ามันไม่จำเป็นจริงๆ เพราะปวดหัวเหมือนกันครับเวลาไล่โปรแกรมแบบนั้น กระโดดไปสิ แปดชั้น สิบชั้น งงจริงๆ

แต่อะไรก็ไม่นรกเท่า if ซ้อน if ซ้อน if ซ้อน if ซ้อน if ซ้อน .... (ล้อเล่นนะครับ สองชั้นจะเป็นลมแล้วครับ)

By: bossalove
bossalove's blog
on 20/06/07 15:34 #25134 toggle
bossalove's picture

ผมว่าต่อให้ design ดียังไง ใช้ methodology ที่ดียังไง ถ้าระบบมันใหญ่และซับซ้อนจริง ถึงจุดหนึ่งมันก็ต้องซับซ้อนเกินว่ามนุษย์จะอ่านได้ง่ายๆอยู่ดี

ผมว่าแก้ปัญหาด้วยการทำ documentation น่าจะดีกว่านะ ถ้ามัวแต่หวังแต่จะงม code ลูกเดียว . . . . โอ๊ว . . . .

By: Bluegear
Bluegear's blog
on 21/06/07 4:49 #25180 Reply to:25134 toggle
Bluegear's picture

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