ข้อกำหนดการตั้งชื่อ: camelCase กับ underscore_case หรือไม่ คุณคิดอย่างไรเกี่ยวกับเรื่องนี้? [ปิด]

ฉันใช้ underscore_case ประมาณ 2 ปีและฉันเพิ่งเปลี่ยนมาใช้ camelCase เนื่องจากงานใหม่ (ใช้งานในภายหลังประมาณ 2 เดือนและฉันยังคิดว่า underscore_case เหมาะกว่าสำหรับโครงการขนาดใหญ่ที่มีโปรแกรมเมอร์จำนวนมากเข้าร่วม ส่วนใหญ่เป็นเพราะรหัสอ่านง่ายกว่า)

ตอนนี้ทุกคนในที่ทำงานใช้ camelCase เพราะ (ดังนั้นพวกเขาบอกว่า) โค้ดดูสง่างามกว่า

คุณคิดอย่างไรเกี่ยวกับ camelCase หรือ underscore_case

ป.ล. โปรดแก้ตัวภาษาอังกฤษไม่ดีของฉัน

แก้ไข

อัปเดตก่อน:

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

• ฉันใช้ camelCase เช่นเดียวกับ everibody ในทีม (เหมือนกับที่พวกคุณส่วนใหญ่แนะนำ)

• เราใช้ Zend Framework ซึ่งแนะนำ camelCase ด้วย

ตัวอย่างบางส่วน (เกี่ยวข้องกับ PHP):

• กรอบงาน Codeigniter แนะนำ underscore_case และโดยสุจริตรหัสจะอ่านง่ายขึ้น

• ZF แนะนำ camelCase และฉันไม่ใช่คนเดียวที่คิดว่ารหัส ZF นั้นยากกว่าที่จะทำตาม

ดังนั้นคำถามของฉันจะถูกนำมาใช้ใหม่:

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

ป.ล. ขอบคุณทุกคนสำหรับคำตอบทันที

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

แต่ในกรณีที่มีทางเลือกฉันชอบขีดเส้นใต้ของอูฐด้วยเหตุผลง่าย ๆ : ฉันพบว่าสไตล์อ่านง่ายกว่า นี่คือตัวอย่าง: คุณพบว่าสามารถอ่านได้มากขึ้น? นี้:

aRatherLongSymbolName

หรือสิ่งนี้:

a_rather_long_symbol_name

ฉันพบว่ารุ่นขีดล่างอ่านง่ายกว่ามาก สมองของฉันสามารถละเว้นขีดได้ง่ายกว่าที่จะสามารถตรวจสอบขอบเขตตัวพิมพ์เล็ก / พิมพ์ใหญ่ในกรณีอูฐโดยเฉพาะอย่างยิ่งที่เขตแดนที่อยู่ระหว่างร่ายมนตร์ที่มีลักษณะคล้ายกับการร่ายมนตร์อื่น ๆ ของกรณีตรงข้ามหรือเลข ( I/l, O/0, t/Iฯลฯ ) ตัวอย่างเช่นตัวแปรบูลีนนี้เก็บค่าที่ระบุว่า Igloo ถูกสร้างขึ้นโดยได้รับอนุญาตการวางแผนที่เหมาะสม (ไม่ต้องสงสัยว่าเป็นกรณีการใช้งานทั่วไปสำหรับเราทุกคน):

isIllicitIgloo

ฉันพบว่ารุ่นนี้อ่านง่ายกว่ามาก :

is_illicit_igloo

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

ฉันคิดว่าคุณควรใช้หลักการตั้งชื่อที่นำมาใช้โดยแพลตฟอร์มของคุณ underscore_case จะดูแปลกในรหัส C # เป็น camelCase ใน Ruby =)

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

จากการตอบกลับคำตอบของ John Isaacks:

"สุจริตรหัสง่ายต่อการอ่าน" ความเห็นหรือความจริง?

ฉันตัดสินใจทำการวิจัยและพบกระดาษนี้ วิทยาศาสตร์ต้องพูดอะไรในเรื่องนี้?

