มีปัญหากับ null ใน C# อยู่หรือ? ตรวจมันด้วยความสามารถใหม่อย่าง nullable สิ

ทีมพัฒนาภาษา C# จาก Microsoft ปล่อยภาษารุ่นต้นแบบ (prototype) มาทดลองความสามารถสำหรับลดปริมาณปัญหาที่เกี่ยวกับ null โดยเฉพาะ ด้วยการเพิ่มชนิดข้อมูลใหม่ (type) ที่คล้ายกันภายใต้ชื่อว่า nullable มาให้เลือกใช้งาน

ผู้สนใจสามารถดาวน์โหลดความสามารถนี้มาทดลองเล่นได้ผ่าน GitHub

ส่วนใครสงสัยว่า nullable คืออะไร มีบทบาทอย่างไรในการแก้บั๊ก เชิญอ่านต่อข้างในได้เลย

null คืออะไร ทำไมถึงก่อปัญหาได้อย่างมากมายยิ่งนัก?

ย้อนกลับไปยังปี 1965 ซึ่งยังเป็นช่วงของการวางรากฐานให้ภาษาโปรแกรมในทุกวันนี้ (ภาษาที่เราคุ้นเคยกันอย่าง C ปรากฏตัวขึ้นภายหลังในปี 1972) ในขณะนั้นคุณ Tony Hoare กำลังพัฒนาภาษา ALGOL W ซึ่งเป็นภาษาเชิงวัตถุ (Object-Oriented Programming) ได้เกิดความคิดสุดบรรเจิด สร้าง null ขึ้นมาเพื่อเก็บการอ้างอิง (reference) ถึงวัตถุที่ไม่ปรากฏ

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

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

เมื่อ null สามารถมีได้หลายเจตนา แต่ไม่มีสิ่งใดกำกับเจตนาเหล่านั้นอย่างชัดแจ้ง หลายๆ ครั้งนักพัฒนาจึงหลงลืมที่จะต้องตรวจสอบค่า null และส่งผลให้เกิด NullReferenceException ในที่สุด

การมาถึงของ nullable เพื่อแก้ปัญหาดังกล่าว

โชคยังดีที่บางภาษาอย่างเช่น ML, Haskell, F# เห็นถึงข้อจำกัดเหล่านี้และนำระบบชนิดข้อมูลแบบตัวเลือก (option type) มาใช้แทน ซึ่งบังคับให้แสดงค่าด้วย None เมื่อไม่มีวัตถุ หรือแสดงค่าด้วย Some(T) เมื่อมีวัตถุในชนิดข้อมูล T นี่หมายความว่านักพัฒนาที่เลือกเขียนภาษาเหล่านี้จะถูกบังคับให้เช็คค่า null ทุกครั้งนั่นเอง (ซึ่งก็ไม่ได้ยากเย็นอะไรเพราะภาษาเหล่านั้นมักมีการจับคู่รูปแบบ (pattern matching) มาให้อยู่แล้ว)

แม้ว่า C# จะไม่มีชนิดข้อมูลแบบตัวเลือกเฉกเช่นภาษาเหล่านั้น แต่ตัวอย่างข้างต้นก็ชี้ให้เห็นถึงแนวทางในการแก้ไขปัญหาดังกล่าว ทีมพัฒนาภาษา C# เลือกที่จะอนุรักษ์การเขียนโค้ดรูปแบบดั้งเดิมไว้โดยไม่พัฒนา None และ Some(T) ที่ยุ่งยากขึ้นมาใช้ แต่แนะนำชนิดข้อมูลใหม่ในชื่อ nullable ขึ้นมาแทน (ประกาศตัวแปรได้ด้วยการนำ ? ไปต่อท้ายชื่อชนิดข้อมูลเดิม) วัตถุที่เก็บในตัวแปรนี้สามารถมีค่าเป็น null ได้ (และในทำนองเดียวกันชนิดข้อมูลที่ไม่มีเครื่องหมาย ? ต่อท้ายจะเป็นชนิดข้อมูลแบบ non-nullable ที่ไม่สามารถเก็บค่า null ได้)

class Person {
    public string RealName;
    public string? Nickname;
}

โค้ดที่ 1: คลาสบุคคลแบบเรียบง่ายที่มีเพียง 2 สมบัติอันได้แก่ชื่อจริงและชื่อเล่น

จากตัวอย่างในโค้ดที่ 1 ซึ่งนิยามคลาสบุคคลที่ประกอบด้วย 2 สมบัติ (property) จะเห็นว่า

• ชื่อจริง (RealName) มีชนิดข้อมูลเป็น non-nullable string สามารถเก็บได้เพียงข้อมูลตัวอักษร ไม่สามารถเก็บค่า null ได้
• ชื่อเล่น (Nickname) มีชนิดข้อมูลเป็น nullable string สามารถเก็บข้อมูลตัวอักษรหรือค่าที่เป็น null ก็ได้

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

