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

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

11
ทำไมตัวบ่งชี้แบบสั้นที่เป็นความลับยังคงเป็นเรื่องปกติในการเขียนโปรแกรมระดับต่ำ
เคยมีเหตุผลที่ดีมากในการรักษาชื่อคำสั่ง / ทะเบียนย่อ เหตุผลเหล่านั้นใช้ไม่ได้อีกต่อไป แต่ชื่อรหัสลับสั้น ๆ ยังคงพบได้บ่อยในการเขียนโปรแกรมระดับต่ำ ทำไมนี้ มันเป็นเพราะนิสัยเก่านั้นยากที่จะทำลายหรือมีเหตุผลที่ดีกว่า? ตัวอย่างเช่น: Atmel ATMEGA32U2 (2010?): TIFR1(แทนTimerCounter1InterruptFlag), ICR1H(แทนInputCapture1High), DDRB(แทนDataDirectionPortB), ฯลฯ ชุดคำสั่ง. NET CLR (2002): bge.s(แทนbranch-if-greater-or-equal.short) ฯลฯ ชื่อที่ไม่ได้เป็นความลับใช้งานได้นานกว่าหรือไม่ เมื่อตอบและลงคะแนนโปรดพิจารณาสิ่งต่อไปนี้ คำอธิบายที่เป็นไปได้หลายข้อเสนอแนะที่นี่นำไปใช้อย่างเท่าเทียมกันกับการเขียนโปรแกรมระดับสูงและยังเป็นฉันทามติโดยและขนาดใหญ่คือการใช้ชื่อที่ไม่เป็นความลับประกอบด้วยคำหรือสอง (คำย่อเข้าใจกันโดยทั่วไป) นอกจากนี้หากข้อโต้แย้งหลักของคุณเกี่ยวกับพื้นที่ทางกายภาพในแผนภาพกระดาษโปรดพิจารณาว่าสิ่งนี้ไม่สามารถใช้ได้กับภาษาแอสเซมบลีหรือ CIL อย่างแน่นอนและฉันจะขอบคุณถ้าคุณแสดงแผนภาพที่ชื่อ terse พอดี แต่คนอ่านทำให้แผนภาพแย่ลง . จากประสบการณ์ส่วนตัวที่ บริษัท เซมิคอนดักเตอร์ fabless ชื่อที่อ่านได้พอดีใช้ได้ดีและทำให้ไดอะแกรมอ่านง่ายขึ้น อะไรคือสิ่งที่สำคัญที่แตกต่างเกี่ยวกับการเขียนโปรแกรมระดับต่ำเมื่อเทียบกับภาษาระดับสูงที่ทำให้ชื่อที่เป็นความลับสั้น ๆ เป็นที่ต้องการในการเขียนโปรแกรมระดับต่ำ แต่ไม่ใช่การเขียนโปรแกรมระดับสูง

4
การตั้งชื่อคลาส: เอกพจน์หรือพหูพจน์ [ปิด]
เป็นเรื่องยากสำหรับฉันที่จะเลือกรูปแบบเอกพจน์และพหูพจน์สำหรับชื่อคลาส: CustomerRepository vs. CustomersRepository CustomerService vs. CustomersService CustomerController vs. CustomersController และสำหรับชื่อคอมโพสิตมันก็ยิ่งยากขึ้น: OrderCustomerRepository กับ OrderCustomersRepository เทียบกับ OrdersCustomersRepository คุณชอบแนวทางใดและทำไม


