พิมพ์ไทยสำหรับโปรแกรมเมอร์: เวิร์กโฟลว์เกษมณีสำหรับโค้ด คอมเมนต์ คอมมิต และเอกสาร
นักพัฒนาในประเทศไทยมักทำงานกับสองระบบภาษาในหน้าจอเดียวกัน โค้ด ชื่อแพ็กเกจ path คำสั่งใน shell ชื่อ branch และ API ส่วนใหญ่ใช้ภาษาอังกฤษ แต่คอมเมนต์ เอกสารภายใน รายละเอียด issue ข้อความใน pull request คำอธิบาย test requirement ของผลิตภัณฑ์ และ commit message อาจต้องใช้ภาษาไทย ปัญหานี้จึงไม่ใช่แค่พิมพ์ไทยให้เร็ว แต่เป็นปัญหาของเวิร์กโฟลว์: ต้องสลับภาษาให้ทันความคิด รักษาความถูกต้องของโค้ด ทำให้ข้อความไทยอ่านง่าย และลดข้อผิดพลาดเล็ก ๆ ที่มองข้ามได้ง่ายตอน review
บทความนี้เขียนสำหรับผู้ใช้เกษมณีที่รู้พื้นฐานของแป้นพิมพ์แล้ว และต้องการระบบทำงานแบบสองภาษาในงานพัฒนาโปรแกรม จึงจะไม่สอนซ้ำเรื่องแถวเหย้า ผังนิ้วทั้งหมด สระ วรรณยุกต์ แถวตัวเลข หรือการตั้งค่าระบบปฏิบัติการแบบละเอียด แต่จะเน้นว่าเมื่ออยู่ในงานเขียนโปรแกรม ควรใช้ภาษาไทยตรงไหน ใช้อย่างไร และป้องกันไม่ให้การสลับภาษาขัดจังหวะความคิด หลักใหญ่มีเพียงข้อเดียว: โค้ดควรอยู่ในโหมดภาษาอังกฤษเสมอ เว้นแต่กำลังตั้งใจเขียนข้อความไทยจริง ๆ
งานพัฒนาแบบสองภาษาคือปัญหาการจัดการสถานะ
โปรแกรมเมอร์ทำงานกับสถานะที่มองไม่เห็นอยู่ตลอดเวลา เช่น directory ปัจจุบัน branch ของ Git environment ของ Python terminal pane ที่เลือกอยู่ mode ของ editor ตำแหน่ง cursor และไฟล์ที่ยังไม่ได้ save สถานะภาษาของแป้นพิมพ์ก็เป็นสถานะหนึ่งเช่นกัน เมื่อสถานะนี้ผิด ข้อผิดพลาดอาจไม่ปรากฏชัดจนกว่าจะพิมพ์ไปแล้วหลายตัวอักษร ตัวไทยที่หลุดเข้า source code เครื่องหมายไทยที่ติดอยู่ในคำสั่ง หรือข้อความไทยที่เผลอไปอยู่ในชื่อไฟล์ อาจทำให้เสียเวลามากกว่าการพิมพ์ข้อความไทยทั้งประโยค
กรอบคิดที่ดีไม่ใช่ “ฉันพิมพ์ไทยเป็นบางครั้ง” แต่ควรเป็น “ฉันเข้าโหมดไทยเฉพาะในพื้นที่ที่ปลอดภัยสำหรับภาษาไทย” พื้นที่ที่ปลอดภัยได้แก่ คอมเมนต์ string literal ที่ตั้งใจให้เป็นข้อความไทย Markdown ที่เป็นเนื้อความ รายละเอียด issue คำอธิบาย pull request และย่อหน้าเอกสาร ส่วนพื้นที่ของโค้ดได้แก่ identifier keyword operator import คำสั่ง path ชื่อ branch ชื่อ environment variable key ใน JSON ที่เป็นสัญญา API และค่าคอนฟิกส่วนใหญ่ editor เดียวกันอาจมีทั้งสองพื้นที่อยู่ติดกัน ดังนั้นผู้พิมพ์ต้องรู้ก่อนเสมอว่า cursor อยู่ในพื้นที่แบบใด
- พื้นที่โค้ด: ใช้ input method ภาษาอังกฤษเป็นค่าเริ่มต้น เว้นแต่มีเหตุผลชัดเจนให้ใช้ไทย
- พื้นที่คอมเมนต์: ใช้ไทยได้เมื่อคอมเมนต์อธิบายเจตนา business rule edge case หรือศัพท์เฉพาะของงาน
- พื้นที่สตริง: ใช้ไทยได้เฉพาะเมื่อเป็นข้อความที่ผู้ใช้ต้องเห็น test data ข้อความแปล หรือข้อมูลตัวอย่างที่ตั้งใจใส่
- พื้นที่ Markdown: โดยทั่วไปใช้ไทยได้ในย่อหน้า หัวข้อ task description และข้อความ review
- พื้นที่ terminal: ถือว่าไม่ปลอดภัยสำหรับภาษาไทย เว้นแต่กำลังป้อนข้อความให้โปรแกรมที่รองรับและคาดหวังภาษาไทยโดยตรง
ทำให้ปุ่มสลับภาษาเป็น shortcut ระดับหลัก
นิสัยที่สำคัญที่สุดต่อประสิทธิภาพไม่ใช่การจำตำแหน่งแป้นเพิ่มอีกหนึ่งตำแหน่ง แต่คือการทำให้การสลับภาษาเป็นเรื่องอัตโนมัติ บน Windows shortcut ที่พบได้บ่อยคือ Win+Space และ Ctrl+Space ขึ้นอยู่กับการตั้งค่า ส่วนบน macOS มักใช้ Control+Space สำหรับสลับ input source เมื่อกำหนดให้ทำหน้าที่นี้ รายละเอียดในแต่ละเครื่องอาจต่างกัน แต่หลักการไม่เปลี่ยน: shortcut สลับภาษาต้องเร็วพอที่จะไม่ตัดกระแสความคิดขณะเขียนโปรแกรม
ถ้าการสลับภาษาช้า พฤติกรรมการทำงานจะเปลี่ยนไป นักพัฒนาอาจเลี่ยงการเขียนคอมเมนต์ไทยที่มีประโยชน์ ผัดผ่อนการเขียนเอกสาร เขียนบันทึกสองภาษาที่ไม่ชัด หรือทิ้งข้อความอังกฤษชั่วคราวไว้จนกลายเป็นถาวร ในทางกลับกัน ถ้าสลับภาษาง่ายแต่ไม่มีวินัย ภาษาไทยก็อาจหลุดเข้าโค้ดได้ เป้าหมายจึงไม่ใช่แค่ความเร็ว แต่เป็นความเร็วที่มีการควบคุม: สลับได้ทันที แต่สลับพร้อมการตัดสินใจว่ากำลังอยู่ในพื้นที่ใด
สลับก่อนเข้าพื้นที่ ไม่ใช่หลังเกิดข้อผิดพลาด
อย่ารอให้พิมพ์ไทยไปแล้วค่อยสลับภาษา ควรสลับที่ขอบเขตของงาน เช่น ก่อนเริ่มคอมเมนต์ ก่อนเริ่มย่อหน้า Markdown ภาษาไทย ก่อนเขียน body ของ commit เป็นภาษาไทย หรือก่อนใส่ localized text แล้วสลับกลับทันทีเมื่อพื้นที่ภาษาไทยจบลง จังหวะที่ควรฝึกคือ เข้าโหมดไทย เขียนหน่วยข้อความไทยให้จบ ออกจากโหมดไทย หน่วยนั้นอาจเป็นคอมเมนต์หนึ่งบรรทัด ประโยคหนึ่งประโยค bullet หนึ่งข้อ หรือย่อหน้าเอกสารหนึ่งย่อหน้า
- วาง cursor ในพื้นที่ที่ปลอดภัยสำหรับภาษาไทย
- สลับเป็นภาษาไทยด้วย shortcut ของระบบ
- พิมพ์หน่วยข้อความไทยให้จบโดยไม่แก้โค้ดรอบข้าง
- สลับกลับเป็นภาษาอังกฤษก่อนพิมพ์ punctuation ที่เป็นส่วนของโค้ด คำสั่ง path หรือ identifier
- ทำงานเขียนโปรแกรมต่อหลังจากยืนยันแล้วว่าสถานะภาษาเป็นภาษาอังกฤษ
ขั้นตอนนี้อาจดูเป็นกลไก แต่ช่วยป้องกันข้อผิดพลาดที่พบบ่อยมาก คือพิมพ์คำอธิบายภาษาไทยเสร็จแล้วพิมพ์ identifier ภาษาอังกฤษต่อทันทีทั้งที่ input method ยังเป็นภาษาไทยอยู่ ยิ่ง cursor ข้ามระหว่างโค้ดกับ prose โดยไม่มีการสลับอย่างตั้งใจน้อยเท่าไร โอกาสมีตัวอักษรหลุดก็ลดลงเท่านั้น
กันไม่ให้ภาษาไทยหลุดเข้าโค้ดโดยไม่ตั้งใจ
ภาษาไทยอาจหลุดเข้าโค้ดได้หลายรูปแบบ กรณีที่เห็นง่ายคือพยัญชนะหรือสระไทยปรากฏอยู่ใน identifier หรือคำสั่ง กรณีที่ละเอียดกว่านั้น เช่น มี ๆ หลุดเข้ามาแทนตัวอักษรละตินที่ตั้งใจพิมพ์ มีเศษประโยคไทยค้างในค่าคอนฟิก หรือมี space ที่กดระหว่างกำลังคิดเป็นภาษาไทยอยู่ในตำแหน่งที่โค้ดคาดหวัง delimiter operator หรือ newline ในหลายสภาพแวดล้อม ปุ่ม space ยังคงใส่ช่องว่างธรรมดา ปัญหาไม่ได้อยู่ที่มีอักขระไทยพิเศษเสมอไป แต่อยู่ที่การพิมพ์ขณะสมองยังอยู่ในโหมด prose
วิธีป้องกันที่ดีคือแยกประเภทของการแก้ไขให้ชัด แก้โค้ดในฐานะโค้ด แล้วเขียนคำอธิบายไทยในฐานะคำอธิบาย หลีกเลี่ยงการแก้โครงสร้างของโค้ดขณะ input method เป็นภาษาไทย ตัวอย่างเช่น หลังพิมพ์คอมเมนต์ไทยแล้ว ให้สลับกลับก่อนใส่วงเล็บปิด comma pipe quote mark command flag หรือ file path แม้อักขระบางอย่างจะพิมพ์ได้ในโหมดไทย การให้ punctuation ของโค้ดอยู่ในช่วงภาษาอังกฤษจะปลอดภัยกว่า
- ค้นหาอักขระไทยก่อน commit เมื่อไฟล์นั้นควรมีเฉพาะโค้ดหรือคอนฟิกที่เครื่องอ่าน
- ตรวจ diff อย่างละเอียดบริเวณ command example, path, JSON, YAML, SQL และ shell script
- ระวังการเปลี่ยนแปลงเพียงหนึ่งตัวอักษรใกล้คอมเมนต์ เพราะอาจเป็นเศษจากสถานะภาษาเดิม
- คงชื่อ branch ชื่อไฟล์ ชื่อแพ็กเกจ และ environment key เป็นภาษาอังกฤษที่คาดเดาได้ เว้นแต่โครงการตั้งใจรองรับชื่อไทย
- ถ้า string ภาษาไทยเป็นสิ่งที่ตั้งใจ ควรทำให้เจตนาชัดจากชื่อตัวแปร ชื่อ test หรือคอมเมนต์รอบข้าง
สำหรับ source file ที่มี string ภาษาไทยอย่างถูกต้อง คำถามตอน review ไม่ควรเป็น “มีภาษาไทยหรือไม่” แต่ควรเป็น “ภาษาไทยอยู่เฉพาะในจุดที่เป็นข้อมูลหรือคำอธิบายหรือไม่” label ที่แปลแล้ว validation message หรือ test fixture อาจถูกต้อง แต่ตัวอักษรไทยใน command option import path หรือ identifier อาจเป็น defect ความแตกต่างนี้สำคัญกว่าชุดอักขระที่ใช้
เขียนไทยในคอมเมนต์ สตริง และ Markdown อย่างปลอดภัย
ภาษาไทยในงานเขียนโปรแกรมควรมีหน้าที่ชัดเจน จุดที่มีคุณค่าสูงคือจุดที่ภาษาไทยอธิบายความรู้เฉพาะโดเมนได้แม่นกว่าอังกฤษ เช่น ศัพท์กฎหมาย ขั้นตอนราชการ คำศัพท์สอบ ข้อความผลิตภัณฑ์ error ที่ผู้ใช้ไทยเห็น สมมติฐานเกี่ยวกับการเรียงลำดับภาษาไทย และ business rule ภายใน คอมเมนต์ภาษาไทยที่ดีควรอธิบายว่าทำไมเงื่อนไขนั้นมีอยู่ ไม่ใช่เพียงทวนว่าโค้ดทำอะไร
ในคอมเมนต์ ควรใช้วลีหรือประโยคไทยที่สมบูรณ์มากกว่าชิ้นส่วนที่ปนกันจนอ่านสะดุด เช่น “ตรวจเฉพาะรายการที่ผ่านการอนุมัติแล้ว” สื่อกฎได้ชัดกว่า “check approved only” เมื่อทีมพูดเรื่องโดเมนนี้เป็นภาษาไทย อย่างไรก็ตาม ควรแยกสัญลักษณ์โค้ดออกจากภาษาเขียนธรรมชาติให้เห็นชัด เขียนคำอธิบายไทยก่อน แล้วอ้างชื่อในโค้ดเท่าที่จำเป็น วิธีนี้ลดความสับสนระหว่างภาษาคนกับ identifier
ใน string literal ภาษาไทยต้องถูกมองเป็นข้อความที่ผู้ใช้เห็นหรือเป็น test data ดังนั้นต้องตรวจคำสะกด ระดับภาษา การขึ้นบรรทัดใหม่ interpolation และ escaping สระนำ เ แ โ ใ ไ ต้องพิมพ์ก่อนพยัญชนะ และลำดับการกดแป้นภายในพยางค์คือ สระนำ พยัญชนะหลัก สระบนหรือล่าง แล้วจึงวรรณยุกต์ สำหรับโปรแกรมเมอร์ เรื่องนี้สำคัญเพราะการแก้ข้อความไทยกลาง string อาจให้ความรู้สึกต่างจากการแก้ข้อความละติน สิ่งที่มองเห็นอยู่หน้าพยัญชนะอาจเป็นสิ่งที่ถูกพิมพ์ก่อนในลำดับแป้น
ใน Markdown ภาษาไทยมักปลอดภัยกว่าใน source code เพราะบริบทหลักเป็น prose แต่ Markdown ก็ยังมี syntax อยู่ดี ควรสลับกลับเป็นอังกฤษก่อนพิมพ์โครงสร้าง เช่น code fence, link, path, front matter key หรือ command example ถ้าเอกสารมีทั้งคำอธิบายภาษาไทยและ code block ให้ถือว่า code block เป็นพื้นที่โค้ด แม้จะอยู่ในเอกสารภาษาไทยก็ตาม
เข้าใจพฤติกรรมการแก้ข้อความไทยใน editor และ terminal
ข้อความไทยไม่ได้ถูกแก้เหมือนข้อความอังกฤษที่หนึ่งตัวอักษรเท่ากับหนึ่งช่องเสมอไป พยางค์ไทยอาจมีพยัญชนะหลัก สระบนหรือล่าง และวรรณยุกต์ สระนำปรากฏทางสายตาหน้าพยัญชนะ แต่ถูกพิมพ์ก่อนพยัญชนะ ในเกษมณี วรรณยุกต์ทั้งสี่กดด้วยนิ้วชี้ขวา: ่ และ ้ อยู่บนแถวเหย้า ส่วน ๊ และ ๋ อยู่บน Shift layer เมื่อต้องพิมพ์อักขระที่อยู่บน Shift layer ให้ใช้กฎ Shift คนละมือ คือกด Shift ด้วยมือฝั่งตรงข้ามกับแป้นที่ต้องการ ไม่ใช้มือเดียวกันกับแป้นนั้น
editor แบบกราฟิกสมัยใหม่และพื้นที่เขียนบน browser มักจัดการภาษาไทยได้พอสมควรสำหรับงานเขียนทั่วไป แต่ปัญหาอาจยังเกิดกับการเลื่อน cursor การเลือกข้อความ การลบ การตัดบรรทัด การ highlight ผลค้นหา หรือการจัดแนวแบบ monospace โปรแกรมใน terminal และ interface ข้อความแบบเรียบง่ายมีโอกาสเจอปัญหามากกว่า เพราะอาจจัดการความกว้างทางสายตา combining mark หรือ column ของ cursor ต่างจาก editor เต็มรูปแบบ พฤติกรรมจริงขึ้นอยู่กับ application, font, operating system และ rendering layer
- ปัญหา cursor: caret อาจเคลื่อนตามลำดับที่เก็บข้อมูล ไม่ใช่หน่วยที่ผู้เขียนมองเห็นเป็นก้อนเดียว
- ปัญหาการลบ: Backspace อาจลบวรรณยุกต์ สระ หรือพยัญชนะหลักในลักษณะที่รู้สึกผิดคาด
- ปัญหาการเลือกข้อความ: การเลือกเพียงบางส่วนของพยางค์ไทยอาจทำให้ข้อความที่ได้ดูไม่สมบูรณ์
- ปัญหาการตัดบรรทัด: บรรทัดแคบอาจตัดตรงจุดที่ดูไม่สวยหรืออ่านยาก
- ปัญหาการจัดแนว: ตารางที่วาดด้วย space อาจจัดแนวไม่ตรงเมื่อผสมภาษาไทยกับละติน
วิธีปฏิบัติที่เหมาะสมคือเลือกพื้นที่เขียนให้เข้ากับงาน เขียนภาษาไทยยาว ๆ ใน editor pane เครื่องมือเอกสาร หรือ web form ที่แสดงผลไทยได้ดี ใช้ terminal สำหรับคำสั่ง output สั้น ๆ และ input ที่ควบคุมได้ หลีกเลี่ยงการแต่ง issue description หรือ commit message ภาษาไทยยาว ๆ ใน editor แบบ terminal ถ้ายังไม่เคยทดสอบว่า cursor movement และการลบทำงานน่าเชื่อถือในสภาพแวดล้อมของตน
สร้างวงจรนิสัยสำหรับ commit และ issue
งาน Git แบบสองภาษาต้องอาศัยรูปแบบที่ทำซ้ำได้ เป้าหมายไม่ใช่การบังคับให้ทุก commit message เป็นไทยหรืออังกฤษทั้งหมด แต่คือทำให้ข้อความอ่านเข้าใจสำหรับผู้รับสารที่คาดหวัง และคง token ที่เครื่องมือใช้ให้เสถียร รูปแบบที่ใช้ได้ดีคือให้หัวข้อ commit สั้น กระชับ และคาดเดาได้ แล้วใช้ body สำหรับคำอธิบายภาษาไทยเมื่อเหตุผลเกี่ยวข้องกับโดเมนเฉพาะ
ตัวอย่างเช่น ทีมอาจเลือก prefix ภาษาอังกฤษอย่าง fix, feat, docs, test หรือ refactor เพราะเข้ากับเครื่องมือและการสแกนด้วยสายตาได้ดี ส่วนที่เหลือของ subject อาจมีภาษาไทยได้ถ้าทีม review เป็นภาษาไทย อีกทีมหนึ่งอาจใช้ subject อังกฤษและ body ไทย ทั้งสองแบบใช้ได้ สิ่งสำคัญคือความสม่ำเสมอ ไม่ใช่การปนภาษาแบบสุ่มในทุกวลี
- เขียนหรือ stage โค้ดโดยคง input method ภาษาอังกฤษไว้
- review diff แล้วดูว่าจำเป็นต้องอธิบายภาษาไทยหรือไม่
- เขียนหัวข้อ commit ตาม convention ของทีม
- สลับเป็นภาษาไทยเฉพาะตอนเขียน body เพื่ออธิบายกฎโดเมน ผลกระทบต่อผู้ใช้ หรือบริบทสำหรับ reviewer
- สลับกลับเป็นภาษาอังกฤษก่อนเขียนเลข issue ชื่อ branch คำสั่ง หรือ reference
- อ่านข้อความสุดท้ายหนึ่งรอบในฐานะ reviewer ไม่ใช่ในฐานะผู้เขียน
การเขียน issue ใช้ตรรกะเดียวกัน ใช้ไทยสำหรับบริบทของปัญหา ขั้นตอนทำซ้ำ expected behavior และผลกระทบทางธุรกิจเมื่อทีมสื่อสารกันเป็นภาษาไทย ใช้อังกฤษสำหรับ command line, stack trace, identifier, endpoint path, package name และ version string ถ้าหนึ่งประโยคมีทั้งสองส่วน ให้แยก machine token ให้เห็นชัด เช่น ใส่เป็น inline code แยกบรรทัด หรือใส่ใน fenced block
ฝึกเกษมณีในบริบทของงานเขียนโปรแกรม
แบบฝึกพิมพ์ไทยทั่วไปมีประโยชน์ แต่โปรแกรมเมอร์ต้องการความคล่องอีกแบบหนึ่ง คือความสามารถในการเข้าและออกจากภาษาไทยโดยไม่ทำให้โครงสร้างทางเทคนิครอบข้างเสีย แบบฝึกจึงควรมีคอมเมนต์ bullet ใน Markdown localized string template ของ issue และ body ของ commit การฝึกไม่ได้มีแค่การขยับนิ้ว แต่รวมถึงวินัยเรื่องสถานะของ input method ด้วย
เกษมณีมีรายละเอียดที่ควรรู้สำหรับงาน prose รอบโค้ด เช่น สระนำต้องพิมพ์ก่อนพยัญชนะ วรรณยุกต์ทั้งสี่กดด้วยนิ้วชี้ขวา และเลขไทยกับเครื่องหมายอย่าง ๆ และ ฿ อยู่บนชั้น Shift ของแถวตัวเลข แต่เมื่อต้องทำงานใกล้โค้ด ทักษะที่สำคัญกว่าคือการตัดสินว่าอักขระนั้นควรอยู่ในพื้นที่ปัจจุบันหรือไม่
- แบบฝึกคอมเมนต์: เขียนคอมเมนต์ไทยหนึ่งบรรทัดเพื่ออธิบาย business rule ที่ไม่ชัด แล้วสลับกลับไปพิมพ์โค้ดบรรทัดถัดไปเป็นอังกฤษ
- แบบฝึกสตริง: พิมพ์ validation message ภาษาไทยสั้น ๆ แล้วแก้หนึ่งคำภายในสตริงโดยไม่ทำให้ quote หรือ interpolation รอบข้างเสีย
- แบบฝึก Markdown: เขียน bullet list ภาษาไทย แล้วตามด้วย command block ภาษาอังกฤษ
- แบบฝึก commit: เขียน subject เป็นอังกฤษและ body เป็นไทย จากนั้นเพิ่ม issue reference ในโหมดภาษาอังกฤษ
- แบบฝึก terminal: พิมพ์เฉพาะคำสั่งอังกฤษ แล้วป้อนหรือวางข้อความไทยเฉพาะภายในโปรแกรมที่คาดหวัง prose input
ระหว่างฝึก อย่าไล่ความเร็วก่อน ให้สังเกตการเปลี่ยนสถานะ การสลับที่สะอาดก่อนและหลังข้อความไทยมีค่ามากกว่าการพิมพ์ไทยเร็วแต่ปล่อยให้ input method ค้างผิดภาษา ความเร็วมีประโยชน์หลังจากนิสัยเรื่องขอบเขตมั่นคงแล้ว
ใช้การตรวจ review สำหรับไฟล์สองภาษา
ไฟล์สองภาษาควรมีรอบ review เพิ่มจากปกติเล็กน้อย code review ทั่วไปตรวจ logic, naming, test, security และ maintainability ส่วน review ที่คำนึงถึงภาษาไทยเพิ่มเรื่องตำแหน่งของข้อความ ความอ่านง่าย และการรั่วของ input method โดยไม่ตั้งใจ สิ่งนี้สำคัญมากในโครงการที่มีภาษาไทยในคอมเมนต์ fixture translation dictionary Markdown และข้อความที่ผู้ใช้เห็น
เริ่มจากดู diff แบบโครงสร้างก่อน ภาษาไทยปรากฏตรงไหน อยู่ในคอมเมนต์ สตริง เอกสาร หรือ test data หรือไม่ จากนั้นตรวจบริเวณขอบของข้อความไทยแต่ละช่วง จุดที่เสี่ยงมักอยู่ก่อนหรือหลังข้อความไทยพอดี เพราะเป็นจุดที่ผู้เขียนสลับ input method ให้มองหาสัญลักษณ์ผิดคาด punctuation ที่เสีย quote ที่ไม่ครบ เครื่องหมายซ้ำโดยไม่ตั้งใจ และโค้ดที่เปลี่ยนไปโดยไม่มีเหตุผลชัดเจน
- สำหรับคอมเมนต์: ตรวจว่าภาษาไทยอธิบายเจตนา ไม่ใช่ทวน syntax
- สำหรับสตริง: ตรวจถ้อยคำที่ผู้ใช้เห็น escaping interpolation และการขึ้นบรรทัดใหม่
- สำหรับ Markdown: ตรวจว่าหัวข้อ bullet code fence และ link render ตามที่ต้องการ
- สำหรับคอนฟิก: ยืนยันว่าภาษาไทยอยู่เฉพาะใน value ที่รองรับข้อมูลไทยได้
- สำหรับคำสั่ง terminal: คัดลอกคำสั่งไปทดสอบในสภาพแวดล้อมที่ปลอดภัยก่อนเผยแพร่
การค้นหาภาษาไทยในไฟล์ช่วยได้ แต่ไม่ควรแทนการตัดสินใจของมนุษย์ การพบอักขระไทยใน repository ไม่ได้แปลว่าผิดโดยอัตโนมัติ ต้องจำแนกแต่ละตำแหน่ง ภาษาไทยใน privacy notice อาจจำเป็น ภาษาไทยใน shell command อาจผิด ภาษาไทยใน test fixture อาจมีประโยชน์ ภาษาไทยในชื่อ environment variable อาจเปราะบาง หน้าที่ของ reviewer คือแยกให้ออกว่าข้อความนั้นเป็นการสื่อสารกับมนุษย์หรือเป็นสิ่งที่เครื่องต้องตีความ
เวิร์กโฟลว์ประจำวันที่ใช้ได้จริง
ระบบพิมพ์สองภาษาที่น่าเชื่อถือที่สุดต้องง่ายพอให้ใช้ทุกวัน เริ่ม session เขียนโค้ดด้วยสมมติฐานว่า input method เป็นภาษาอังกฤษ สลับเป็นไทยเฉพาะหลัง cursor อยู่ในพื้นที่ที่ปลอดภัยสำหรับภาษาไทย เขียนหน่วยข้อความไทยให้จบ สลับกลับก่อนออกจากพื้นที่นั้น ตรวจขอบเขต แล้วทำซ้ำ วงจรเล็ก ๆ นี้ช่วยรักษาทั้งความถูกต้องของโค้ดและความอ่านง่ายของภาษาไทย
สำหรับงานเอกสารยาว ให้แบ่งหน้าออกเป็นพื้นที่ prose และพื้นที่ syntax ข้อความอธิบายภาษาไทยสามารถร่างต่อเนื่องได้ แต่ code block, command, path, package name และ configuration key ทุกครั้งควรกระตุ้นให้ตรวจว่า input method กลับเป็นอังกฤษแล้ว สำหรับงาน Git ให้เลือก convention ของทีมสำหรับ subject และ body แล้วใช้ให้สม่ำเสมอ สำหรับงาน terminal อย่าแต่งข้อความไทยยาว ๆ ใน interface ที่เปราะบางเมื่อมี editor ที่เหมาะกว่าพร้อมใช้งาน
ดังนั้น การพิมพ์ไทยแบบสัมผัสสำหรับโปรแกรมเมอร์จึงไม่ใช่แค่ muscle memory ของเกษมณี แต่คือการควบคุมว่าภาษาไทยควรอยู่ตรงไหนในกระบวนการพัฒนา นักพัฒนาที่สลับภาษาได้เร็ว พิมพ์ไทยได้แม่น และ review ขอบเขตสองภาษาได้ดี จะเขียนคอมเมนต์ชัดขึ้น ทำเอกสารดีขึ้น และรักษาโค้ดให้ปลอดภัยขึ้น ทักษะแป้นพิมพ์กับนิสัยทางวิศวกรรมจึงเสริมกัน: อย่างหนึ่งทำให้การป้อนภาษาไทยลื่นไหล อีกอย่างทำให้โปรแกรมยังตีความได้ไม่กำกวม
คู่มือที่เกี่ยวข้อง
คู่มือฝึกลำดับอักขระไทยสองตัวและสามตัวที่พบบ่อยบนผังเกษมณี แทนที่จะฝึกเฉพาะแป้นเดี่ยวหรือคำเต็ม บทความนี้แสดงวิธีฝึกจังหวะส่งต่อของนิ้วที่ทำให้การพิมพ์ไทยไหลลื่นขึ้น
สำรวจวิธีการจัดเก็บพยางค์ภาษาไทยในรูปแบบโค้ดพอยต์เส้นตรงแทนที่จะเป็นกลุ่มตัวอักษรที่มองเห็น พร้อมเรียนรู้กลยุทธ์การใช้งานเคอร์เซอร์ ปุ่ม Backspace และการแก้ไขคำผิดอย่างมีประสิทธิภาพ
คู่มือสำหรับผู้ใช้คีย์บอร์ด mechanical หรือ laptop ที่ไม่มีตัวอักษรไทยบนแป้น เปรียบเทียบคีย์แคปไทย สติกเกอร์ แผ่นคลุม และการใช้แป้นไม่มีสัญลักษณ์ เพื่อเลือกแบบที่ช่วยฝึกพิมพ์สัมผัสจริง ไม่ใช่ฝึกก้มมองแป้น