เหตุผลที่ใช้ตัวพิมพ์เล็กสำหรับคำแรกในตัวแปรโลคัล (เช่น employeeCount, firstName) คืออะไร

ฉันใช้การวิพากษ์วิจารณ์อย่างมากจากโปรแกรมเมอร์คนอื่น ๆ เนื่องจากฉันใช้ตัวเรือนที่เหมาะสมกับตัวแปรทั้งหมดของฉัน ยกตัวอย่างเช่นโปรแกรมเมอร์ของคุณโดยทั่วไปจะใช้employeeCountชื่อตัวแปร EmployeeCountแต่ฉันจะใช้ ฉันใช้ตัวเครื่องที่เหมาะสมสำหรับทุกอย่างไม่ว่าจะเป็นวิธีที่เป็นโมฆะวิธีคืนค่าตัวแปรคุณสมบัติหรือค่าคงที่ ฉันยังทำตามอนุสัญญานี้ใน Javascript สิ่งสุดท้ายที่ทำให้เกิดความสับสนวุ่นวายของคนจริงๆ

เหตุผลทั่วไปที่กำหนดว่าทำไมฉันไม่ควรทำตามกรอบ "ที่ไม่ได้มาตรฐาน" นี้เป็นเพราะกรณีที่เหมาะสมควรถูกสงวนไว้สำหรับคุณสมบัติและวิธีการโมฆะ int employeeCount = getEmployeeCount()ตัวแปรท้องถิ่นและวิธีการที่ส่งกลับค่าควรมีคำแรกเป็นตัวพิมพ์เล็กเช่น

อย่างไรก็ตามฉันไม่เข้าใจว่าทำไม

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

นับตั้งแต่วันแรกของการเขียนโปรแกรมแมโคร Excel 97 กับ Office IDE ฉันไม่เคยต้องการรูปแบบการเขียนเพื่อบอกฉันว่ามีบางสิ่งที่เป็นตัวแปรหรือคุณสมบัติในตัวเครื่องหรือไม่ นี่เป็นเพราะฉันมักจะใช้รูปแบบการตั้งชื่อที่ใช้งานง่ายมาก ตัวอย่างเช่นGetNuggetCount()แนะนำวิธีการที่จะไปที่ไหนสักแห่งและนับจำนวนนักเก็ตทั้งหมด SetNuggetCount(x)แนะนำว่าคุณกำลังกำหนดค่าใหม่ให้กับจำนวนนักเก็ต NuggetCountโดยตัวมันเองแนะนำคุณสมบัติหรือตัวแปรท้องถิ่นที่เป็นเพียงการเก็บค่า สำหรับคนสุดท้ายนั้นอาจถูกล่อลวงให้พูดว่า "อ้าฮ่า! นั่นคือคำถามทรัพย์สินหรือตัวแปร? เพื่อที่ฉันจะตอบด้วย "มันเป็นเรื่องสำคัญจริง ๆ ?"

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

แก้ไข: สำหรับ MainMa

แทนที่รหัสนี้ด้วยตัวอย่างรหัสแรกในคำตอบของคุณและดูว่าอาร์กิวเมนต์ของคุณดีขึ้นเพียงใด:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

หลักการตั้งชื่อนั้นมักถูกใช้เมื่อผู้คนต้องการให้ตัวแปรมีชื่อเดียวกับชนิดของมัน ตัวอย่างเช่น:

Employee employee;

บางภาษาบังคับใช้ตัวพิมพ์ใหญ่ด้วยซ้ำ ป้องกันการนี้ต้องใช้ชื่อตัวแปรที่น่ารำคาญเหมือนMyEmployee, CurrentEmployee, EmployeeVarฯลฯ คุณมักจะสามารถบอกได้ว่าสิ่งที่เป็นชนิดหรือตัวแปรเพียงจากทุน ที่ช่วยป้องกันความสับสนในสถานการณ์เช่น:

employee.function(); // instance method
Employee.function(); // static method

นอกจากนี้ในภาษาอังกฤษคำนามไม่ได้เป็นตัวพิมพ์ใหญ่ดังนั้นคุณจึงไม่สามารถเรียกร้องการใช้อักษรตัวพิมพ์ใหญ่ของคุณได้ว่า "เหมาะสม"

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

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

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

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

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

http://thecodelesscode.com/case/94

1. ทำไมต้องมีมาตรฐาน

ท้ายที่สุดมันจะดีกว่าไหมถ้าให้ทุกคนเขียนรหัสตามความชอบส่วนตัวและหยุดพูดเรื่องมาตรฐานที่ดีกว่ากัน?

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

อะไรที่สามารถอ่านได้ระหว่างโค้ดสองชิ้นนี้

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

หรือ:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

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

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

โดยการมีมาตรฐานที่เข้มงวดสม่ำเสมอทำให้อ่านรหัสได้ง่ายขึ้น

2. ทำไมมาตรฐานของพวกเขาถึงดีกว่าที่ฉันคิดค้นในตอนนี้?

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

ตัวอย่าง: ใน บริษัท ของฉันฉันมีระเบียบแบบแผนเฉพาะสำหรับการตั้งชื่อคีย์และดัชนีต่างประเทศและดัชนีในฐานข้อมูล ชื่อเหล่านั้นมีลักษณะดังนี้:

• [FK for Application: CreatedByApplicationId],
• [IX for SessionIPAddress: SessionId] หรือ
• [PK for RoleOfPassword: RoleId, PasswordId].

