คำถามติดแท็ก naming

ให้ความหมายและคำอธิบายด้วยจำนวนอักขระน้อยที่สุดในแบบฟอร์มที่ได้รับการยอมรับมากที่สุดจากทีมหรือชุมชนของคุณโดยรวม

7
การย่อมาตรฐานสำหรับ "นิพจน์ทั่วไป", "regex" หรือ "regexp" คืออะไร [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังว่าคำตอบจะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน8 ปีที่ผ่านมา ฉันต้องการที่จะรู้ว่าอะไรคือวิธีที่เป็นมาตรฐานมากขึ้นในการเรียกการแสดงออกปกติในทางสั้น ๆ ฉันได้เห็นทั้ง regex และ regexp Google กล่าวว่า regex มีความนิยมมากถึงเกือบ 2 เท่าที่ regexp แต่ขึ้นอยู่กับวิธีที่ฉันค้นหา (เมื่อฉันเพิ่ม "การแสดงออกปกติ" หลังจากคำว่า "regex" กลายเป็น "การแสดงออกปกติ regex" ผลลัพธ์จะแตกต่างกัน) และบน stackexchange จะมีแท็ก regex :) อะไรคือวิธีที่เหมาะสมกว่าในการย่อให้สั้นลง บางทีมันไม่สำคัญ :) แต่ขอบคุณสำหรับคำตอบ