1. ปลอกอูฐมีความน่าจะเป็นที่ถูกต้องมากกว่าขีดล่าง (ราคาต่อรองสูงกว่า 51.5%)
2. โดยเฉลี่ยแล้วกรณีของอูฐใช้เวลานานขึ้น 0.42 วินาทีซึ่งนานกว่า 13.5%
3. การฝึกอบรมไม่มีผลกระทบอย่างมีนัยสำคัญทางสถิติว่าสไตล์มีอิทธิพลต่อความถูกต้องอย่างไร
4. ผู้ที่มีการฝึกอบรมเพิ่มเติมนั้นเร็วขึ้นในตัวระบุในรูปแบบของอูฐ
5. การฝึกอบรมในรูปแบบเดียวส่งผลเสียต่อเวลาค้นหาสไตล์อื่น ๆ

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

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

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

คัดลอกคนที่ฉลาดที่สุด

ในกรณีของภาษาการเขียนโปรแกรมให้คัดลอกสไตล์ของผู้พัฒนาภาษา

เช่นฉันรหัส C ตรงตามที่ทำใน K&R

จากนั้นเมื่อมีคนพยายามเริ่มการสนทนาสไตล์การเขียนโค้ดที่น่าเบื่อฉันสามารถบอกพวกเขาได้ว่า "นำเรื่องนั้นมากับเดนนิสริตช์

โดยทั่วไปแล้วฉันชอบ camelCase อย่างไรก็ตามนั่นเป็นเพราะอาชีพส่วนใหญ่ของฉันฉันได้ทำงานในภาษาและสภาพแวดล้อมที่ปกติแล้วไกด์สไตล์จะแนะนำ camelCase (Java, ECMAScript, C ++) คุณในฐานะบุคคล PHP มีแนวโน้มที่จะมีสิ่งที่ตรงกันข้าม

ที่กล่าวว่าเมื่อคุณไปเกินสามหรือวลีหรือถ้าคุณใช้การเริ่มต้นเช่น XmlForExample ก็หยุดอ่านได้

นั่นคือเหตุผลที่ emac ทำให้โหมดแว่นตาของเรา

CamelCase

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

สมมติว่าโครงการไม่ได้สร้างบน codebase ที่มีอยู่ด้วยมาตรฐานที่แตกต่าง

เป็นคำถามที่น่าสนใจฉันคิดหลายครั้ง แต่ไม่มีคำตอบที่ชัดเจนฉันคิดว่า

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

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

ขึ้นอยู่กับภาษาการเขียนโปรแกรม

ฉันพิจารณาใช้เคสในเรือลำเดียวกันว่าจะใช้สัญกรณ์ฮังการีหรือไม่:

• Python: underscore_case, ไม่มีสัญกรณ์ฮังการี
• C ++: camelCase, สัญลักษณ์ของฮังการี

ทั้งสอง!

ฉันทำการพัฒนามากมายใน CakePHP และฉันใช้อย่างใดอย่างหนึ่งCamelCaseหรือ$underscored_varsตามแฟชั่นต่อไปนี้ (แม้อยู่นอกโครงการ CakePHP):

1. ชื่อไฟล์ - /lowercased_underscored.phpทั่วไป แต่ควรกล่าวถึง
2. เรียนclass CamelCase extends ParentObject - โปรดทราบว่าเมื่อใช้CamelCaseงานอักขระเริ่มต้นจะไม่เป็นตัวพิมพ์เล็ก ฉันพบว่าcamelCaseมันดูแปลก จริงๆ
3. ตัวแปร -$are_variables_underscored === TRUE;
4. ตัวแปรที่เก็บอินสแตนซ์ -$CamelCase = new CamelCase();
5. ปุ่มอาร์เรย์ -$collection['underscored_keys'];
6. ค่าคงที่ - ALL_CAPS_AND_UNDERSCOREDฉันคิดว่าทุกคนสามารถยอมรับว่าค่าคงที่ควรจะเป็น
7. วิธีการ -$CamelCase->foo_method_underscored();
8. วิธีการคงที่ -CamelCase::just_like_regular_methods();

โดยส่วนตัวแล้วฉันชอบunderscore_caseเพราะฉันเห็นว่าอ่านง่ายกว่า แต่เห็นด้วยกับผู้ตอบคนอื่น ๆ ที่ชี้ให้เห็นว่าความสอดคล้องกับ codebase ที่มีอยู่นั้นมีความสำคัญมากกว่า

อย่างไรก็ตามฉันมีตัวอย่างสำหรับผู้ที่พูดว่า "ทำตามแบบแผนของภาษาและห้องสมุดของคุณ"

ในอดีตเราเขียนรหัส C บน Windows โดยใช้underscore_caseและเรียกPascalCaseใช้ฟังก์ชัน Win32:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

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

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

