เกิดอะไรขึ้นกับสายเวท?

164

ในฐานะนักพัฒนาซอฟต์แวร์ที่มีประสบการณ์ฉันได้เรียนรู้ที่จะหลีกเลี่ยงสายเวท

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

เหตุผลอะไรบ้างที่มีเพื่อหลีกเลี่ยงพวกเขา? พวกเขามีปัญหาอะไรทำให้เกิด?

anti-patterns

— Kramii
แหล่งที่มา

38

สายเวทย์คืออะไร? เช่นเดียวกับตัวเลขมายากล ?

— Laiv

14

@Laiv: มันคล้ายกับตัวเลขเวทย์มนตร์ใช่ฉันชอบนิยามที่deviq.com/magic-strings : "สตริง Magic เป็นค่าสตริงที่ระบุโดยตรงภายในรหัสแอปพลิเคชันที่มีผลกระทบต่อพฤติกรรมของแอปพลิเคชัน" (คำจำกัดความที่en.wikipedia.org/wiki/Magic_stringไม่ใช่สิ่งที่ฉันมีอยู่ในใจเลย)

— Kramii

17

นี่เป็นเรื่องตลกที่ฉันเรียนรู้ที่จะเกลียดชัง ... ต่อมาฉันสามารถโต้แย้งอะไรได้บ้างเพื่อโน้มน้าวรุ่นน้องของฉัน ... เรื่องราวที่ไม่สิ้นสุด :-) ฉันจะไม่พยายาม "โน้มน้าวใจ" ฉันอยากจะเรียนรู้ด้วยตัวเอง ประสบการณ์ของคุณเองไม่ได้มีอะไรมากไปกว่าบทเรียน / แนวคิด สิ่งที่คุณกำลังพยายามที่จะทำคือการปลูกฝัง อย่าทำอย่างนั้นถ้าคุณไม่ต้องการทีม Lemmings

— Laiv

15

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

— Kramii

6

@DavidArno ที่เป็นว่าสิ่งที่เขาทำโดยการถามคำถามนี้

— user56834

212

ในภาษาที่รวบรวมเป็นค่าสตริงมายากลจะไม่ได้ตรวจสอบที่รวบรวมเวลา หากสตริงต้องตรงกับรูปแบบเฉพาะคุณต้องเรียกใช้โปรแกรมเพื่อรับประกันว่ามันเหมาะกับรูปแบบนั้น ถ้าคุณใช้บางอย่างเช่น enum ค่าอย่างน้อยก็ใช้ได้ในเวลารวบรวมแม้ว่ามันอาจจะเป็นค่าที่ไม่ถูกต้องก็ตาม
หากมีการเขียนสตริงมายากลในหลาย ๆ ที่คุณต้องเปลี่ยนทั้งหมดโดยไม่มีความปลอดภัย (เช่นข้อผิดพลาดเวลาคอมไพล์) สิ่งนี้สามารถโต้กลับได้โดยการประกาศมันในที่เดียวและนำตัวแปรมาใช้ซ้ำ
ความผิดพลาดอาจกลายเป็นข้อบกพร่องร้ายแรง หากคุณมีฟังก์ชั่น:
```
func(string foo) {
    if (foo == "bar") {
        // do something
    }
}
```
และบางคนบังเอิญพิมพ์:
```
func("barr");
```
สิ่งนี้แย่กว่าความยากของสตริงยิ่งยากขึ้นโดยเฉพาะถ้าคุณมีโปรแกรมเมอร์ที่ไม่คุ้นเคยกับภาษาดั้งเดิมของโปรเจ็กต์
สายเวทย์นั้นไม่ค่อยจัดทำเอกสารด้วยตนเอง หากคุณเห็นสตริงหนึ่งนั่นจะบอกคุณว่าไม่มีสิ่งใดที่สตริง / ควรจะเป็น คุณอาจจะต้องพิจารณาการใช้งานเพื่อให้แน่ใจว่าคุณเลือกสตริงที่ถูกต้อง

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

— Erdrik Ironrose
แหล่งที่มา

34

เกี่ยวกับอาร์กิวเมนต์แรก: TypeScript เป็นภาษาที่รวบรวมที่สามารถพิมพ์สตริงตัวอักษร สิ่งนี้จะทำให้การโต้แย้งเป็นโมฆะสองถึงสี่ ดังนั้นไม่ใช่สตริงเองจึงเป็นปัญหา แต่ใช้ชนิดที่อนุญาตค่ามากเกินไป เหตุผลเดียวกันสามารถนำไปใช้กับการใช้จำนวนเต็มมายากลสำหรับการแจกแจง

