จุดประสงค์ของการเพิ่มตัวระบุ Unicode สนับสนุนการใช้ภาษาต่าง ๆ คืออะไร

ฉันเองพบว่ารหัสการอ่านที่เต็มไปด้วยตัวระบุ Unicode ทำให้เกิดความสับสน ในความคิดของฉันมันยังป้องกันไม่ให้รหัสถูกดูแลรักษาได้ง่าย ไม่ต้องพูดถึงความพยายามทั้งหมดที่จำเป็นสำหรับผู้แต่งนักแปลหลายคนที่จะใช้การสนับสนุนดังกล่าว ฉันยังสังเกตเห็นการขาด (หรือการมีอยู่) ของตัวระบุ Unicode อย่างต่อเนื่องสนับสนุนในรายการของ (dis) ข้อดีของการใช้งานภาษาต่าง ๆ (เช่นที่มันสำคัญจริงๆ) ฉันไม่เข้าใจ: ทำไมถึงสนใจมาก?

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

แต่ถ้ายูนิโค้ดสามารถใช้ในทางที่ผิดก็ไม่ได้แปลว่ามันไม่ดีในซอร์สโค้ด

เมื่อเขียนรหัสสำหรับเขตข้อมูลที่มียูนิโค้ดคุณสามารถย่อรหัสของคุณและทำให้อ่านง่ายขึ้น แทน:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

คุณสามารถเขียน:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

ซึ่งอาจจะไม่ง่ายต่อการอ่านสำหรับนักพัฒนาเฉลี่ย แต่ยังง่ายต่อการอ่านสำหรับคนที่ใช้สัญลักษณ์ทางคณิตศาสตร์ในชีวิตประจำวัน

หรือเมื่อทำแอปพลิเคชันที่เกี่ยวข้องกับการถ่ายภาพ SLR แทนที่จะเป็น:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

คุณสามารถเปลี่ยนค่ารูรับแสงด้วยสัญลักษณ์ƒโดยเขียนได้ใกล้กับƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

สิ่งนี้อาจไม่สะดวก : เมื่อพิมพ์รหัส C # ทั่วไปฉันต้องการเขียน:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

ค่อนข้างมากกว่า:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

เพราะในกรณีแรก IntelliSense ช่วยให้ฉันเขียนรหัสทั้งหมดโดยไม่ต้องพิมพ์และโดยเฉพาะอย่างยิ่งโดยไม่ต้องใช้เมาส์ของฉันในขณะที่ในกรณีที่สองฉันไม่รู้ว่าจะหาสัญลักษณ์เหล่านั้นได้ที่ไหนและจะถูกบังคับให้ต้องพึ่งพาเมาส์ และค้นหาในรายการเติมข้อความอัตโนมัติ

สิ่งนี้ถูกกล่าวว่ามันยังมีประโยชน์ในบางกรณี currentLens.GetMaximumƒ();จากตัวอย่างก่อนหน้านี้ของฉันสามารถพึ่งพา IntelliSense และพิมพ์ได้ง่ายGetMaximumApertureโดยมีขนาดสั้นและอ่านง่ายขึ้น นอกจากนี้สำหรับโดเมนเฉพาะที่มีสัญลักษณ์จำนวนมากแป้นพิมพ์ลัดอาจช่วยพิมพ์สัญลักษณ์ได้เร็วกว่าการเทียบเท่าตัวอักษรในซอร์สโค้ด

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

