แปลมาจาก “Clean Code: A Handbook of Agile Software Craftsmanship”
หนึ่งในแรงกระตุ้นให้เราเขียน comment คือเราเขียนโค้ดในส่วนนั้นได้ห่วยแตก เพราะเมื่อมันห่วยแตกเราจะกังวลว่ามันถูกจัดการในภายภาดหน้าได้ยากเพราะมัน ยุ่งเหยิงดังนั้นเราคิดในใจเสมอว่า “เราควรเขียน comment ในส่วนนี้” แต่ในทางปฎิบัติที่ดีคือเราต้องจัดระเบียนโค้ดเราใหม่สิถึงจะถูก การที่เรามีโค้ดที่สามารถอธิบายตัวเองได้ทีมาพร้อมกับ comment ในปริมาณที่จำเป็นจะทำให้เรามีโค้ดที่มีคุณภาพมาก ดังนั้นเราควรใช้เวลาอันมีค่าของเราไปกับการเขียนโค้ดให้ดีจะมากกวว่าเสีย เวลาไปนั่งเขียน comment
Explain Yourself in Code
หลายครั้งที่เรา เห็นว่าโค้ดมันอธิบายตัวเองได้ห่วยแตกมาก แต่มี comment

// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
(employee.age > 65))

กับอีกอันที่เขียนแบบนี้

if (employee.isEligibleForFullBenefits())

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

แปลมาจาก Code in the Language of the Domain จากหนังสือ 97 Things Every Programmer Should Know
ลองนึกภาพตามโค้ดด้านล่าง

if (portfolioIdsByTraderId.get(trader.getId()).containsKey(portfolio.getId())) {...}

เดากันไปแบบมึนๆว่า มันน่าจะเอา ID ออกมาจาก Trader ออบเจคเพื่อดึง Map ออกมาจาก Map อีกตัว (Map-Of-Map) จากนั้นตวจสอบว่ามี ID ที่ต้องการจะใช้ของ Portfolio ออบเจคใหม่มีอยู่ใน Inner Map หรือไม่จากนั้นเราก็ต้องกลับไปไล่ดูการประกาศ
portfolioIdsByTraderId
Continue reading →