— Yogu

11

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

— Erdrik Ironrose

23

@Yogu Typescript จะไม่เปลี่ยนชื่อสตริงทั้งหมดของคุณหากคุณเปลี่ยนประเภทตัวอักษรสตริงคงที่ที่คุณคาดหวัง คุณจะได้รับข้อผิดพลาดในการรวบรวมเวลาเพื่อช่วยให้คุณค้นพบทั้งหมด แต่นั่นเป็นเพียงการปรับปรุงบางส่วนในวันที่ 2 ไม่ได้บอกว่ามันเป็นอะไรที่น่าประหลาดใจอย่างยิ่ง (เพราะมันเป็นเช่นนั้นและฉันรักคุณสมบัติ) ทันทีกำจัดข้อได้เปรียบของ enums ในโครงการของเราเวลาที่จะใช้ enums และเมื่อใดที่ยังไม่เป็นคำถามแบบเปิดที่เราไม่แน่ใจ ทั้งสองวิธีมีความรำคาญและความได้เปรียบ

— KRyan

30

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

— corsiKa

35

@Yogu ฉันยังจะเถียงว่าถ้าค่าสตริงตัวอักษรจะถูกตรวจสอบที่รวบรวมเวลาแล้วมันสิ้นสุดสภาพการเป็นสตริงมายากล ณ จุดนั้นมันเป็นเพียงค่าปกติ / ค่า enum ที่เกิดขึ้นกับการเขียนในวิธีที่ตลก เมื่อพิจารณาในมุมมองนั้นฉันจะยืนยันว่าความคิดเห็นของคุณสนับสนุนคะแนนของ Erdrik มากกว่าที่จะหักล้างพวกเขา

— GrandOpener

89

การประชุมสุดยอดของสิ่งที่คำตอบอื่น ๆ ได้เข้าใจไม่ใช่ "ค่าเวทมนตร์" ที่ไม่ดี แต่พวกเขาควรจะ:

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

สิ่งที่โดยทั่วไปจะแตกต่างจาก "ค่าคงที่" ที่ยอมรับได้จาก "ค่าเวทมนตร์" คือการละเมิดกฎเหล่านี้อย่างน้อยหนึ่งกฎ

ถ้าใช้อย่างดีค่าคงที่เพียงแค่ให้เราแสดงความจริงบางประการของรหัสของเรา

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

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

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

แก้ไข:การยอมรับการแก้ไขหนึ่งครั้งปฏิเสธอีกครั้งและตอนนี้ทำการแก้ไขของตัวเองตอนนี้ฉันขอพิจารณารูปแบบการจัดรูปแบบและเครื่องหมายวรรคตอนของรายการกฎของฉันที่จะตัดสินทันทีและสำหรับฮ่า ๆ ๆ !

— สตีฟ
แหล่งที่มา

2

ฉันชอบคำตอบนี้ หลังจากทั้งหมด "struct" (และคำสงวนอื่น ๆ ทุกคำ) เป็นสายเวทให้กับคอมไพเลอร์ C มีวิธีการเข้ารหัสที่ดีและไม่ดีสำหรับพวกเขา

— Alfred Armstrong

6

ตัวอย่างเช่นถ้ามีคนเห็น“ X: = 898755167 * Z” ในรหัสของคุณพวกเขาอาจไม่รู้ว่ามันหมายถึงอะไรและมีโอกาสน้อยที่จะรู้ว่ามันผิด แต่ถ้าพวกเขาเห็น“ Speed_of_Light: constant Integer: = 299792456” บางคนจะค้นหาและแนะนำค่าที่ถูกต้อง (และอาจเป็นประเภทข้อมูลที่ดีกว่า)

— WGroleau

26

บางคนพลาดจุดนี้อย่างสมบูรณ์และเขียน COMMA = "," แทนที่จะเป็น SEPARATOR = "," อดีตไม่ได้ทำให้อะไรชัดเจนขึ้นในขณะที่หลังระบุการใช้งานที่ตั้งใจและช่วยให้คุณสามารถเปลี่ยนตัวแยกในภายหลังในที่เดียว

— มาร์คัส

1