ฉันชอบเครื่องหมายขีดคั่นแบบปกติธรรมดาของ Dylan พวกเขาเป็นแบบง่ายต่อการอ่านและง่ายต่อการอ่าน

ชอบ

result-code := write-buffer(file-stream, some-string)

แต่ฉันเดาว่าภาษานี้ค่อนข้างคลุมเครือนี่เป็นหัวข้อนอกเรื่อง ... :(

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

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

และอย่าสับสนนี่ไม่ได้เกี่ยวกับความสามารถในการอ่าน (ซึ่งเป็นเรื่องส่วนตัว) มันเกี่ยวกับความสอดคล้องและความเป็นมืออาชีพ ทุกคนที่ทำงานใน codebase ที่มีมาตรฐานเป็นจำนวนมากจะเข้าใจ

ฉันใช้มิกซ์บางครั้ง: module_FunctionName ฟังก์ชันทั้งหมด (ไม่คงที่) ในโมดูลของฉันเริ่มต้นด้วยตัวย่อของโมดูล

ตัวอย่างเช่นฟังก์ชั่นสำหรับส่งเนื้อหาบัฟเฟอร์บนบัส I2C:

i2c_BufferSend()

ทางเลือกi2c_buffer_sendไม่แสดงการแยกขนาดใหญ่พอระหว่างคำนำหน้าและชื่อฟังก์ชัน i2cBufferSendผสมในส่วนนำหน้ามากเกินไป (มีฟังก์ชั่น I2C ค่อนข้างมากในโมดูลนี้)

i2c_Buffer_send อาจเป็นทางเลือกแม้ว่า

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

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why

โดยส่วนตัวแล้วฉันชอบ camelCase แต่ในบางฟอนต์ฉันคิดว่าขีดล่างอ่านง่ายกว่า

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

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

ในทำนองเดียวกันหากคุณต้องการแยกความแตกต่างของประเภททำไมไม่ใช้ภาษาที่อนุญาต

var intThingy = 7; // :(

int thingy = 7;    // :)

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

ตอนแรกฉันเห็นด้วยกับ dafmetal มันมีความสำคัญสูงสุดที่คุณไม่ได้ผสมผสานรูปแบบการเขียนโปรแกรมที่แตกต่างกัน การทำเช่นนี้ในไฟล์เดียวและเป็นไฟล์ที่แย่ที่สุดที่คุณสามารถทำได้ IMHO ข้ามไฟล์ที่แตกต่างกันมันเสียสมาธิ แต่ไม่ถึงกับเสียชีวิต

สิ่งต่อไปที่คุณต้องทำคือการตั้งชื่อกฎที่เป็นที่นิยมสำหรับภาษาที่คุณกำลังเขียนรหัส C ++ ของฉันสำหรับ instnace จะดูแตกต่างจาก Python อย่างชัดเจน (PEP8 เป็นคำแนะนำที่ดีที่นี่)

คุณสามารถใช้ระเบียบการตั้งชื่อต่าง ๆ เพื่ออ้างอิงสิ่งต่าง ๆ ได้มากเท่าที่คุณอาจใช้ UPPER_CASE สำหรับค่าคงที่ (ใช้กับภาษาบางภาษาเท่านั้น) คุณสามารถใช้ this_style สำหรับชื่อตัวแปรท้องถิ่นในขณะที่คุณใช้ camelCase สำหรับอินสแตนซ์ / สมาชิก ตัวแปร สิ่งนี้อาจไม่จำเป็นเมื่อคุณมีสิ่งต่าง ๆ เช่นselfหรือthisอย่างไรก็ตาม

ปรับปรุง

มาดูกันว่าคุณมีแพลตฟอร์มใดบ้าง Foo witch ไม่ได้แนะนำการตั้งชื่อใด ๆ และเป็นทางเลือกของหัวหน้าทีมที่จะเลือก คุณเป็นหัวหน้าทีมนั้นทำไมคุณถึงเลือก camelCase หรือทำไม underscore_case

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

หากต้องการอ้างอิง Alex Martelli ในเรื่องที่คล้ายกันมาก:

แน่นอนว่าฉันเบื่อหน่ายในรูบีของการพิมพ์ "ท้าย" โง่ ๆ ในตอนท้ายของแต่ละบล็อก (แทนที่จะเป็นเพียงการผูกมัด) - แต่จากนั้นฉันจะหลีกเลี่ยงการพิมพ์โง่เง่า ':' ซึ่ง Python ต้องการที่ เริ่มต้นของแต่ละบล็อกเพื่อให้เป็นเกือบล้าง :-) ความแตกต่างทางไวยากรณ์อื่น ๆ เช่น '@foo' กับ 'self.foo' หรือความสำคัญที่สูงขึ้นของเคสใน Ruby vs Python เป็นเรื่องเกี่ยวกับฉันที่ไม่เกี่ยวข้อง

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

