“ การแสดงความคิดเห็นตลก ๆ ” เป็นการปฏิบัติที่ไม่ดีหรือไม่? [ปิด]

ฉันต้องการถามคุณว่าการเพิ่ม "ไข่อีสเตอร์" ในเอกสารต้นฉบับนั้นไม่เป็นมืออาชีพหรือไม่ คุณอาจต้องอ่านStackOverflowโพลสำรวจความคิดเห็นตลกในเอกสารแหล่งที่มาและผมก็มีสะดุดส่วนตัวที่สิ่งดังกล่าวจำนวนมากในระหว่างการทำงานของฉันรวมทั้งตลก (หรือไม่) สิ่งที่อยู่ในเอกสาร API สาธารณะ (เช่นนี้อ่อนแอBZZZTT !! 1!สิ่ง ในเอกสารสาธารณะของ Android ฉันสามารถยกตัวอย่างได้อีกอย่างน้อยหนึ่งโหล)

ฉันไม่สามารถมาถึงความเห็นขั้นสุดท้ายสำหรับตัวเองเพราะฉันมีข้อโต้แย้งที่ขัดแย้งกันด้วยตัวเอง

อาร์กิวเมนต์ Pro:

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

ข้อโต้แย้ง:

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

คุณคิดอย่างไร?

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

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

ฉันจะยังคงลงคะแนนคัดค้านเพียงเพราะความคิดเห็น 'ตลก' ทุกครั้งที่ฉันเคยอ่านอาจจะเป็นเฮฮาในเวลา - แต่ฉันยังไม่เห็นคนที่ตลกจริง ๆ ส่วนใหญ่เป็นเพียงทำให้งงงวยหรือลึกลงไปใน -เรื่องตลก.

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

ฉันเป็นแฟนตัวยงของตลกการแสดงความคิดเห็น

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

โดยเฉพาะอย่างยิ่งถ้าผู้อ่านเป็นสมาชิกของทีมของคุณ

สิ่งที่ฉันไม่ชอบมากที่สุดคือนักพัฒนาที่จริงจังกับตัวเองมากเกินไป ฉันคิดว่าเราควรมีความสนุกสนานในที่ทำงานหรืองานไม่คุ้มค่า

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

รหัสมีความหมายสำหรับการอ่าน ... หลายครั้ง

คุณรู้ว่ามีมุกตลกกี่เรื่องที่ตลกหลังจากการบอกร้อยครั้ง?

ความเห็นตลกดีมาก

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

อย่าตลกเหมือนผู้ชายคนนี้ ;)

นี่คือสิ่งที่ฉันเขียนตอนสองโมงเช้า ("DQ" เป็นชื่อย่อของ บริษัท ฉัน):

// Twas the night before go-live and all through DQ
// the devs were all crying and yes, this means you.
// Keys had been saved with both hyphens and 'scores
// which left this programmer with finger pad sores.
// The solution I crafted, you'll likely find lacking:
// to OR them together with judicuous hacking.

$hyphenated = str_replace('_','-',$data_type_key);
$underscored = str_replace('-','_',$data_type_key);
// (and then see line 46)

หากคุณกำลังตรวจสอบซอร์สโค้ดต่อหน้าลูกค้าคุณจะเขินอายไหม?

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

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

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

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

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

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

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

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

กฎพื้นฐานง่ายๆของฉันคือ: หากมันค่อนข้างชัดเจนว่าส่วนของรหัสทำอะไรความคิดเห็นตลก ๆ เปิด!

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