@marcus แน่นอน! แน่นอนว่ามีกรณีสำหรับการใช้ค่าตัวอักษรแบบง่าย ๆ ในสถานที่ - ตัวอย่างเช่นถ้าวิธีการแบ่งค่าตามสองมันอาจจะชัดเจนและง่ายกว่าที่จะเขียนvalue / 2แทนที่จะvalue / VALUE_DIVISORเป็นหลังที่กำหนดไว้ที่2อื่น หากคุณต้องการสรุปวิธีการจัดการ CSV คุณอาจต้องการให้ตัวคั่นส่งผ่านเป็นพารามิเตอร์และไม่ได้กำหนดเป็นค่าคงที่เลย แต่ทั้งหมดเป็นคำถามของการตัดสินในบริบท - ตัวอย่างของ @ WGroleau SPEED_OF_LIGHTเป็นสิ่งที่คุณต้องการตั้งชื่ออย่างชัดเจน แต่ไม่ใช่ทุกตัวอักษรที่ต้องการสิ่งนี้

— Steve

4

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

— corsiKa

34

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

— jason
แหล่งที่มา

4

"ไม่มีการใช้ซ้ำ" หมายความว่าอย่างไร

— ลา

7

แทนที่จะสร้างตัวแปร / ค่าคงที่หนึ่ง ๆ และใช้ซ้ำในโครงการ / รหัสทั้งหมดของคุณคุณกำลังสร้างสตริงใหม่ในแต่ละอันซึ่งทำให้เกิดการทำซ้ำที่ไม่จำเป็น

— สัน

ดังนั้นจุดที่ 2 และ 4 เหมือนกันหรือไม่

— โทมัส

4

@ThomasMoors ไม่ว่าเขาจะพูดถึงวิธีการสร้างสายอักขระใหม่ทุกครั้งที่คุณต้องการใช้สายมายากลที่มีอยู่แล้วจุดที่ 2 เกี่ยวกับการเปลี่ยนสายตัวเอง

— Pierre Arlaud

25

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

Field nameField = myEntity.GetField("ProductName");

(สังเกตสตริงมายากล "ชื่อผลิตภัณฑ์")

สิ่งนี้สามารถนำไปสู่ปัญหาต่าง ๆ :

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

ดังนั้นวิธีแก้ปัญหาของฉันคือสร้างค่าคงที่สำหรับชื่อเหล่านี้ซึ่งจัดเรียงตามประเภทเอนทิตี ดังนั้นตอนนี้ฉันสามารถใช้:

Field nameField = myEntity.GetField(Model.Product.ProductName);

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

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

ถัดไปในรายการของฉัน: ซ่อนค่าคงที่เหล่านี้ด้านหลังคลาสที่สร้างขึ้นอย่างมากพิมพ์ - แล้วประเภทข้อมูลก็ปลอดภัย

— Hans Ke ﬆ ing
แหล่งที่มา

+1 คุณได้คะแนนที่ดีจำนวนมากโดยไม่ จำกัด โครงสร้างของโค้ด: การสนับสนุน IDE และเครื่องมือซึ่งสามารถช่วยชีวิตในโครงการขนาดใหญ่ได้

— kmdreko

nameField = myEntity.ProductName;หากบางส่วนของประเภทบุคคลของคุณเป็นแบบคงที่มากพอที่จริงการกำหนดชื่อคงให้มันคุ้มค่าที่ผมคิดว่ามันจะฉลาดมากขึ้นที่จะเพียงแค่กำหนดรูปแบบข้อมูลที่เหมาะสมสำหรับมันดังนั้นคุณก็สามารถทำได้

— Lie Ryan

@LieRyan - มันง่ายกว่ามากในการสร้างค่าคงที่แบบธรรมดาและอัพเกรดโครงการที่มีอยู่เพื่อใช้งาน ที่กล่าวว่าฉันกำลังทำงานเกี่ยวกับการสร้างประเภทคงที่เพื่อให้ฉันสามารถทำอย่างแม่นยำว่า

— ฮันส์ Ke ﬆ ing

9

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

ในบางกรณีสายวิเศษควรหลีกเลี่ยง:

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

แต่ในบางกรณี "สตริงเวทมนตร์" นั้นใช้ได้ สมมติว่าคุณมีโปรแกรมแยกวิเคราะห์อย่างง่าย:

switch (token.Text) {
  case "+":
    return a + b;
  case "-":
    return a - b;
  //etc.
}

ไม่มีเวทย์มนตร์ที่นี่จริง ๆ และไม่มีปัญหาที่อธิบายไว้ข้างต้น จะไม่มีประโยชน์ใดstring Plus="+"ๆ ในการกำหนด IMHO เป็นต้นให้ง่ายขึ้น