แหล่ง

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

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

สำหรับภาษาการเขียนโปรแกรมที่ฉันใช้เช่น Java, Python, C ++ ฉันใช้รูปแบบที่ชัดเจน:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

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

ฉันยังพบว่ามีประโยชน์ที่จะเข้มงวดและตั้งชื่อใน PascalCase เช่นโปรแกรมแยกวิเคราะห์ HTML เป็น HtmlParser แทนที่จะเป็น HTMLParser หรือ HTMLparser เพราะฉันเชื่อว่าการจดจำกฎที่เข้มงวดและทำให้ขอบเขตของคำศัพท์ชัดเจนขึ้น (น่าเสียดายที่ต้องมีการสะกดคำผิดเช่น HTML หรือ SQL) ในทำนองเดียวกันกับ camelCase, htmlParserMethod แทน HTMLParserMethod หรือ HTMLparserMethod

อัปเดต :

ฉันพบว่าใช้ในการขยายกฎเหล่านี้เพื่อรวมตัวแปรส่วนตัว - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

ใน Java สิ่งนี้หมายความว่าเขตข้อมูลส่วนตัวนั้นเป็นไปตามคำจำกัดความในเนมสเปซที่แตกต่างจากตัวแปรท้องถิ่นซึ่งหมายความว่าคุณสามารถข้ามthis.เขตข้อมูลส่วนตัวได้ รูปแบบอื่น ๆ ที่ฉันเคยเห็นคำนำหน้าด้วย " m" แต่รูปแบบเหล่านั้นยังใช้ camelCase สำหรับชื่อตัวแปร นอกจากนี้ยังช่วยให้ฉันเพื่อให้ความแตกต่างระหว่างเขตข้อมูลที่ควรจะเข้าถึงได้ภายในโดยชั้น (และทำให้มันเป็นซุปเปอร์ชัดเจนเมื่อมันเกิดขึ้นนอกของชั้นobject._field_xยืนออก)

ถ้ามันลงมากับฉันฉันจะไม่บังคับหรือบอกใบ้เกี่ยวกับการใช้สไตล์ใด ๆ เพราะในฐานะโปรแกรมเมอร์เราจะสามารถอ่านสัญลักษณ์ IfItIsInCamelCase หรือ in_underscore_space หรือแม้แต่ใน __SomeOtherStyle และเข้าใจความหมายของมัน การใช้เวลาในการแยกวิเคราะห์สัญลักษณ์เพียงเล็กน้อยนั้นไม่มีค่าใช้จ่ายใด ๆ

ตอนนี้อาร์กิวเมนต์หลักสำหรับการประชุมที่ฉันเดาก็คือคุณรู้ล่วงหน้าว่ารูปแบบของฟังก์ชัน / ชื่อตัวแปรคืออะไรและไม่จำเป็นต้องค้นหามัน - มันคือ LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? ตอนนี้ฉันจะตอบโต้การโต้แย้งโดยพูดว่า "รับ IDE ที่รองรับการเติมสไตล์ Intellisense อัตโนมัติ!" (ไม่สามารถทำได้เสมอไป)

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

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

สไตล์ที่แตกต่างกันสามแบบ แต่คุณรู้แน่ชัดว่าสิ่งใดที่แต่ละคนทำ

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

ฉันมักจะชอบ camelCase ด้วยเหตุผลโง่ ๆ ที่ฉันทำส่วนใหญ่ของการพัฒนาใน Eclipse (สำหรับ Java, PHP และ JavaScript) และเมื่อฉันCtrl+ ←หรือCtrl+ →ผ่านคำพูดมันหยุดที่ขอบเขต camelCase

เช่น: myIntVariableจะได้รับการปฏิบัติโดย Eclipse เป็น 3 คำเมื่อCtrl+ ← →'ผ่านเข้าไป

ฉันรู้ว่ามันเป็นเรื่องแปลก ๆ แต่ฉันคิดว่าตัวเองชอบที่จะแก้ไขคำกลางในชื่อ camelCase