จะทราบได้อย่างไรว่าการสะกดคำผิดในซอร์สโค้ดเป็นปัญหาร้ายแรงหรือไม่ [ปิด]

ฉันพบข้อผิดพลาดในการสะกดคำที่ฉันพบทุกวันใน codebase ของเราซึ่งฉันจะทำซ้ำตัวอย่างสั้น ๆ แต่เป็นตัวแทน:

ArgumnetCount
Timeount
Gor message from queue 

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

สิ่งเหล่านี้สามารถพบได้แม้กระทั่งในอีเมลงานนำเสนอเอกสารหรือข้อมูลที่เป็นลายลักษณ์อักษรใด ๆ ที่เรามีใน บริษัท พัฒนาซอฟต์แวร์

ฉันต้องการทราบวิธีการตรวจสอบว่ามันเป็นปัญหาร้ายแรงหรือไม่?

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

ข้อผิดพลาดในการสะกดคำอาจหมายถึงหนึ่งในสองสิ่งต่อไปนี้:

• บุคคลที่ทำให้พวกเขาไม่เชี่ยวชาญภาษาอังกฤษและไม่ใช้เวลาในการชดเชยโดยใช้เครื่องมือที่เหมาะสม (พจนานุกรมตัวตรวจสอบการสะกด ฯลฯ )
• คนที่ทำให้พวกเขามีความเชี่ยวชาญในภาษาอังกฤษ แต่ไม่สนใจเกี่ยวกับการสะกดคำเลย

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

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

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

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

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

การเป็นโปรแกรมเมอร์เป็นเรื่องเกี่ยวกับความแม่นยำและความระมัดระวังเกี่ยวกับการพิมพ์ผิด, จุลภาค, อัฒภาค, จุดซึ่งเป็นมนุษย์ผู้ไม่เชื่อเรื่องพระเจ้าภาษาใช้เวลาส่วนใหญ่

ครั้งแรกที่คุณเสียเวลาค้นหาTimeoutตัวแปรเพียงเพื่อค้นหาว่ามันถูกเขียนขึ้นเป็นTimeountอย่างไรคุณจะรู้อีกเหตุผลว่าทำไมการสะกดคำจึงสำคัญ

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

ข้อผิดพลาดการสะกดคำในชื่อชั้นเรียนสาธารณะและวิธีการนั้นไม่เป็นมืออาชีพ พวกเขาเสียเวลาและเงิน พวกเขาเจ็บปวดในภาษาที่พิมพ์แบบคงที่เช่น Java ซึ่ง IDE สามารถสร้างเมนูของคลาสและชื่อเมธอด พวกมันทนไม่ได้ในภาษาที่พิมพ์แบบไดนามิก

ยิ่งแย่ลงคือการสะกดคำผิดในชื่อตารางฐานข้อมูลและชื่อคอลัมน์

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

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

นอกจากนี้โดยเฉพาะในความคิดเห็นสารมีความสำคัญมากกว่าแบบฟอร์ม ไม่มีความภาคภูมิใจที่นี่:

String s = "Wikipedia"; / * กำหนดค่า "Wikipedia" ให้กับตัวแปร s * /

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

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

สิ่งที่มองเห็นได้ในที่สาธารณะจะต้องอ่านอย่างระมัดระวัง

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

ตัวอย่างเช่นมันไม่ชัดเจนจากการเหลือบมองครั้งแรกหากGor message from queueหมายถึง "ได้รับข้อความจากคิว" หรือ "ข้อความ GOR จากคิว" คุณจะต้องอ่านรหัสเพื่อทำความเข้าใจความหมายของความคิดเห็น (ดังนั้นการเอาชนะวัตถุของความคิดเห็น)

คุณควรขอให้ใช้บทวิจารณ์โค้ดใน บริษัท ของคุณ จากนั้นคุณสามารถ "วิจารณ์" คนอย่างสร้างสรรค์ในขณะที่พวกเขาทำแบบเดียวกันกับคุณ

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

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

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

แน่นอนว่าโมดูลทั้งหมดนั้นไม่ได้มีค่าเท่ากันดังนั้นคุณสามารถคิดเกี่ยวกับการชั่งน้ำหนักผลลัพธ์ของคุณด้วยการวัดต่างๆเช่นความซับซ้อนตามวัฏจักรของโมดูล

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

ฉันต้องตรวจสอบรายละเอียดสำหรับระบบ (ถ้ามี) อีกครั้งและตรวจสอบการออกแบบโดยรวม ฉันจะไม่แปลกใจถ้าคุณพบหลุม

นี่เป็นสองแยกต่างหาก แต่ปัญหาที่เกี่ยวข้อง มันขึ้นอยู่กับว่าการสะกดคำผิดอยู่ที่ไหน:

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

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

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

การสะกดคำภาษาอังกฤษที่ถูกต้องเป็นสิ่งจำเป็นในรหัส ฉันยังมีรหัสฐานข้อมูลขนาดใหญ่เต็มไปด้วยซึ่งพูดพล่อยๆและมันเป็นฝันร้ายที่จะรักษา

อย่าปล่อยให้เรื่องนี้พ้นมือ พยายามให้ความรู้กับทุกคนว่าผู้ดูแลรหัสไม่ได้เป็นผู้อ่าน

นี่เป็นปัญหาทางวัฒนธรรมหลายด้าน

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

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

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

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

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

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

ใช่มันเป็นปัญหาร้ายแรงสำหรับผลิตภัณฑ์สำหรับทีมและสำหรับแต่ละบุคคล

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