void DoSomething(Person person) {
    WriteLine(person.Nickname.Length);       // WARNING #1
    if (person.Nickname != null) {
        WriteLine(person.Nickname.Length);   // ok
        person = GetAnotherPerson();
        WriteLine(person.Nickname.Length);   // WARNING #2
        WriteLine(person.Nickname!.Length);  // ok #3
    }
}

โค้ดที่ 2: คำเตือนเมื่อทำงานกับชนิดข้อมูล nullable

void DoSomething(Person person) {
    person.RealName = null;                  // WARNING #4
    person.RealName = default(string);       // WARNING #5
    person.RealName = person.Nickname;       // WARNING #6
    person.RealName = null!;                 // ok #7
}

โค้ด 3: คำเตือนเมื่อทำงานกับชนิดข้อมูล non-nullable

จากโค้ดที่ 2 และ 3 ซึ่งแสดงตัวอย่างคำเตือนที่จะเกิดขึ้นเมื่อใช้งาน null ขัดกับชนิดข้อมูล โดยมีรายละเอียดดังนี้

1. ตัวแปร person.Nickname มีชนิดข้อมูลเป็น nullable ซึ่งยินยอมให้มีค่าเป็น null ได้ จึงไม่ควรเรียกใช้สมบัติต่างๆ ของตัวแปร (เช่น .Length) โดยไม่ตรวจสอบก่อนว่าตัวแปรดังกล่าวกำลังเก็บค่า null หรือไม่
2. เกิดการเปลี่ยนค่าตัวแปรขึ้นในบรรทัดที่ผ่านมา (person = GetAnotherPerson()) ซึ่งอาจทำให้ตัวแปร person.Nickname กลับไปมีค่าเป็น null ได้อีกครั้ง แม้จะมีการตรวจสอบค่ามาก่อนแล้วก็ตาม
3. หากมั่นใจว่าตัวแปรดังกล่าวไม่มีทางเป็น null และไม่ต้องการเห็นคำเตือนจากคอมไพเลอร์ สามารถใช้เครื่องหมาย ! ต่อท้ายชื่อตัวแปรเพื่อซ่อนคำเตือนในบรรทัดนั้นๆ ได้
4. ตัวแปร person.RealName มีชนิดข้อมูลเป็น non-nullable จึงไม่ควรตั้งค่าตัวแปรด้วย null
5. ค่าของ default(string) คือ null
6. ไม่ควรนำค่าจากตัวแปรที่ใช้ชนิดข้อมูล nullable มาตั้งค่าให้ตัวแปรที่ใช้ชนิดข้อมูล non-nullable
7. แม้ตัวแปรดังกล่าวไม่ควรเป็น null แต่หากต้องการเก็บค่า null ในตัวแปรนั้นจริงๆ โดยไม่ต้องการเห็นคำเตือนจากคอมไพเลอร์ ก็ยังสามารถทำได้โดยเติม ! ต่อท้ายเช่นกัน

กระบวนการนี้ยังมีข้อจำกัดอยู่บ้าง เช่น จากคำเตือนที่ 2 หากบรรทัดก่อนหน้าไม่ได้นำวัตถุใหม่มาเก็บในตัวแปรเดิม แต่เป็นการแก้ค่าในวัตถุเดิม (อาจเรียก person.ResetFields()) คอมไพเลอร์จะไม่สามารถตรวจตรงนี้ได้

คำแนะนำเพื่อการปรับใช้ nullable กับโปรแกรมที่มีอยู่

เมื่อเปิดใช้ความสามารถนี้บนโค้ดเดิม ตัวแปรทุกตัวจะถูกมองว่าเป็น non-nullable ตั้งแต่เริ่ม คำเตือนการใช้ null จากการคอมไพล์รอบแรกจะทำให้ต้องตัดสินใจว่า

1. พลาดตั้งค่า null ให้กับตัวแปรที่ไม่ควรเป็น null นี่คือบั๊กที่รอวันเกิดและต้องได้รับการแก้ไขโดยเปลี่ยนค่าตัวแปรให้ไม่เป็น null
2. ตัวแปรนั้นสามารถมีค่าเป็น null ได้ ควรเปลี่ยนชนิดข้อมูลให้เป็น nullable

หลังจากแก้ไขโค้ดโดยบอกว่าตัวแปรใดเป็น nullable และคอมไพล์อีกรอบ ก็ถึงระลอกสองของคำเตือนใหม่ๆ ที่อาจโผล่ขึ้นมาแทน ซึ่งจะเกี่ยวกับการใช้ตัวแปรโดยลืมตรวจสอบว่าเป็น null หรือไม่นั่นเอง

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

เรียบเรียงจาก: .NET Blog