Tags:
Node Thumbnail

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

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

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

No Description

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

Get latest news from Blognone

Comments

By: sukjai
iPhoneAndroidRed HatUbuntu
on 22 November 2017 - 21:20 #1020516

+1

By: syootakarn
iPhoneWindows PhoneAndroidBlackberry
on 22 November 2017 - 21:37 #1020519
syootakarn's picture

ภาษาที่ไม่ต้องกำหนดชนิดตัวแปร(กำหนดได้น้อย) เช่น Javascript หรือ PHP คงลำบากกันต่อไป

By: PH41
ContributorAndroidUbuntuWindows
on 22 November 2017 - 21:46 #1020520
PH41's picture

ดีครับผมใช้ใน Swift, Kotlin ชอบมาก

By: Hadakung
iPhoneWindows PhoneAndroidWindows
on 22 November 2017 - 22:05 #1020522

? ใช้มาสักพักละนึกว่ามีนานแล้ว entity framework นิเพียบ...

By: ionz
AndroidWindows
on 22 November 2017 - 22:13 #1020523 Reply to:1020522

อันนั้นเป็น Nullable Value-Type แต่อันใหม่เป็น Nullable Reference Type ครับ
ใช้แก้ปัญหาเวลาอยากจะประกาศตัวแปรที่เป็น Reference Type บางตัวอยากให้เป็น null ได้ก็ต้องใส่ ?
ตัวไหนไม่ได้ใส่ ? ก็แสดงว่าเป็น non-nullable จะโดน compile ไล่เบี้ยว่าใน code ตรงไหนแอบ assign null รึเปล่า ถ้าเจอก็จะโผล่เป็น error/warning

By: Hadakung
iPhoneWindows PhoneAndroidWindows
on 22 November 2017 - 22:30 #1020526 Reply to:1020523

อ๋อผมคงโฟกัส ? อ่านดีๆด็อย่างที่ท่านว่าขอบคุณครับ

ปล หลุดพ้นจาก NullReferenceException แล้ว :D

By: thanyadol
iPhone
on 23 November 2017 - 08:40 #1020557 Reply to:1020523

ปกติผมไม่ค่อย assign null นะครับ เน้นใช้ constructor ช่วย

By: Nucksoo on 22 November 2017 - 23:21 #1020533 Reply to:1020522
Nucksoo's picture

ถ้า ? ที่เป็นตัวแปร null ได้นั้น ผมใช้มานานแล้วหละครับ มันมีมานานแล้ว ปัจจุบันก็ยังใช้อยู่เหมือนกันครับ

By: HMage
AndroidWindows
on 22 November 2017 - 22:58 #1020531

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

ผมว่าบังคับหรือสร้างวินัยให้ programmer handle exception ใดๆ ด้วยตัวเองจะเหมาะกว่า เพราะนอกจาก null แล้วยังมี runtime exception อีกตั้งหลายอย่าง เช่น array index out of bound, unparsable string เป็นต้น

By: neizod
ContributorTraineeIn Love
on 23 November 2017 - 01:22 #1020539 Reply to:1020531
neizod's picture

อ่า... ไม่แน่ใจว่าย่อหน้านี้ผมเขียนอะไรตกหล่นไปหรือเปล่าครับ?

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

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

หรือคุณจะบอกว่าเครื่องมือพวกนี้มันหาดีไม่ได้ ห้ามใช้มันนะมาฝึกวินัยโดยใช้สายตาอ่านโค้ดเพียงอย่างเดียว แล้วก็เรียนรู้เอาว่าตนเองพลาดตอนไหนจาก feedback ลูกค้าเท่านั้น?

By: tontpong
Contributor
on 23 November 2017 - 01:48 #1020540 Reply to:1020531

อันนี้คือแค่ช่วยเช็คไม่ใช่หรอ.. คือจะถือว่าตัวแปรที่เขียนโค้ดแบบก่อนๆ หน้านี้ เป็นตัวแปรแบบไม่ควรยุ่งเกี่ยวกับ null, ดังนั้นจุดไหนที่มีโอกาสยุ่งกับค่า null ก็จะเจอแจ้งเตือนตอนคอมไพล ขณะที่ของเดิมนั้นจะไปรู้ตอน runtime

By: Nucksoo on 22 November 2017 - 23:26 #1020534
Nucksoo's picture

ใน C# ผมยังคงเล่นกับ null ในระบบใหญ่ๆของผมครับ พอเข้าใจมันก็ใช้งานได้อน่างไม่มีปัญหา ก็ใช้มาจะสิบปีแล้ว

เช่น int ?MemberID
และที่ใช้ย่อยคือ ?date ก่อนจะใช้ก็เชคว่า null หรือเปล่า ถ้า null ก็ไม่ต้องทำ พอจะทพก็ cast เอา ตอนนี้ยังคงใช้ได้ดีอยู่แบบไม่มีปัญหา แต่เท่าที่อ่านน่าจะปัญหาของการ reference อันนี้อ่านจาก comment

By: syootakarn
iPhoneWindows PhoneAndroidBlackberry
on 23 November 2017 - 10:40 #1020580 Reply to:1020534
syootakarn's picture

ยิ่งมีการตรวจสอบเยอะๆ (ตรวจสอบว่าเป็น Null) โปรแกรมยิ่งช้าครับ

By: Pichai_C
Windows PhoneWindows
on 22 November 2017 - 23:52 #1020535

C# application เก่าๆ ที่พัฒนา ถ้า upgrade version มีหนาวแน่นอน แก้ null กันมัน

By: tontpong
Contributor
on 23 November 2017 - 11:31 #1020586 Reply to:1020535

เกรงว่าจะสั่งปิดแล้วลืมยาวๆ ไม่เปิดอีกเลย ?

By: Architec
ContributorWindows PhoneAndroidWindows
on 23 November 2017 - 06:36 #1020548

งาน embedded ผมขาดมันไปไม่ได้เลยนะนั่น อย่างรับค่าพวก GPS ต้องเช็คแบบละเอียดยิบ แม้แต่วันที่หากแปลง NMEA ไม่ได้(มี noise)ก็จะส่ง null กลับมา (DateTime?) จะเข้าเงื่อนไขแต่ละทีนี่เช็คตลอด

By: adente
ContributorSUSESymbianWindows
on 23 November 2017 - 11:46 #1020588
adente's picture

เนา นู นุน นัน ได้ยินคนอื่นเรียกแทบไม่เหมือนกันเลย

By: tontpong
Contributor
on 23 November 2017 - 14:16 #1020628 Reply to:1020588

ค่า เน่า ?