4
หลักการตั้งชื่อที่โดดเด่นสำหรับตัวแปรใน PHP คือ camelcase หรือขีดล่าง? [ปิด]
ฉันทามติดูเหมือนว่าควรจะทำตามแบบแผนของแพลตฟอร์มที่พวกเขากำลังพัฒนา ดู: ขีดเส้นใต้หรืออูฐ? ข้อกำหนดการตั้งชื่อ: camelCase กับ underscore_case หรือไม่ อย่างไรก็ตาม, PHP ดูเหมือนจะไม่ปฏิบัติตามอย่างเคร่งครัดการประชุมใด ๆ ภายใน (ความผิดไม่มี) แม้สำหรับวิธีการและฟังก์ชั่น (เช่นmysqli::set_local_infile_default, PDOStatement::debugDumpParams); อย่างไรก็ตามเครื่องหมายขีดล่างดูเหมือนจะโดดเด่นในชื่อฟังก์ชัน อย่างไรก็ตามสิ่งที่ฉันไม่สามารถหาได้คือสิ่งนี้: อะไรคือหลักการตั้งชื่อที่เด่นชัดสำหรับตัวแปรใน PHP?

2
ฉันควรใช้“ is” เป็นคำนำหน้าสำหรับตัวแปรบูลีนเสมอหรือไม่ [ปิด]
ฉันควรใช้isเป็นคำนำหน้าสำหรับตัวแปรบูลีนเสมอหรือไม่ สิ่งที่เกี่ยวกับ booleans ที่บ่งบอกถึงบางสิ่งบางอย่างในอดีต? ฉันควรจะเขียนisInitializedหรือwasInitialized? ฉันควรเขียนถึงคุณสมบัติIsManyMembersหรือHasManyMembersไม่? มีวิธีปฏิบัติที่ดีที่สุดหรือไม่? หรือฉันควรเขียนตามกฎภาษาอังกฤษ?

7
วิธีตั้งชื่อตัวแปรเมื่อคำนั้นเป็นทั้งคำนามและคำกริยา
ฉันพบปัญหากรณีมุมด้วยคำแนะนำทั่วไปของ: คำนามสำหรับตัวแปร คำกริยาสำหรับฟังก์ชั่น โดยเฉพาะฉันมีกรณีที่คำไม่ชัดเจน - มันอาจเป็นทั้งคำกริยาหรือคำนาม และในบางกรณีเมื่อเราพูดถึงแอปพลิเคชันมันจะถูกใช้ทั้งสองวิธีในประโยคเดียวกัน ความตั้งใจของฉันคือเพื่อให้แน่ใจว่าโปรแกรมจะยังคงสามารถอ่านได้สำหรับนักพัฒนาในอนาคตเช่นเดียวกับตัวฉันเองเมื่อฉันกลับไปยังส่วนของรหัสเดือนต่อมา batteryหนึ่งในตัวอย่างที่เป็นด้วย A batteryมีchargeและคุณยังสามารถcharge()ใช้แบตเตอรี่ได้อีกด้วย ฉันคิดว่าการมีทั้งคู่Battery.ChargeและBattery.Charge(value)จะสับสนกับนักพัฒนาในอนาคต โซลูชันปัจจุบันของฉันคือเลือกคำที่แตกต่างสำหรับกรณีเหล่านี้หนึ่งหรือทั้งสองกรณี (ตัวแปรและฟังก์ชัน) ปัญหาของฉันด้วยวิธีการที่เป็นBatteryตัวแปรวัตถุและฟังก์ชั่นจะไม่สอดคล้องกับการอภิปรายการออกแบบที่เกี่ยวข้องกับการ chargeBattery คำถามของฉันคือถ้ามีอีกวิธีที่ดีกว่า / จัดการความขัดแย้งนี้ในการตั้งชื่อแบบแผนการ? อ่านเพิ่มเติมบางเรื่อง ไม่มีใครตอบคำถามของฉันโดยเฉพาะ แนวทางการตั้งชื่อวิธีการกระชับความหมายที่มีความหมาย แบบแผนการตั้งชื่อตัวแปร คำตอบที่เลือกจากhttps://softwareengineering.stackexchange.com/questions/14169/what-naming-guidelines-do-you-follow
48 naming  variables 

