ทีมพัฒนาภาษา C# จาก Microsoft ปล่อยภาษารุ่นต้นแบบ (prototype) มาทดลองความสามารถสำหรับลดปริมาณปัญหาที่เกี่ยวกับ null โดยเฉพาะ ด้วยการเพิ่มชนิดข้อมูลใหม่ (type) ที่คล้ายกันภายใต้ชื่อว่า nullable มาให้เลือกใช้งาน
ผู้สนใจสามารถดาวน์โหลดความสามารถนี้มาทดลองเล่นได้ผ่าน GitHub
ส่วนใครสงสัยว่า nullable คืออะไร มีบทบาทอย่างไรในการแก้บั๊ก เชิญอ่านต่อข้างในได้เลย
ย้อนกลับไปยังปี 1965 ซึ่งยังเป็นช่วงของการวางรากฐานให้ภาษาโปรแกรมในทุกวันนี้ (ภาษาที่เราคุ้นเคยกันอย่าง C ปรากฏตัวขึ้นภายหลังในปี 1972) ในขณะนั้นคุณ Tony Hoare กำลังพัฒนาภาษา ALGOL W ซึ่งเป็นภาษาเชิงวัตถุ (Object-Oriented Programming) ได้เกิดความคิดสุดบรรเจิด สร้าง null ขึ้นมาเพื่อเก็บการอ้างอิง (reference) ถึงวัตถุที่ไม่ปรากฏ
ความเรียบง่ายดูไร้พิษภัยของมันส่งผลให้ภาษาโปรแกรมอื่นๆ ดำเนินรอยตาม เพียงเพื่อจะมาพบภายหลังว่ามันเป็นต้นเหตุของข้อผิดพลาดจำนวนมหาศาล จนคุณ Hoare เรียกมันว่า "ความผิดพลาดพันล้านดอลลาร์" และออกมาขอโทษหลังจากตระหนักได้ในภายหลัง
ความผิดพลาดอันยิ่งใหญ่ของ null อาจกล่าวได้ว่าเกิดจากความไม่ชัดเจนในเจตนาของมัน เพราะค่า null อาจถูกตีความได้ว่าวัตถุนั้นยังไม่ได้กำหนดค่า (และใช้ค่า null เป็นค่าปริยายไปก่อน) หรือค่า null อาจหมายความว่าวัตถุนั้นไม่มีค่าจริงๆ ก็ย่อมได้
เมื่อ null สามารถมีได้หลายเจตนา แต่ไม่มีสิ่งใดกำกับเจตนาเหล่านั้นอย่างชัดแจ้ง หลายๆ ครั้งนักพัฒนาจึงหลงลืมที่จะต้องตรวจสอบค่า null และส่งผลให้เกิด NullReferenceException
ในที่สุด
โชคยังดีที่บางภาษาอย่างเช่น 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 ขัดกับชนิดข้อมูล โดยมีรายละเอียดดังนี้
person.Nickname
มีชนิดข้อมูลเป็น nullable ซึ่งยินยอมให้มีค่าเป็น null ได้ จึงไม่ควรเรียกใช้สมบัติต่างๆ ของตัวแปร (เช่น .Length
) โดยไม่ตรวจสอบก่อนว่าตัวแปรดังกล่าวกำลังเก็บค่า null หรือไม่person = GetAnotherPerson()
) ซึ่งอาจทำให้ตัวแปร person.Nickname
กลับไปมีค่าเป็น null ได้อีกครั้ง แม้จะมีการตรวจสอบค่ามาก่อนแล้วก็ตาม!
ต่อท้ายชื่อตัวแปรเพื่อซ่อนคำเตือนในบรรทัดนั้นๆ ได้person.RealName
มีชนิดข้อมูลเป็น non-nullable จึงไม่ควรตั้งค่าตัวแปรด้วย nulldefault(string)
คือ null!
ต่อท้ายเช่นกันกระบวนการนี้ยังมีข้อจำกัดอยู่บ้าง เช่น จากคำเตือนที่ 2 หากบรรทัดก่อนหน้าไม่ได้นำวัตถุใหม่มาเก็บในตัวแปรเดิม แต่เป็นการแก้ค่าในวัตถุเดิม (อาจเรียก person.ResetFields()
) คอมไพเลอร์จะไม่สามารถตรวจตรงนี้ได้
เมื่อเปิดใช้ความสามารถนี้บนโค้ดเดิม ตัวแปรทุกตัวจะถูกมองว่าเป็น non-nullable ตั้งแต่เริ่ม คำเตือนการใช้ null จากการคอมไพล์รอบแรกจะทำให้ต้องตัดสินใจว่า
หลังจากแก้ไขโค้ดโดยบอกว่าตัวแปรใดเป็น nullable และคอมไพล์อีกรอบ ก็ถึงระลอกสองของคำเตือนใหม่ๆ ที่อาจโผล่ขึ้นมาแทน ซึ่งจะเกี่ยวกับการใช้ตัวแปรโดยลืมตรวจสอบว่าเป็น null หรือไม่นั่นเอง
แน่นอนว่าโปรแกรมใดๆ ย่อมไม่ได้ประกอบด้วยโค้ดที่เขียนเองอย่างเดียว แต่ยังพึ่งพิงไลบรารีภายนอกอีกมากมาย สำหรับไลบรารีที่แก้ไขโค้ดให้รองรับชนิดข้อมูลแบบ nullable แล้ว ก็ถือว่าโชคดีที่จะได้เห็นคำเตือนการใช้ null ในโค้ดตนเองที่ผิดพลาดจริงๆ แต่สำหรับไลบรารีที่ยังไม่แก้ไขโค้ดให้รองรับความสามารถนี้ ทีมพัฒนาภาษา C# บอกว่าให้ใช้ !
ในโค้ดตนเองเพื่อซ่อนข้อผิดพลาดจากคอมไพเลอร์ไปก่อน
เรียบเรียงจาก: .NET Blog
Comments
+1
ภาษาที่ไม่ต้องกำหนดชนิดตัวแปร(กำหนดได้น้อย) เช่น Javascript หรือ PHP คงลำบากกันต่อไป
ดีครับผมใช้ใน Swift, Kotlin ชอบมาก
? ใช้มาสักพักละนึกว่ามีนานแล้ว entity framework นิเพียบ...
อันนั้นเป็น Nullable Value-Type แต่อันใหม่เป็น Nullable Reference Type ครับ
ใช้แก้ปัญหาเวลาอยากจะประกาศตัวแปรที่เป็น Reference Type บางตัวอยากให้เป็น null ได้ก็ต้องใส่ ?
ตัวไหนไม่ได้ใส่ ? ก็แสดงว่าเป็น non-nullable จะโดน compile ไล่เบี้ยว่าใน code ตรงไหนแอบ assign null รึเปล่า ถ้าเจอก็จะโผล่เป็น error/warning
อ๋อผมคงโฟกัส ? อ่านดีๆด็อย่างที่ท่านว่าขอบคุณครับ
ปล หลุดพ้นจาก NullReferenceException แล้ว :D
ปกติผมไม่ค่อย assign null นะครับ เน้นใช้ constructor ช่วย
ถ้า ? ที่เป็นตัวแปร null ได้นั้น ผมใช้มานานแล้วหละครับ มันมีมานานแล้ว ปัจจุบันก็ยังใช้อยู่เหมือนกันครับ
อ่านดูแล้วรู้สึกเป็นความหวังดีที่อันตรายไปหน่อย
เหมือนกับบอกว่า "ไม่ต้องห่วงเรื่อง null นะ เรามีวิธีใหม่ช่วยตรวจสอบให้แล้ว" แต่ที่จริงก็ยังมีช่องโหว่ที่ไม่สามารถช่วยได้จริงๆ จะกลายเป็นหลุดรั่วไปเลยโดยที่คนเขียนไม่ได้คิดจะใส่ใจเลย
ผมว่าบังคับหรือสร้างวินัยให้ programmer handle exception ใดๆ ด้วยตัวเองจะเหมาะกว่า เพราะนอกจาก null แล้วยังมี runtime exception อีกตั้งหลายอย่าง เช่น array index out of bound, unparsable string เป็นต้น
อ่า... ไม่แน่ใจว่าย่อหน้านี้ผมเขียนอะไรตกหล่นไปหรือเปล่าครับ?
ผมเห็นด้วยเรื่องวินัยของโปรแกรมเมอร์นะ แต่วินัยไม่ใช่สิ่งที่จะสร้างกันได้ในชั่วข้ามคืนผ่านการอบรมสั่งสอนเพียงอย่างเดียวหนิครับ การสร้างวินัยมันต้องมีภาคปฏิบัติด้วย และถ้าภาคฏิบัติมันมีเครื่องมืออะไรมาช่วยบังคับให้เกิดวินัยตรงนี้ มันก็น่าเป็นเรื่องยินดีไม่ใช่หรือ?
หรือคุณจะบอกว่าเครื่องมือพวกนี้มันหาดีไม่ได้ ห้ามใช้มันนะมาฝึกวินัยโดยใช้สายตาอ่านโค้ดเพียงอย่างเดียว แล้วก็เรียนรู้เอาว่าตนเองพลาดตอนไหนจาก feedback ลูกค้าเท่านั้น?
อันนี้คือแค่ช่วยเช็คไม่ใช่หรอ.. คือจะถือว่าตัวแปรที่เขียนโค้ดแบบก่อนๆ หน้านี้ เป็นตัวแปรแบบไม่ควรยุ่งเกี่ยวกับ null, ดังนั้นจุดไหนที่มีโอกาสยุ่งกับค่า null ก็จะเจอแจ้งเตือนตอนคอมไพล ขณะที่ของเดิมนั้นจะไปรู้ตอน runtime
ใน C# ผมยังคงเล่นกับ null ในระบบใหญ่ๆของผมครับ พอเข้าใจมันก็ใช้งานได้อน่างไม่มีปัญหา ก็ใช้มาจะสิบปีแล้ว
เช่น int ?MemberID
และที่ใช้ย่อยคือ ?date ก่อนจะใช้ก็เชคว่า null หรือเปล่า ถ้า null ก็ไม่ต้องทำ พอจะทพก็ cast เอา ตอนนี้ยังคงใช้ได้ดีอยู่แบบไม่มีปัญหา แต่เท่าที่อ่านน่าจะปัญหาของการ reference อันนี้อ่านจาก comment
ยิ่งมีการตรวจสอบเยอะๆ (ตรวจสอบว่าเป็น Null) โปรแกรมยิ่งช้าครับ
C# application เก่าๆ ที่พัฒนา ถ้า upgrade version มีหนาวแน่นอน แก้ null กันมัน
เกรงว่าจะสั่งปิดแล้วลืมยาวๆ ไม่เปิดอีกเลย ?
งาน embedded ผมขาดมันไปไม่ได้เลยนะนั่น อย่างรับค่าพวก GPS ต้องเช็คแบบละเอียดยิบ แม้แต่วันที่หากแปลง NMEA ไม่ได้(มี noise)ก็จะส่ง null กลับมา (DateTime?) จะเข้าเงื่อนไขแต่ละทีนี่เช็คตลอด
เนา นู นุน นัน ได้ยินคนอื่นเรียกแทบไม่เหมือนกันเลย
ค่า เน่า ?