การเขียนโค้ดแบบตายตัว (Hard coding)คือแนวทางการพัฒนาซอฟต์แวร์ที่ฝังข้อมูลลงในซอร์สโค้ดของโปรแกรมหรือวัตถุที่สามารถทำงานได้โดยตรง แทนที่จะดึงข้อมูลจากแหล่งภายนอกหรือสร้างข้อมูลขึ้นมาในระหว่างการทำงานของโปรแกรม

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

ข้อมูลที่กำหนดค่าตายตัวนั้นเหมาะสมที่สุดสำหรับข้อมูลที่ไม่เปลี่ยนแปลง เช่นค่าคงที่ทางกายภาพหมายเลขเวอร์ชันและองค์ประกอบข้อความคงที่

ในทางกลับกัน ข้อมูลที่เข้ารหัสแบบอ่อน (Soft-coded data) จะเข้ารหัสข้อมูลใดๆ ก็ได้ผ่านทางข้อมูลที่ผู้ใช้ป้อนไฟล์ข้อความไฟล์INIการตอบสนองจากเซิร์ฟเวอร์ HTTP ไฟล์การกำหนดค่า มาโครพรีโปรเซสเซอร์ ค่าคงที่ภายนอก ฐานข้อมูล อาร์กิวเมนต์บรรทัดคำสั่งและจะถูกกำหนดในระหว่างการทำงานของโปรแกรม

การเขียนโค้ดแบบตายตัวทำให้ต้องเปลี่ยนซอร์สโค้ดของโปรแกรมทุกครั้งที่ข้อมูลอินพุตหรือรูปแบบที่ต้องการเปลี่ยนแปลง ซึ่งอาจสะดวกกว่าสำหรับผู้ใช้ปลายทางที่จะเปลี่ยนรายละเอียดด้วยวิธีการบางอย่างนอกโปรแกรม^{[ 1 ]}

การเขียนโค้ดแบบตายตัวมักจำเป็น แต่ก็อาจถือเป็นรูปแบบที่ไม่เหมาะสมได้เช่น กัน ^{[ 2 ]} โปรแกรมเมอร์อาจยังไม่ได้สร้างโซลูชันส่วนติดต่อผู้ใช้แบบไดนามิกสำหรับผู้ใช้ปลายทาง แต่ยังคงต้องส่งมอบฟีเจอร์หรือปล่อยโปรแกรมออกมา ซึ่งโดยปกติแล้วจะเป็นเพียงชั่วคราว แต่ก็ช่วยแก้ไขแรงกดดันในการส่งมอบโค้ดในระยะสั้นได้ ต่อมาจึงทำการเขียนโค้ดแบบอ่อนตัวเพื่อให้ผู้ใช้สามารถส่งพารามิเตอร์ที่ช่วยให้ผู้ใช้ปลายทางสามารถแก้ไขผลลัพธ์หรือผลที่ได้

คำว่า "hard-coded" เดิมทีถูกใช้เป็นคำอุปมากับการต่อสายวงจรไฟฟ้าแบบตายตัว เพื่อสื่อถึงความไม่ยืดหยุ่นที่เกิดจากการใช้งานในงานออกแบบและพัฒนาซอฟต์แวร์ ในบริบทของสภาพแวดล้อมการพัฒนาร่วมกันที่ สามารถขยายได้ในขณะทำงาน เช่นเกม MUDการเขียนโค้ดแบบ hard-coded ยังหมายถึงการพัฒนากลไกหลักของระบบที่รับผิดชอบงานระดับต่ำและการเรียกใช้สคริปต์ซึ่งแตกต่างจาก การเขียน โค้ดแบบ soft-codedที่พัฒนาสคริปต์ระดับสูงซึ่งระบบจะตีความในขณะทำงานโดยใช้ค่าจากแหล่งภายนอก เช่นไฟล์ข้อความไฟล์ INI มาโครพรีโปรเซสเซอร์ค่าคงที่ภายนอกฐานข้อมูล อาร์กิวเมนต์บรรทัดคำสั่งการตอบสนองของเซิร์ฟเวอร์HTTP ไฟล์การกำหนดค่าและข้อมูลที่ผู้ใช้ป้อนในกรณีนี้ คำนี้ไม่ได้มีความหมายเชิงลบ แต่หมายถึงการพัฒนาโดยทั่วไป มากกว่าการฝังข้อมูลเอาต์พุตโดยเฉพาะ

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

เพื่อเป็น มาตรการ จัดการสิทธิ์ดิจิทัล (DRM) นักพัฒนาซอฟต์แวร์อาจกำหนดหมายเลขประจำเครื่องที่ ไม่ซ้ำกัน ลงในโปรแกรมโดยตรง หรืออาจกำหนดรหัสสาธารณะ ไว้โดยตรง ซึ่งเป็นการ สร้าง DRM ที่ไม่สามารถสร้างโปรแกรมสร้างรหัส (keygen) ได้

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