— JacquesB
แหล่งที่มา

7

ฉันคิดว่าคำจำกัดความของคุณของ "สตริงเวทมนตร์" ไม่เพียงพอมันจำเป็นต้องมีแนวคิดในการซ่อน / ซ่อนเร้น / ทำให้ลึกลับ ฉันจะไม่ดูที่ "+" และ "-" ในการที่เคาน์เตอร์ตัวอย่างเป็น "มายากล" ใด ๆ if (dx != 0) { grad = dy/dx; }มากกว่าผมจะดูที่ศูนย์เป็นความมหัศจรรย์ใน

— Rupe

2

@Rupe: ฉันเห็นด้วย แต่ OP ใช้นิยาม " ค่าสตริงที่ระบุโดยตรงในรหัสแอปพลิเคชันที่มีผลกระทบต่อพฤติกรรมของแอปพลิเคชัน " ซึ่งไม่จำเป็นต้องใช้สตริงที่เป็นปริศนาดังนั้นนี่คือคำจำกัดความที่ฉันใช้ คำตอบ.

— JacquesB

7

มีการอ้างอิงถึงตัวอย่างของคุณฉันได้เห็นงบสวิทช์ซึ่งแทนที่"+"และ"-"ด้วยและTOKEN_PLUS TOKEN_MINUSทุกครั้งที่ฉันอ่านฉันรู้สึกว่าเป็นการยากที่จะอ่านและดีบักเพราะมัน! สถานที่ที่ฉันเห็นด้วยว่าการใช้สตริงแบบธรรมดาย่อมดีกว่า

— Cort Ammon

2

ฉันยอมรับว่ามีบางครั้งที่สายเวทเหมาะสม: การหลีกเลี่ยงพวกมันเป็นกฎง่ายๆและกฎของหัวแม่มือทั้งหมดมีข้อยกเว้น หวังว่าเมื่อเรามีความชัดเจนเกี่ยวกับสาเหตุที่พวกเขาสามารถเป็นสิ่งที่ไม่ดีเราจะสามารถที่จะสร้างทางเลือกที่ชาญฉลาดมากกว่าการทำสิ่งที่เพราะ (1) เราไม่เคยเข้าใจว่าอาจมีวิธีที่ดีกว่าหรือ (2) เรา เคยมีคนบอกให้ทำสิ่งต่าง ๆ โดยนักพัฒนาอาวุโสหรือมาตรฐานการเข้ารหัส

— Kramii

2

ฉันไม่รู้ว่า "เวทมนต์" คืออะไรที่นี่ มันดูเหมือนตัวอักษรสตริงพื้นฐานสำหรับฉัน

— tchrist

6

วิธีเพิ่มคำตอบที่มีอยู่:

สากล (i18n)

หากข้อความที่จะแสดงบนหน้าจอมีการกำหนดค่าตายตัวและฝังอยู่ภายในเลเยอร์ของฟังก์ชั่นคุณจะมีช่วงเวลาที่ยากลำบากในการแปลข้อความนั้นเป็นภาษาอื่น

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

สภาพแวดล้อมการพัฒนาบางอย่าง (เช่น MS Visual Studio) ใช้วิธีการอื่นและต้องการให้มีการแปลสตริงทั้งหมดในฐานข้อมูลทรัพยากรและอ่านกลับไปยังโลแคลปัจจุบันโดยใช้ ID เฉพาะของสตริงนั้น ในกรณีนี้แอปพลิเคชันของคุณที่มีสายอักขระเวทไม่สามารถแปลเป็นภาษาอื่นได้ การพัฒนาที่มีประสิทธิภาพต้องการสตริงข้อความทั้งหมดเพื่อป้อนลงในฐานข้อมูลทรัพยากรและกำหนด ID เฉพาะเมื่อเขียนรหัสครั้งแรกและหลังจากนั้น i18n จะค่อนข้างง่าย การพยายามเติมโฆษณาซ้ำหลังจากความจริงมักจะต้องใช้ความพยายามอย่างมาก (และใช่ฉันเคยไปที่นั่นแล้ว!) ดังนั้นจึงเป็นการดีกว่าที่จะทำสิ่งต่าง ๆ ในตอนแรก

— ทำจากแป้งที่ยังไม่ได้ร่อน
แหล่งที่มา

3

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

แต่นี่ไม่ใช่สิ่งที่นักพัฒนาจำนวนมากให้ความสนใจ

— user3511585
แหล่งที่มา