^{¹แน่นอนฉันจะไม่เพลิดเพลินกับเชิงอรรถในรหัส C # ซึ่งมีกฎสไตล์ที่เข้มงวดเกี่ยวกับวิธีการเขียนความคิดเห็น ในทางกลับกันถ้ามีหลายสิ่งที่จะอธิบาย แต่สิ่งเหล่านั้นไม่สำคัญมากทำไมไม่วางไว้ที่ด้านล่างของไฟล์และสร้างเชิงอรรถในPHPDocของวิธีการ?}

ฉันจะพูดว่า:

1. เพื่อให้ผู้ที่ไม่ใช่มืออาชีพและสามเณรสามารถเรียนรู้การเขียนโปรแกรม (เช่นที่โรงเรียน) และไม่รู้ภาษาอังกฤษ พวกเขาไม่ได้เขียนรหัสการผลิตอยู่ดี ฉันเห็นรหัสหลายครั้งเช่น:

   double upsos, baros;
   cin >> upsos >> baros;
   

   ปล่อยให้คนจนเขียนด้วยภาษาของเขา:

   double ύψος, βάρος;
   cin >> ύψος >> βάρος;
   

2. คุณไม่ชอบเหรอ

   class ☎ {
   public:
       ☎(const char*);
       void 📞();
       void 🎧(👨);
   };
   
   ☎ ☏("031415926");
   ☏.🎧(👨("Bob"));
   ofstream f;
   f.💾();
   

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

แต่ OP นั้นถูกต้อง: ตอนนี้เป็นไปได้แล้วที่ชาวอินเดียที่พูดภาษาฮินดีต้องรักษารหัสด้วยตัวระบุรัสเซียและความคิดเห็นเกี่ยวกับภาษาอาหรับ ช่างเป็นฝันร้ายสำหรับคนจีนที่น่าสงสารที่ควรทำการตรวจสอบคุณภาพและไม่สามารถอ่านตัวอักษร 3 ตัวใด ๆ ข้างต้นได้!

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

ฉันคิดว่ามันสมเหตุสมผลดีที่จะอนุญาตให้มีอักขระ Unicode ในสตริงและความคิดเห็น และถ้า lexer & parser ต้องรองรับยูนิโค้ดสำหรับสิ่งนั้นผู้เขียนคอมไพเลอร์อาจได้รับการสนับสนุนอักขระยูนิโค้ดในตัวระบุได้ฟรีดังนั้นจึงดูเหมือนว่ามีข้อ จำกัด โดยพลการที่จะอนุญาตเฉพาะอักขระ ASCII ในตัวระบุเท่านั้น

เท่าที่ฉันกังวลนี่เป็นเพียงเหตุผลทางการตลาดเท่านั้น และนอกจากนี้อาจทำให้ชีวิตของเรายากขึ้น

ข้อโต้แย้งทางการตลาด

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

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

และด้วยเหตุนี้พวกเขาจึงสามารถโอ้อวด: "อ้ากับ Y คุณไม่ได้รับการสนับสนุน Unicode สำหรับตัวระบุของคุณ! ใน X ที่เราทำดังนั้นสำหรับนักเรียนมันง่ายกว่ามาก!"

การเข้าใจผิดของการเข้าถึง

น่าเสียดายที่การโต้แย้งเรื่องการเข้าถึงนั้นผิดพลาด

โอ้ฉันเข้าใจว่าสามารถเขียน "résultatDuJetDeDé" แทน "diceThrowResult" (ใช่ฉันเป็นคนฝรั่งเศส) อาจดูเหมือนชนะในระยะสั้น ... แต่มีข้อเสีย!

การเขียนโปรแกรมเป็นเรื่องเกี่ยวกับการสื่อสาร

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

• การอ่านมันแสดงถึงความสามารถในการเห็นภาพอักขระที่คุณใช้ Unicode ไม่ได้รับการสนับสนุนอย่างดีจากทุกแบบอักษร
• การทำความเข้าใจมันหมายถึงการพึ่งพาตัวระบุ - เว้นแต่คุณจะเสริมความคิดเห็นที่มีความรุนแรง แต่นั่นเป็นการละเมิดกฎ DRY

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

การเขียนโปรแกรมต้องมีความเข้าใจ

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

• ห้องสมุดเหล่านั้นเขียนด้วยภาษาใด
• มีการบันทึกไว้ในห้องสมุดภาษาใดบ้าง

หากคุณตอบ Morrocan อาหรับฉันจะแปลกใจ

หากคุณไม่ได้พึ่งพาเฉพาะการบรรยายที่คุณให้ความช่วยเหลือและเอกสารประกอบที่ครอบคลุมในทุก ๆ คุณสมบัติของห้องสมุดที่คุณจะต้องใช้ (และอาจเป็นห้องสมุดที่แปลแล้ว) คุณจะต้องเรียนรู้ภาษาอังกฤษเล็กน้อย แต่คุณอาจจะต้องใช้เวลานานกว่าจะเริ่มหลักสูตรการเขียนโปรแกรมนี้อยู่ดี

ภาษาอังกฤษคือ...

... ภาษากลางของโปรแกรมเมอร์ (และนักวิทยาศาสตร์ส่วนใหญ่)

คนที่เร็วกว่ายอมรับมันและไปกับมันมากกว่าต่อสู้กับมันคนที่เร็วกว่านั้นสามารถเรียนรู้และก้าวหน้าได้อย่างแท้จริง

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

ยังคง ...

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

แล้วทำไมล่ะ

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

และอาจมีประโยชน์สำหรับผู้ใช้บางราย

แต่ส่วนตัวแล้วฉันจะจัดการกับโค้ดที่เขียนด้วยตัวระบุภาษาอังกฤษเท่านั้น ฉันไม่สนใจว่าคุณต้องการความช่วยเหลือในการเขียนโค้ดหรือห้องสมุดของคุณยอดเยี่ยมมากและฉันสามารถใช้มันได้มากถ้าฉันไม่เข้าใจฉันจะต้องเพิกเฉย

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

โปรแกรมเมอร์ควรมีสิทธิและความสามารถในการเรียกตัวแปรของพวกเขาตามที่พวกเขาต้องการ มันไม่ใช่ธุรกิจของคุณที่มีภาษาอะไรอยู่

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

ตามPEP 3131 - การสนับสนุนตัวระบุที่ไม่ใช่ ASCIIลงวันที่ในปี 2550 ส่วนแรกของสถานะ Rationale:

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

ฉันยังไม่ได้ตรวจสอบภาษาอื่น ๆ แต่ควรเป็นเหตุผลที่พวกเขาเพิ่มการสนับสนุน

มันจะทำให้ชีวิตง่ายขึ้น (สำหรับเราบางคน) ถ้าคอมไพเลอร์ไม่สนับสนุน Unicode ตัวระบุจากขวาไปซ้ายนั้นแย่มาก ตัวอักษรโรมันที่รวมกันและตัวระบุ Unicode จากขวาไปซ้ายยิ่งแย่ลงไปอีก

สิ่งที่ไม่ดีเกี่ยวกับการไม่สนับสนุนคือตัวช่วยสร้าง GUI บางอย่างใช้ข้อความที่คุณใส่ไว้ในรายการและใช้ข้อความนั้นเป็นตัวระบุรายการโดยอัตโนมัติ ดังนั้นพวกเขาจะทำอะไรกับข้อความ Unicode ในรายการเหล่านั้น? ไม่มีคำตอบที่ง่ายฉันกลัว

ความคิดเห็นแบบ Unicode จากขวาไปซ้ายอาจเป็นเรื่องตลกเช่นกัน ตัวอย่างเช่นใน VS 2010 ความคิดเห็น XML จะแสดง (ถูกต้อง) เป็น RTL ในรหัส ... แต่เมื่อคุณใช้ Intellisense เพื่อดึงตัวระบุที่อื่นในรหัสคำแนะนำเครื่องมือจะแสดง (ไม่ถูกต้อง) LTR ดีกว่าบางทีถ้าไม่มีการสนับสนุนในตอนแรก? ไม่ใช่การโทรที่ง่ายอีกครั้ง