หากโปรแกรม Windows ถูกตั้งค่าให้ติดตั้งลงในไดรฟ์ C:\Program Files\Appname เสมอ และมีผู้ใช้พยายามติดตั้งลงในไดรฟ์อื่นด้วยเหตุผลด้านพื้นที่ว่างหรือการจัดระเบียบ อาจทำให้การติดตั้งล้มเหลวหรือใช้งานไม่ได้หลังจากติดตั้งเสร็จ ปัญหานี้อาจไม่ถูกตรวจพบในระหว่างการทดสอบ เนื่องจากผู้ใช้โดยเฉลี่ยจะติดตั้งลงในไดรฟ์และไดเร็กทอรีเริ่มต้น และการทดสอบอาจไม่มีตัวเลือกในการเปลี่ยนไดเร็กทอรีการติดตั้ง อย่างไรก็ตาม โปรแกรมเมอร์และนักพัฒนาควรหลีกเลี่ยงการกำหนดเส้นทางการติดตั้งของโปรแกรมให้ตายตัว เนื่องจากเส้นทางการติดตั้งเริ่มต้นขึ้นอยู่กับระบบปฏิบัติการ เวอร์ชันของระบบปฏิบัติการ และ การตัดสินใจ ของผู้ดูแลระบบตัวอย่างเช่น การติดตั้งMicrosoft Windows จำนวนมาก ใช้ไดรฟ์ C: เป็น ฮาร์ดดิสก์หลักแต่ก็ไม่รับประกันว่าจะใช้แบบนั้นเสมอไป

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

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

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

ระบบปฏิบัติการ Windows บางระบบมีสิ่งที่เรียกว่าโฟลเดอร์พิเศษซึ่งจัดระเบียบไฟล์อย่างเป็นระบบบนฮาร์ดดิสก์ อย่างไรก็ตาม การกำหนดโฟลเดอร์แบบตายตัวอาจก่อให้เกิดปัญหาได้:

โปรแกรม Windows บางโปรแกรมจะกำหนดเส้นทางของไฟล์โปรไฟล์ไว้ในตำแหน่งที่นักพัฒนากำหนดเอง เช่นนี่คือเส้นทางที่ใช้กันทั่วไปในWindows 2000หรือเวอร์ชันที่สูงกว่า แต่จะทำให้เกิดข้อผิดพลาดหากไฟล์โปรไฟล์ถูกจัดเก็บไว้บนเครือข่ายหรืออยู่ในตำแหน่งอื่น วิธีที่ถูกต้องในการดึงไฟล์โปรไฟล์คือการเรียกใช้ฟังก์ชัน หรือตรวจสอบตัวแปรสภาพแวดล้อมอีกสมมติฐานหนึ่งที่นักพัฒนามักใช้คือ ไฟล์โปรไฟล์นั้นอยู่บนฮาร์ดดิสก์ภายในเครื่อง C:\Documents and Settings\UsernameGetUserProfileDirectory%userprofile%

โปรแกรม Windows บางโปรแกรมกำหนดพาธไปMy Documentsยัง โฟลเดอร์นี้แบบตายตัว ProfilePath\My Documentsโปรแกรมเหล่านี้จะทำงานได้บนเครื่องที่ใช้ Windows เวอร์ชันภาษาอังกฤษ แต่ใน Windows เวอร์ชัน ภาษาอื่นๆโฟลเดอร์นี้มักจะมีชื่อแตกต่างกัน ตัวอย่างเช่น ในเวอร์ชันภาษาอิตาลี โฟลเดอร์นี้มีชื่อว่า Documenti นอกจากนี้ โฟลเดอร์นี้อาจMy Documentsถูกย้ายMy Documentsตำแหน่งโดยใช้การเปลี่ยนเส้นทางโฟลเดอร์ (Folder Redirection) ในนโยบายกลุ่ม (Group Policy)ใน Windows 2000 หรือเวอร์ชันที่สูงกว่า วิธีที่ถูกต้องในการเรียกใช้งานคือการเรียกSHGetFolderPathใช้ฟังก์ชัน

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

การเขียนโค้ดแบบตายตัวนั้นเป็นปัญหาอย่างยิ่งในการเตรียมซอฟต์แวร์สำหรับการแปลเป็นภาษาอื่นๆ

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

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

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

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

ซอฟต์โค้ดดิ้ง (Soft coding)เป็น ศัพท์ทางด้าน การเขียนโปรแกรมคอมพิวเตอร์ที่หมายถึงการดึงค่าหรือฟังก์ชันจากแหล่งข้อมูลภายนอก เช่นไฟล์ข้อความไฟล์INI มาโครพรีโปรเซสเซอร์ ค่าคงที่ภายนอกไฟล์การกำหนดค่าอาร์กิวเมนต์บรรทัดคำสั่งฐานข้อมูล ข้อมูลที่ผู้ใช้ป้อน การตอบสนองจากเซิร์ฟเวอร์ HTTP ซึ่งตรงข้ามกับฮาร์ดโค้ดดิ้ง (Hard coding) ที่หมายถึงการเขียนค่าและฟังก์ชันลงในซอร์สโค้ดโดยตรง

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

โดยทั่วไปแล้ว คำนี้จะใช้ในกรณีที่การเขียนโค้ดแบบอ่อนกลายเป็นรูปแบบที่ไม่พึงประสงค์ การสรุปค่าและคุณสมบัติมากเกินไปอาจทำให้เกิดความซับซ้อนและปัญหาในการบำรุงรักษามากกว่าการเปลี่ยนแปลงโค้ดเมื่อจำเป็น การเขียนโค้ดแบบอ่อนในความหมายนี้ ได้รับการกล่าวถึงในบทความในThe Daily WTF ^{[ 3 ]}

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

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

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

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

• ซอฟต์แวร์ปิดแหล่งที่มา
• เฟิร์มแวร์
• เอฟเฟกต์แพลตฟอร์มภายใน
• หลักแห่งอำนาจน้อยที่สุด
• รหัสที่แก้ไขตัวเองได้