8
อนุสัญญาการตั้งชื่อตัวแปร? [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันเพิ่งเริ่มใช้ ReSharper (สำหรับ C #) และฉันชอบโปรแกรมค้นหารหัสกลิ่นมันแสดงให้ฉันเห็นบางอย่างเกี่ยวกับการเขียนของฉันที่ฉันต้องการแก้ไขเมื่อนานมาแล้ว (หลักการตั้งชื่อตัวแปรส่วนใหญ่) มันทำให้ฉันพิจารณาอนุสัญญาการตั้งชื่อของฉันอีกครั้งสำหรับวิธีการและตัวแปรอินสแตนซ์ ReSharper แนะนำว่าตัวแปรอินสแตนซ์นั้นเป็นตัวพิมพ์เล็กอูฐและเริ่มต้นด้วยเครื่องหมายขีดล่าง ในขณะที่ฉันตั้งใจจะทำให้ตัวแปรท้องถิ่นทั้งหมดของฉันลดขนาดอูฐ แต่จำเป็นต้องเน้นหรือไม่ คุณรู้สึกสบายไหม ฉันไม่ชอบอนุสัญญานี้ แต่ฉันยังไม่ได้ลองเลยคุณคิดยังไง? สิ่งที่สองที่กระตุ้นให้ฉันประเมินใหม่คือข้อกำหนดการตั้งชื่อของฉันสำหรับตัวจัดการเหตุการณ์ GUI ฉันมักจะใช้มาตรฐาน VS ของ ControlName_Action และการควบคุมของฉันมักจะใช้สัญกรณ์ฮังการี (เป็นคำต่อท้ายเพื่อช่วยชี้แจงในรหัสสิ่งที่ผู้ใช้มองเห็นและสิ่งที่ไม่เมื่อจัดการกับตัวแปรที่มีชื่อคล้ายกัน) ดังนั้นฉันจึงจบลงด้วย OK_btn_Click ( ) คุณมีความเห็นอย่างไรต่อเรื่องนี้ ฉันควรยอมแพ้กับการประชุม ReSharper หรือมีตัวเลือกอื่น ๆ ที่ใช้ได้อย่างเท่าเทียมกัน?
11 c#  naming  resharper 

6
หมายเลขเวอร์ชั่นก่อนหน้าทำงานอย่างไรสำหรับผลิตภัณฑ์ใหม่
ตอนนี้ฉันกำลังเขียนแอปพลิเคชันเดสก์ท็อปขนาดเล็กสำหรับเพื่อน แต่ฉันกำลังทำมันเป็นประสบการณ์การเรียนรู้ด้วยตนเองเป็นหลัก ด้วยจิตวิญญาณของการได้รับการศึกษาและทำสิ่งที่ถูกต้องฉันต้องการมีหมายเลขรุ่นสำหรับแอปนี้ การวิจัยของฉันทำให้เกิดผลลัพธ์ที่เกี่ยวข้องเหล่านี้ คุณใช้ "แผนการตั้งชื่อเวอร์ชัน" อะไร คุณทำเวอร์ชันไฟล์อย่างไร (หมายเลขเวอร์ชัน) โครงการแยกที่หมายเลขเวอร์ชันของฉันเริ่มต้นที่ไหน แต่ไม่มีพวกเขาที่ระบุหมายเลขของอัลฟ่า, เบตา, ผู้สมัครอิสระ, & c ข้อตกลงสำหรับหมายเลขรุ่นต่ำกว่า 1.0 คืออะไร ฉันรู้ว่าพวกเขาสามารถไปบางครั้ง; ตัวอย่างเช่น PuTTY มีมานานอย่างน้อยหนึ่งทศวรรษและยังคงเป็นรุ่นเบต้า 0.60 เท่านั้น
11 naming 

4
ขั้นตอนการจัดเก็บ [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว หนึ่งในนักพัฒนาอาวุโสของเราระบุว่าเราควรใช้แบบแผนการตั้งชื่อสำหรับกระบวนการจัดเก็บด้วยรูปแบบการตั้งชื่อแบบ "objectVerb" เช่น ("MemberGetById") แทนการตั้งชื่อแบบ "verbObject" ("GetMemberByID") เหตุผลสำหรับมาตรฐานนี้คือกระบวนการที่เก็บไว้ทั้งหมดที่เกี่ยวข้องจะถูกจัดกลุ่มเข้าด้วยกันโดยวัตถุแทนที่จะกระทำ ในขณะที่ฉันเห็นตรรกะของวิธีการตั้งชื่อสิ่งต่าง ๆ นี่เป็นครั้งแรกที่ฉันได้เห็นกระบวนงานที่เก็บไว้ซึ่งตั้งชื่อด้วยวิธีนี้ ความเห็นของฉันเกี่ยวกับหลักการตั้งชื่อก็คือชื่อนั้นไม่สามารถอ่านได้อย่างเป็นธรรมชาติและใช้เวลาพอสมควรในการพิจารณาว่าคำพูดกำลังพูดถึงอะไรและกระบวนการนั้นควรทำอย่างไร คุณทำอะไรกับสิ่งนี้ วิธีการตั้งชื่อ proc ที่จัดเก็บโดยทั่วไปวิธีใดและคุณใช้อนุสัญญาการตั้งชื่อประเภท proc ที่เก็บไว้หรือไม่

3
ใน Java 8 จะดีกว่าการใช้นิพจน์การอ้างอิงเมธอดหรือเมธอดที่ส่งคืนการใช้อินเตอร์เฟสการทำงานหรือไม่?
Java 8 เพิ่มแนวคิดของส่วนต่อประสานการทำงานรวมถึงวิธีการใหม่มากมายที่ออกแบบมาเพื่อใช้งานส่วนต่อประสานการทำงาน อินสแตนซ์ของอินเทอร์เฟซเหล่านี้สามารถสร้างได้อย่างกระชับโดยใช้นิพจน์การอ้างอิงเมธอด (เช่นSomeClass::someMethod) และนิพจน์แลมบ์ดา (เช่น(x, y) -> x + y) เพื่อนร่วมงานและฉันมีความคิดเห็นที่แตกต่างกันเมื่อควรใช้แบบฟอร์มเดียวหรือแบบอื่น (ซึ่ง "ดีที่สุด" ในกรณีนี้จะทำให้ "อ่านได้ง่ายที่สุด" และ "สอดคล้องกับมาตรฐานการปฏิบัติทั่วไป" มากที่สุด เทียบเท่า) โดยเฉพาะกรณีนี้เกี่ยวข้องกับกรณีที่ข้อมูลต่อไปนี้เป็นจริงทั้งหมด: ฟังก์ชั่นที่เป็นปัญหาไม่ได้ใช้งานนอกขอบเขตเดียว การตั้งชื่อให้ช่วยให้สามารถอ่านได้ (ตรงข้ามกับตรรกะที่เรียบง่ายพอที่จะดูว่าเกิดอะไรขึ้นอย่างรวดเร็ว) ไม่มีเหตุผลการเขียนโปรแกรมอื่นทำไมรูปแบบหนึ่งจะดีกว่าอีกรูปแบบหนึ่ง ความเห็นของฉันในปัจจุบันเกี่ยวกับเรื่องนี้คือการเพิ่มวิธีการส่วนตัวและการอ้างอิงโดยวิธีการอ้างอิงเป็นวิธีที่ดีกว่า รู้สึกว่านี่เป็นวิธีที่คุณสมบัติถูกออกแบบมาให้ใช้และดูเหมือนง่ายขึ้นในการสื่อสารสิ่งที่เกิดขึ้นผ่านชื่อวิธีการและลายเซ็น (เช่น "บูลีน isResultInFuture (ผลผลลัพธ์)" ชัดเจนว่ากำลังส่งคืนบูลีน) นอกจากนี้ยังทำให้วิธีการส่วนตัวนำมาใช้ซ้ำได้มากขึ้นหากการปรับปรุงในอนาคตให้กับชั้นเรียนต้องการใช้ประโยชน์จากการตรวจสอบเดียวกัน แต่ไม่ต้องการเครื่องมือห่อหุ้มส่วนต่อประสานการทำงาน การตั้งค่าของเพื่อนร่วมงานของฉันคือการมีวิธีการที่ส่งกลับอินสแตนซ์ของอินเทอร์เฟซ (เช่น "Predicate resultInFuture ()") สำหรับฉันแล้วมันรู้สึกว่ามันไม่ได้เป็นวิธีที่จะใช้คุณสมบัติรู้สึก clunkier เล็กน้อยและดูเหมือนว่ามันยากที่จะสื่อสารความตั้งใจผ่านการตั้งชื่อ เพื่อให้ตัวอย่างคอนกรีตนี้นี่คือรหัสเดียวกันเขียนในสไตล์ที่แตกต่าง: public class ResultProcessor { public void …

1
หลักการตั้งชื่อสำหรับแพ็คเกจทดสอบ
เรากำลังตั้งชื่อแพคเกจการทดสอบของเราเหมือนกับชุดทดสอบที่จะทดสอบ ดังนั้นเราจึงจบลงด้วยโครงสร้างนี้: src/main/java com.hello.world helloWorld.java src/test/java com.hello.world helloWorldTest.java ฉันมักจะรู้สึกเช่นนี้ไม่ได้ฉลาดเพราะคุณไม่สามารถแยกความแตกต่างระหว่าง "ทดสอบ" และ "ทดสอบ" ถ้าให้กับชื่อแพคเกจเท่านั้น ในทางกลับกันฉันไม่ได้พบกรณีที่จริงเรื่องนี้อย่างใด เป็นการดีที่จะมีการตั้งชื่อแบบแผนเดียวกันสำหรับทั้งสองแพ็คเกจ (สำหรับกรณีทดสอบและคลาสที่มา)? ถ้าไม่สิ่งที่จะเป็นวิธีที่ดีกว่า
11 naming  packages 

3
หลายคลาสที่มีชื่อเดียวกัน แต่มีเนมสเปซที่แตกต่างกันใช่ไหม
ฉันพบรหัสบางส่วน (C # ถ้าสำคัญ) ที่มีคลาสที่มีชื่อเหมือนกัน แต่แตกต่างกันในเนมสเปซ พวกเขาทั้งหมดมีแนวโน้มที่จะเป็นตัวแทนของสิ่งเดียวกัน แต่มักจะ "มุมมอง" ที่แตกต่างกันของวัตถุเดียวกัน เนมสเปซที่แตกต่างกันนั้นเป็นส่วนหนึ่งของโซลูชันเดียวกันและแม้แต่ dll เดียวกัน ฉันมีความคิดของฉัน แต่ไม่พบสิ่งใดที่ชัดเจนเกี่ยวกับการปฏิบัตินี้เพื่อใช้เป็นเครื่องมือที่ฉลาดหรือมีรูปแบบที่ควรหลีกเลี่ยง คำถามเกี่ยวกับการตั้งชื่อ smurfสัมผัสนี้ แต่จากทิศทางอื่น การแก้ความสงสัยในชื่ออาจต้องการคำนำหน้าโดยพลการและแพร่หลายซึ่งคำถามนั้นต้องการกำจัด แนวทางการปฏิบัตินี้มีอะไรบ้าง?
11 naming 

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

4
อะไรคือชื่อของอาร์กิวเมนต์การทำงานในเท่า
ในการสั่งซื้อฟังก์ชั่นที่สูงขึ้นพับ / ลดชื่อของการโต้แย้งการทำงานคืออะไรถ้ามี? ฉันกำลังทำงานกับไลบรารีการประมวลผลแบบตารางเดี่ยวที่แถวถูกพับเพื่อทำการวิเคราะห์อย่างง่าย (เช่นการค้นหาคอลัมน์ขั้นต่ำสูงสุดและค่าเฉลี่ย) ฉันกำลังมองหาชื่อเสียงสำหรับการโต้แย้งของfoldฟังก์ชั่นและชื่อใด ๆ ที่เป็นที่ยอมรับในชุมชน ML (หรือ Haskell หรือ Common LISP ในฐานะผู้สมัครที่สองและสาม) น่าสนใจ ชื่อชอบfเป็นเรื่องธรรมดาในคำอธิบายของfoldฟังก์ชั่น แต่มันไม่ได้อธิบายและคำนามจะเหมาะกว่า

3
ข้อใดจะดีกว่าสำหรับการแก้ไขข้อบกพร่องเล็ก ๆ และคุณสมบัติขนาดเล็ก - ตั้งชื่อสาขาตามหมายเลขตั๋วหรือตั้งชื่อพวกเขาตามคำอธิบายคุณลักษณะ?
ฉันอยู่ในช่วงกลางของความไม่ลงรอยกัน (แน่นอน) ด้วยความเป็นผู้นำของฉันเกี่ยวกับการตั้งชื่อสาขาที่เหมาะสม สิ่งนี้ใช้กับสาขาการแก้ไขข้อบกพร่องและสาขาคุณลักษณะขนาดเล็กไม่ใช่สาขาคุณลักษณะระยะยาว สำหรับสาขาคุณลักษณะที่ใช้เวลานานเรายอมรับว่าชื่อที่มนุษย์อ่านได้ดีกว่า ต่อไปนี้เป็นมุมมองสองประการ: เหมืองแร่: การตั้งชื่อสาขาตามทีมและหมายเลขตั๋วจะดีกว่า มันทำให้ง่ายต่อการค้นหาในระบบตั๋วของเราและพิมพ์ให้สั้นลง นอกจากนี้ยังช่วยให้ค้นหาสาขาที่เกี่ยวข้องใน GIT ได้ง่ายขึ้นเมื่อค้นหาข้อมูลประวัติเกี่ยวกับตั๋ว ตัวอย่าง: team-name/12345 team-name/53719 ของพระองค์ การตั้งชื่อสาขาตามคุณสมบัติ / ฟังก์ชั่น มันทำให้การเติมข้อความอัตโนมัติง่ายขึ้นและจดจำได้ง่ายกว่าตัวเลขแต่ละตัว ตัวอย่าง: team-name/fix-that-sql-bug team-name/expand-http-parser การประนีประนอมอย่างหนึ่งที่ฉันเสนอคือ: team-name/12345-fix-that-sql-bug แต่เขาไม่ชอบสิ่งนี้เพราะมันยุ่งกับการเติมข้อความอัตโนมัติของ GIT หากนี่คือพื้นฐานความคิดเห็นโปรดอย่าลังเลที่จะให้คำแนะนำฉันเกี่ยวกับวิธีการนี้เหมาะสำหรับ SO - แต่ฉันคิดว่าเหตุผลที่ฉันให้สามารถแก้ไข / เพิ่มเติมเพื่อให้คำตอบเชิงประจักษ์

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

6
สิ่งใดที่คุณเรียกคลาสที่ไม่มีเมธอด
สิ่งใดที่คุณเรียกคลาสที่ไม่มีเมธอด ตัวอย่างเช่น, class A { public string something; public int a; } ด้านบนเป็นคลาสที่ไม่มีวิธีการใด ๆ คลาสประเภทนี้มีชื่อพิเศษหรือไม่?

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

3
อะไรคือเหตุผลเบื้องหลัง“ I” แบบแผนการตั้งชื่อนำหน้าสำหรับอินเตอร์เฟสใน. NET?
ฉันรู้ว่าการประชุม "ฉัน" เป็นเรื่องที่เกิดขึ้นตั้งแต่ COM แต่ฉันไม่เคยเข้าใจเลยว่าทำไมมันถึงไม่ได้รับการพิจารณาเหมือนการประชุมตั้งชื่ออื่น ๆ ทุกครั้งก่อนที่. การบริโภคที่ชาญฉลาดสิ่งเดียวที่แยกอินเทอร์เฟซออกจากกันคือคลาสนามธรรมคือพวกมันสามารถสืบทอดได้หลายทาง แต่ทุกอย่างหลังจาก Visual Studio 2003 ได้แสดงลายเซ็นประเภทในคำแนะนำเครื่องมือมันไม่มีประโยชน์เหมือนกับสัญลักษณ์ฮังการีอื่น ๆ ทั้งหมดที่ถูกทิ้งไป ฉันคิดว่าอาจเป็นเช่นนั้นเพื่อให้คุณสามารถใช้งานอินเทอร์เฟซพื้นฐานที่มีชื่อเดียวกันเช่นการMessageสืบทอดIMessageแต่ไลบรารี NET ส่วนใหญ่ได้หายไปสำหรับการเพิ่มคำว่า "Base" ที่ท้าย (เช่นSystem.Collections.ReadOnlyCollectionBase) แทน - และสิ่งนี้ทำให้รู้สึกความหมายมากขึ้น การทำงานร่วมกันของ COM น่าจะเป็นอีกเหตุผลหนึ่งที่เป็นไปได้ - แต่ไม่ใช่ว่าคลาสของ wrapper ที่มันสร้างนั้นมีความแปลกประหลาดอย่างสมบูรณ์ใน. NET ดังนั้นฉันจึงสงสัยว่านั่นเป็นการพิจารณาด้านสุนทรียภาพ ในโครงการใหม่ของฉันฉันลืมการประชุมทั้งหมดและรู้สึกดี มีบางอย่างที่ฉันขาดหายไปหรือไม่?
10 .net  naming 

2
ข้อตกลงการตั้งชื่อแบบเฉพาะคลาส Java คลาส
ฉันต้องสร้างอะแดปเตอร์ระหว่างซอฟต์แวร์สองตัว (การจำลองด้วย mech, ไม่ใช่ cs) ThatThingสมมติว่าเรามีระดับที่ชื่อว่า ฉันต้องจัดการกับการใช้งานเฉพาะของผู้ขายต่าง ๆ เวอร์ชันเหล่านี้ไม่มีชื่อที่มีความหมาย (ต่างจาก eclipse helios, indigo เป็นต้น) 1. ฉันจะตั้งชื่อคลาสที่ควรแสดงหมายเลขเวอร์ชั่นได้อย่างไร ผมพบว่าชั้นชอบThatThing_3_6_Impl, ThatThing_3_7_Implค่อนข้างอึดอัด
10 java  naming 

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.