ส่วนตัวแล้วฉันพบว่าการประชุมนี้ยอดเยี่ยมและชัดเจนมาก สำหรับฉัน. แต่มันดูดโดยสิ้นเชิง มันแย่มากเพราะเป็นของฉันและเพราะไม่มีผู้ดูแลระบบฐานข้อมูลคนใดคนหนึ่งไม่เคยใช้เลย ซึ่งหมายความว่า:

• เมื่อฉันจะจ้าง DBA เขาจะถูกบังคับให้เรียนรู้ระเบียบใหม่แทนที่จะเริ่มทำงานทันที

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

• ถ้าฉันนำรหัสจากภายนอกเพื่อใช้ด้วยตัวเองฉันจะถูกบังคับให้แก้ไขชื่อเพื่อให้เหมือนกัน

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

3. แล้วการใช้อักษรตัวพิมพ์ใหญ่เป็นอย่างไร

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

หากคุณพิจารณา C # ลอจิกนี้สอดคล้องกันมากพอ

หากคุณพิจารณา Java วิธีการเริ่มต้นด้วยตัวอักษรขนาดเล็กซึ่งไม่เป็นไปตามตรรกะ

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

ใน JavaScript ฟังก์ชั่นเริ่มต้นด้วยตัวอักษรขนาดเล็กเว้นแต่พวกเขาต้องการnewก่อน มันจะไม่ดีกว่าวิธีอื่น ๆ หรือ อาจจะ. ความจริงก็คือว่าเป็นเวลาหลายปีที่นักพัฒนา JavaScript ใช้มาตรฐานนี้และไม่ใช่สิ่งที่ตรงกันข้าม เขียนซ้ำทุกเล่มและบังคับให้นักพัฒนาทุกคนเปลี่ยนสไตล์ตอนนี้จะซับซ้อนเล็กน้อย

ในทางเทคนิคแล้วมันไม่สำคัญ (หรืออย่างน้อยในภาษาส่วนใหญ่ก็ไม่ได้)

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

ไม่ใช่เพราะมันดีที่สุด แต่เป็นเพราะสิ่งที่ทุกคนใช้ หากคุณยึดติดกับมาตรฐานรหัสของคุณจะสอดคล้องกับรหัสอื่น ๆ ส่วนใหญ่ที่คุณจะใช้ในท้ายที่สุด - ห้องสมุดรหัสเพื่อนร่วมทีมภาษาในตัว การตั้งชื่อที่สอดคล้องกันเป็นอาวุธที่มีประสิทธิภาพอย่างหนึ่งเนื่องจากมันหมายความว่าเมื่อคุณเดาชื่อของบางอย่างคุณมักจะเดาถูก มันfile.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? แบบแผนการตั้งชื่อจะบอกคุณ

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

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

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

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

และความยุติธรรมของเรื่องนี้อาจเหลือจากสไตล์ที่แย่กว่าของฉันเมื่อหลายปีก่อนเมื่อวิธีการไม่น่าจะเหมาะกับหน้าจอเดียว

นี่ดูเหมือนคำถามเกี่ยวกับการประชุมมากกว่าการประชุมเฉพาะของคุณ

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

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

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

"เพราะกรณีที่เหมาะสมควรถูกสงวนไว้สำหรับคุณสมบัติและวิธีการโมฆะตัวแปรท้องถิ่นและวิธีการที่ส่งกลับค่าควรมีคำแรกเป็นตัวพิมพ์เล็ก" และเพราะมันเป็นแบบแผนมาตรฐาน

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

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

เส้นจะเบลอเล็กน้อยเมื่อจัดการกับสิ่งต่าง ๆ เช่นการป้องกันหรือออกหรือบางสิ่งบางอย่าง

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

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

สำหรับฉันมันลงมาที่ความคาดหวัง

เมื่อฉันอ่านโค้ดส่วนใหญ่ฉันคาดหวังว่าทุกอย่างที่ขึ้นต้นด้วย a lowerCaseจะเป็นตัวแปรโลคอลหรือฟังก์ชั่น (ใน C # ที่จะเป็นแค่ตัวแปร) หากฉันเห็นตัวแปรท้องถิ่นProperCaseฉันอาจจะสะดุดและสับสนในขณะที่คิดว่าเป็นชื่อคลาสหรือทรัพย์สินหรืออย่างอื่น นั่นจะทำให้ฉันอ่านรหัสอีกครั้งและจะรบกวนฉัน

นั่นเป็นสิ่งที่เกิดขึ้นในกรณีของคุณ

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

ตัวพิมพ์เล็กควรใช้กับตัวแปรในตัวเครื่องเพื่อให้ง่ายต่อการพิมพ์ (ปุ่ม speed / no shift) ใช้ตัวพิมพ์ใหญ่เพื่อช่วยในการอ่านโดยแยกคำภายในชื่อ รหัสที่มีชื่อตัวแปรโลคัลคำเดียว (ซึ่งควรเป็นเรื่องธรรมดา) นั้นรวดเร็วและง่ายต่อการพิมพ์ การใช้ตัวพิมพ์ใหญ่สำหรับแต่ละคำใหม่ในชื่อนั้นก็เร็วกว่า (และใช้พื้นที่น้อยกว่า) ด้วยการใช้เครื่องหมายขีดล่างที่เพิ่มอักขระอื่น - ซึ่งเป็นที่รู้จักกันในชื่อของอูฐ

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

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