ใช้“ สิ่งนี้” ใน Golang

12

สิ่งที่ใกล้เคียงที่สุดของ Golang ก็คือคู่มือสไตล์ที่พบได้ที่นี่ภายใต้ชื่อผู้รับข้อความที่เขียนนี้:

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

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

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

coding-style naming golang

— อาดัม
แหล่งที่มา

3

คำถามที่คล้ายกันพร้อมคำตอบเพิ่มเติม: stackoverflow.com/questions/23482068

— Trenton

11

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

ในสาระสำคัญเมื่อคุณเขียนวิธีเช่นนี้

func (m *MultiShape) area() float64 {
  ...
}

มันเกือบจะเหมือนกับการเขียนฟังก์ชั่นแบบนี้:

func area(m *MultiShape) float64 {
  ...
}

ความแตกต่างเพียงอย่างเดียวคือการเปลี่ยนแปลงทางไวยากรณ์เล็กน้อยในวิธีที่เราเรียกใช้ฟังก์ชัน / วิธี

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

นอกจากนี้ในภาษา OOP "ดั้งเดิม" วิธีการ struct / class 'ทั้งหมดมาพร้อมกับคำนิยาม struct / class ดังนั้นจึงไม่สามารถเพิ่มได้อีกจากภายนอก ใน Go เท่าที่ฉันรู้ว่าทุกคนสามารถเพิ่มวิธีการเพิ่มเติมเพื่ออะไร (ภายในขอบเขตของรหัสของตนเองแน่นอน)

ฉันไม่ได้เขียนพอไปเพื่อสร้างคู่มือสไตล์ของตัวเอง แต่โดยส่วนตัวฉันอาจใช้thisวิธีที่กำหนดไว้ในไฟล์เดียวกับ struct ที่พวกเขาได้รับและชื่อผู้รับที่เป็นคำอธิบายเพิ่มเติมเกี่ยวกับวิธีการที่ฉันแนบกับไฟล์จากไฟล์อื่น .

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

นั่นเป็นคำอธิบายที่ดีฉันคิดว่าฉันคุ้นเคยกับภาษา C # และภาษา OOP อื่น ๆ ดังนั้นฉันจึงกลับไปสู่การประชุมที่ฉันรู้จัก

— อดัม

1

@ อดัมฉันจะหลีกเลี่ยงthisถ้าไม่มีเหตุผลอื่นนอกจากเตือนตัวเองว่าฉันไม่ได้ใช้ภาษา OOP แบบดั้งเดิม

— Michael Hampton

4

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

— mvmn

6

ผมไม่ได้เชื่อตามคู่มือรูปแบบนี้และผมไม่คิดว่าอะไรจะดีกว่าthis, หรือme selfเพราะthis, meหรือselfทำให้มันชัดเจนว่าซุปเปอร์ตัวแปรเป็นตัวอย่างของ struct บริบท ฉันไม่ได้บอกว่าชื่อตัวแปร struct ที่มีความเอนเอียงต่ำเป็นความคิดที่ไม่ดีฉันก็ชอบวิธีที่thisทำให้ชัดเจน

— เควนเฉิน
แหล่งที่มา

คำตอบนี้อาจไร้ประโยชน์ในกรณีที่คนอื่นโพสต์ความคิดเห็นตรงข้ามโดยไม่มีคำอธิบาย ตัวอย่างเช่นถ้าคนโพสต์การเรียกร้องเช่น"ผมเชื่อว่าด้วยคู่มือสไตล์นี้และผมคิดว่ามันจะดีกว่าthis, meหรือself"วิธีการที่จะช่วยให้ผู้อ่านนี้คำตอบที่จะเลือกของสองความคิดเห็นของฝ่ายตรงข้าม? พิจารณาแก้ไข ing มันกลายเป็นรูปร่างที่ดีขึ้นเพื่อตอบสนองวิธีการตอบแนวทาง

— ริ้น

ฉันคิดว่าฉันอธิบายอย่างชัดเจนถึงสิ่งที่ฉันต้องการจะพูด

— Qian Chen

1

ฉันเห็นด้วย. ฉันคิดว่ามีสมองมากเกินไปถูกวางยาในบริบทของจาวาสคริปต์ หากคุณวางทิ้งไว้ นั่นหมายถึงบริบทปัจจุบันนั้นง่ายกว่ามาก และง่ายขึ้นหากคุณเปลี่ยนชื่อ structs ในภายหลังหรือคัดลอกวางส่วนหนึ่งของการนำไปใช้ ฆ้องสำหรับชื่อที่คลุมเครือบรรทัด hl ฯลฯ ไม่ได้ทำให้ง่ายขึ้นกว่านี้

— Sentient

0

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

ใน JavaScript เช่นโมดูลควบคุมอาจเริ่มต้นการโต้ตอบและประกาศonLoadฟังก์ชั่นแบบอินไลน์ แต่ ณ จุดนั้นมันอาจเป็นเรื่องง่ายสำหรับ coder อื่นที่จะตีความthisภายในonLoadเพื่ออ้างถึงโมดูลควบคุมไม่ใช่กล่องโต้ตอบ หรือในทางกลับกัน นี้อาจจะหลีกเลี่ยงได้ถ้าควบคุมถูกเรียกว่าและโต้ตอบเป็นctrldg

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

3

ฉันไม่ใช่ downvoter แต่พฤติกรรมที่สับสนส่วนใหญ่ของthisใน Javascript นั้นไม่ได้ใช้กับ Go ดังนั้นฉันเดาว่านั่นเป็นสาเหตุ

— Ixrec

@Ixrec หืม ... โอเค ฉันพยายามขยายไปสู่สถานการณ์ที่คุณสามารถเลือกthisชื่อได้ ตัวอย่างเช่นตัวแปลงสัญญาณ JS จะเขียนvar self = thisเพื่อให้มีการอ้างอิงที่เหมือนกัน แต่ตามคู่มือการออกแบบของ Go ซึ่งอาจมีปัญหาความสับสนเดียวกันและในทางทฤษฎีควรใช้การอ้างอิงที่มีความหมายมากขึ้น

— Katana314