9
วิธีและเหตุผลในการตัดสินใจระหว่างวิธีการตั้งชื่อด้วยคำนำหน้า "รับ" และ "ค้นหา"
ฉันมักจะมีปัญหาในการหาว่าผมควรจะตั้งชื่อวิธีการบางอย่างที่เริ่มต้นด้วยเมื่อเทียบกับgetSomethingfindSomething ปัญหาอยู่ในการสร้างผู้ช่วยเหลือสำหรับ API ที่ออกแบบมาไม่ดี สิ่งนี้มักจะเกิดขึ้นเมื่อรับข้อมูลจากวัตถุซึ่งต้องการวัตถุเป็นพารามิเตอร์ นี่คือตัวอย่างง่ายๆ: public String getRevision(Item item) { service.load(item, "revision"); // there is usually more work to do before getting the data.. try { return item.get_revision(); } catch(NotLoadedException exception) { log.error("Property named 'property_name' was not loaded", exception); } return null; } วิธีการและเหตุผลในการตัดสินใจระหว่างการตั้งชื่อวิธีการนี้เป็นgetRevision()หรือfindRevision()?
47 naming  methods 

12
การสะกดผิดโดยเจตนาเพื่อหลีกเลี่ยงคำที่สงวนไว้
ฉันมักจะเห็นรหัสที่มีการสะกดผิดโดยเจตนาของคำทั่วไปที่ดีขึ้นหรือแย่ลงกลายเป็นคำสงวน: klassหรือclazzสำหรับชั้นเรียน :Class clazz = ThisClass.class kountสำหรับการนับใน SQL:count(*) AS kount โดยส่วนตัวแล้วฉันพบว่าการอ่านนี้ลดลง ในทางปฏิบัติของฉันเองฉันไม่ได้พบมากเกินไปกรณีที่ชื่อที่ดีกว่าอาจจะไม่ได้ถูกนำมาใช้ - หรือitemClassrecordTotal ตัวอย่างจาก JavaDocs สำหรับClassแสดงสิ่งนี้ในพารามิเตอร์: public <U> Class<? extends U> asSubclass(Class<U> clazz) นี่แสดงให้เห็นถึงกรณีการใช้งานที่สมเหตุสมผลหรือไม่?

15
มันเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่ที่จะตั้งชื่อตัวแปรที่ไม่ได้ใช้ด้วยการขีดเส้นใต้เดี่ยว?
_บ่อยครั้งเมื่อไวยากรณ์ของภาษาต้องการให้ฉันชื่อตัวแปรที่ไม่เคยใช้ผมจะตั้งชื่อมันว่า ในใจของฉันมันช่วยลดความยุ่งเหยิงและให้ฉันมุ่งเน้นไปที่ตัวแปรที่มีความหมายในโค้ด ฉันคิดว่ามันจะไม่เป็นการรบกวนเพื่อสร้างผล "นอกสายตาจากใจ" ตัวอย่างทั่วไปที่ฉันทำคือการตั้งชื่อแบบสอบถามย่อยใน SQL SELECT * FROM ( SELECT * FROM TableA JOIN TableB ON TableA.ColumnB = TableB.ColumnB WHERE [ColumnA] > 10 ) _ --This name is required, but never used here ORDER BY ColumnC อีกตัวอย่างหนึ่งคือตัวแปรลูปที่ไม่ได้ใช้ array = [[] for _ in range(n)] # Defines a list of …

17
เป็นวิธีปฏิบัติที่ดีหรือไม่ที่จะตั้งชื่อตัวแปร“ return” ที่ส่งคืน [ปิด]
เป็นวิธีปฏิบัติที่ดีในการเรียกใช้ตัวแปรที่เมธอดส่งคืนด้วยชื่อตัวแปรresultหรือไม่? ตัวอย่างเช่น public Zorglub calculate() { Zorglub result = [...] [...] return result; } หรือฉันควรตั้งชื่อตามประเภทของมัน? public Zorglub calculate() { Zorglub zorglub = [...] [...] return zorglub; } ฉันเคยเห็นทั้งสองอย่างในป่าถ้าฉันต้องเลือกเหตุผลอะไรที่ทำให้ฉันชอบอดีตหรือหลัง (หรือชื่อที่ดีกว่า)? ฉันคิดเกี่ยวกับ Java เป็นหลัก

3
บูลีนการตั้งชื่อวิธียืนยันและเชิงลบ
วิธีการบูลีนควรใช้รูปแบบการยืนยันเสมอแม้ว่าจะใช้ในรูปแบบเชิงลบหรือไม่? สมมติว่าฉันต้องการตรวจสอบว่ามีเอนทิตีอยู่ก่อนสร้างหนึ่งหรือไม่อาร์กิวเมนต์ของฉันคือว่ารูปแบบแรกด้านล่างดีกว่ารูปแบบที่สองไม่ว่าจะใช้วิธีการนี้ในรูปแบบที่ยืนยันหรือไม่ โดยสรุปผมหาอ่านได้ง่ายขึ้นกว่าif(!affirmative) if(negative)ฉันมีเพื่อนร่วมงานที่ไม่เห็นด้วยความคิดเหรอ? แบบฟอร์มแรก: int entity_id = 42; if(!entity_exists(entity_id)) create_entity(entity_id); แบบฟอร์มที่สอง: int entity_id = 42; if(entity_not_exist(entity_id)) create_entity(entity_id);
43 naming  functions 

7
การแปลข้อมูลภายนอกเป็นภาษาที่คุณกำลังตั้งโปรแกรม
ฉันไม่แน่ใจว่าจะทำอย่างไรกับสิ่งต่อไปนี้: เราใช้ข้อมูลจากเครื่องมือภายนอกภายในเครื่องมือของเราเอง ข้อมูลนี้เขียนเป็นภาษาดัตช์ เรากำลังเขียนโค้ด Java ของเราเป็นภาษาอังกฤษ เราควรแปลภาษาดัตช์นี้เป็นภาษาอังกฤษหรือแปลเป็นภาษาดัตช์ ตัวอย่างเช่นเรามี 2 แผนกคือ Bouw (ก่อสร้างเป็นภาษาอังกฤษ) และ Onderhoud (บำรุงรักษาเป็นภาษาอังกฤษ) มันจะเป็นตรรกะในการสร้าง: public enum Department { BOUW, ONDERHOUD } หรือ: public enum Department { CONSTRUCTION, MAINTENANCE } หรือแม้กระทั่ง: public enum Afdeling { BOUW, ONDERHOUD } (ผู้ที่สนใจคือแผนกในภาษาดัตช์)
39 naming  translate 

5
ปัญหาเกี่ยวกับการหลีกเลี่ยงการเรียนการตั้งชื่อ Smurf กับ namespaces
ฉันดึงคำว่า smurf ตั้งชื่อจากที่นี่ (หมายเลข 21) ในการบันทึกทุกคนที่ไม่คุ้นเคยปัญหาที่ Smurf การตั้งชื่อคือการกระทำของ prefixing พวงของการเรียนที่เกี่ยวข้องกับตัวแปรอื่น ๆ ที่มีคำนำหน้าร่วมกันเพื่อให้คุณจบลงด้วยการที่ " SmurfAccountViewผ่านSmurfAccountDTOไปSmurfAccountController" ฯลฯ วิธีแก้ปัญหาที่ฉันเคยได้ยินโดยทั่วไปคือการสร้าง smurf namespace และวางคำนำหน้า smurf โดยทั่วไปฉันใช้งานได้ดี แต่ฉันพบปัญหาสองอย่าง ฉันทำงานกับห้องสมุดที่มีConfigurationชั้นเรียน มันอาจจะได้รับการเรียกWartmongerConfigurationแต่ก็ใน namespace Wartmonger Configurationจึงเรียกว่าเพียงแค่ ฉันก็มีConfigurationคลาสที่สามารถเรียกSmurfConfigurationได้ แต่มันอยู่ในเนมสเปซ Smurf เพื่อที่จะซ้ำซ้อน มีสถานที่ในรหัสของฉันที่Smurf.Configurationปรากฏอยู่ด้านข้างWartmonger.Configurationและพิมพ์ชื่อที่ผ่านการรับรองครบถ้วนแล้วเป็น clunky และทำให้โค้ดอ่านน้อยลง มันจะดีกว่าที่จะจัดการกับSmurfConfigurationและ WartmongerConfiguration(ถ้ามันเป็นรหัสและไม่ห้องสมุดของฉัน) ฉันมีคลาสที่เรียกว่าServiceในเนมสเปซ Smurf ซึ่งอาจเรียกได้ว่าSmurfServiceเป็น Serviceเป็นส่วนหน้าของห้องสมุด Smurf ที่ซับซ้อนซึ่งดำเนินงาน Smurf SmurfServiceดูเหมือนชื่อที่ดีกว่าเพราะServiceไม่มีคำนำหน้า Smurf เป็นเรื่องธรรมดาอย่างไม่น่าเชื่อ ฉันยอมรับได้ว่าSmurfServiceชื่อสามัญไร้ประโยชน์อยู่แล้วและการกำจัด smurf ทำให้สิ่งนี้ชัดเจนยิ่งขึ้น แต่มันจะได้รับการตั้งชื่อRunner, …

5
มันเพียงพอสำหรับวิธีการที่จะโดดเด่นเพียงแค่ชื่ออาร์กิวเมนต์ (ไม่พิมพ์)?
มันเพียงพอสำหรับวิธีการที่จะโดดเด่นเพียงแค่ชื่ออาร์กิวเมนต์ (ไม่พิมพ์) หรือมันจะดีกว่าที่จะตั้งชื่ออย่างชัดเจนมากขึ้น? ยกตัวอย่างเช่นVST Find<T>(int id)T FindById<T>(int id) มีเหตุผลที่ดีที่จะตั้งชื่ออย่างชัดเจนยิ่งขึ้น (เช่นการเพิ่มById) และการเก็บชื่ออาร์กิวเมนต์เพียงอย่างเดียวหรือไม่ เหตุผลหนึ่งที่ฉันคิดได้ก็คือเมื่อลายเซ็นของวิธีการเหมือนกัน แต่มีความหมายแตกต่างกัน FindByFirstName(string name) และ FindByLastName(string name)

10
รูปแบบการต่อต้านการตั้งชื่ออะไรอยู่? [ปิด]
มีบางชื่อที่ถ้าคุณพบว่าตัวเองชื่อคุณรู้ว่าคุณได้ทำบางสิ่งบางอย่างสับสน ตัวอย่างเช่น: XxxManager สิ่งนี้ไม่ดีเนื่องจากคลาสควรอธิบายว่าคลาสทำอะไร หากคำที่เฉพาะเจาะจงที่สุดที่คุณสามารถคิดได้ในสิ่งที่ชั้นเรียนทำคือ "จัดการ" ชั้นเรียนนั้นใหญ่เกินไป มีรูปแบบการต่อต้านการตั้งชื่ออื่น ๆ อีกบ้าง? เพื่อความกระจ่างแจ้งฉันไม่ได้ถามว่า "ชื่ออะไรไม่ดี" - คำถามนั้นเป็นอัตนัยทั้งหมดและไม่มีวิธีการตอบ ฉันถามว่า "ชื่ออะไรบ่งบอกถึงปัญหาการออกแบบโดยรวมของระบบ" นั่นคือถ้าคุณพบว่าตัวเองต้องการที่จะเรียก Xyz ส่วนประกอบนั่นอาจบ่งบอกว่าส่วนประกอบนั้นไม่สบาย โปรดทราบว่าที่นี่มีข้อยกเว้นสำหรับทุกกฎ - ฉันแค่มองหาธงคำเตือนเมื่อฉันต้องหยุดและคิดทบทวนการออกแบบใหม่

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