Lý do sử dụng chữ thường cho từ đầu tiên trong một biến cục bộ (ví dụ: workerCount, FirstName)

Tôi nhận được rất nhiều lời chỉ trích từ các lập trình viên khác do tôi sử dụng toàn bộ vỏ thích hợp cho tất cả các biến của mình. Ví dụ, lập trình viên điển hình của bạn sẽ sử dụng employeeCountcho một tên biến, nhưng tôi sử dụng EmployeeCount. Tôi sử dụng vỏ thích hợp đầy đủ cho tất cả mọi thứ , có thể là phương thức void, phương thức trả về, biến, thuộc tính hoặc hằng. Tôi thậm chí còn theo quy ước này trong Javascript. Điều cuối cùng thực sự xào xạc những trò đùa của mọi người.

Lý do điển hình được đưa ra là tại sao tôi không nên tuân theo quy ước vỏ "không chuẩn" này là vì trường hợp thích hợp đầy đủ nên được dành riêng cho các thuộc tính và phương thức void. Biến cục bộ và phương thức trả về một giá trị nên có từ đầu tiên bằng chữ thường int employeeCount = getEmployeeCount().

Tuy nhiên, tôi không hiểu tại sao.

Khi tôi đặt câu hỏi này, dường như tôi chỉ nhận được một câu trả lời tùy ý về tiêu chuẩn đó . Dù câu trả lời là gì đi nữa, nó thường luôn sôi sục theo cách đó và tôi không đặt câu hỏi. Tôi chỉ làm theo nó. . Câu trả lời tùy tiện không bao giờ đủ tốt cho tôi.

Ngay từ những ngày đầu lập trình macro Excel 97 với Office IDE, tôi chưa bao giờ cần một quy ước vỏ để cho tôi biết liệu thứ gì đó có phải là biến cục bộ hay thuộc tính hay không. Điều này là do tôi luôn sử dụng quy ước đặt tên rất trực quan. Ví dụ, GetNuggetCount()rõ ràng gợi ý một phương pháp đi đâu đó và nhận được tất cả các cốm. SetNuggetCount(x)gợi ý rằng bạn đang gán một giá trị mới cho số lượng cố định. NuggetCounttất cả tự nó gợi ý một thuộc tính hoặc biến cục bộ chỉ đơn giản là giữ một giá trị. Cuối cùng, người ta có thể muốn nói, "Ah ha! Đó là câu hỏi. Tài sản hay biến số? LÀ GÌ?" Về điều đó, tôi đã trả lời, "Nó có thực sự quan trọng không?"

Vì vậy, đây là tl; dr;: các lý do khách quan, hợp lý, không độc đoán để sử dụng chữ thường cho từ đầu tiên trong phương thức biến hoặc trả về của bạn là gì?

Chỉnh sửa: Dành cho MainMa

Thay thế mã này bằng mẫu mã đầu tiên trong câu trả lời của bạn và xem đối số của bạn nắm giữ tốt như thế nào:

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);
    }
}

Quy ước đặt tên đó thường được sử dụng khi mọi người muốn có thể đặt một biến có cùng tên với loại của nó. Ví dụ:

Employee employee;

Một số ngôn ngữ thậm chí thực thi viết hoa đó. Ngăn chặn này phải sử dụng tên biến gây phiền nhiễu như MyEmployee, CurrentEmployee, EmployeeVar, vv Bạn luôn có thể cho biết nếu một cái gì đó là một loại hoặc một biến, chỉ từ giá trị vốn hóa. Điều đó ngăn ngừa sự nhầm lẫn trong các tình huống như:

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

Ngoài ra, trong tiếng Anh, danh từ nói chung không được viết hoa, vì vậy bạn không thể thực sự khẳng định cách viết hoa của mình là "đúng".

Vậy điều đó có liên quan gì đến tình huống của bạn? Bạn rõ ràng không gặp khó khăn khi đọc mã của riêng bạn, nhưng bằng cách giữ mọi thứ nhất quán nhất có thể, bạn giảm được khối lượng công việc tinh thần của bất kỳ ai khác cần đọc mã của bạn. Trong mã hóa như bằng văn bản, bạn điều chỉnh phong cách của mình để phù hợp với độc giả.

Không có gì cả. Đó là những gì hầu hết mọi người làm, vì vậy nó đã trở thành tiêu chuẩn bởi vì đó là những gì mọi người làm. Rất nhiều tài liệu tuân theo quy ước này để mọi người chọn thói quen.

Quy ước không quan trọng bằng tính nhất quán trong toàn bộ mã. Miễn là mọi thứ được đặt tên một cách nhất quán để tôi có thể biết mọi thứ đang nhìn vào chúng là gì, việc chữ cái đầu tiên có được viết hoa hay không là không quan trọng.

Tôi sẽ thấy nó chói tai khi bắt gặp mã được viết theo cách của bạn và sẽ nói rằng tôi không thích nó. Nhưng đó là vấn đề của phong cách.

Bây giờ nếu bạn đang làm điều này tại nơi làm việc, sẽ tốt hơn nếu viết mã theo phong cách của nhóm để mã vẫn nhất quán ở mọi nơi. Thay vì có mã của bạn khác với mọi người.

http://thecodlesscode.com/case/94

1. Tại sao tiêu chuẩn tồn tại?

Rốt cuộc, sẽ tốt hơn nếu để mọi người viết mã theo sở thích cá nhân, và ngừng nói về tiêu chuẩn nào tốt hơn?

Thực tế là khi bạn đã quen với một kiểu, việc đọc mã sử dụng một kiểu khác sẽ khó hơn. Bộ não của bạn dành nhiều thời gian hơn để cố gắng hiểu quy ước (nếu có), thay vì hiểu những gì mã làm.

Cái gì dễ đọc hơn giữa hai đoạn mã đó?

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 );
    }
}

hoặc là:

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);
    }
}

Cả hai đoạn mã thực hiện tương tự nhau. Sự khác biệt duy nhất là trong trường hợp đầu tiên, mỗi nhà phát triển làm việc trong dự án đã sử dụng phong cách của riêng mình. Điều này làm cho mã không nhất quán, không thể đọc được và nguy hiểm. Thực tế là các thành viên của nhóm không thể đồng ý về kích thước thụt lề, cùng với thực tế là một trong số họ đã từ chối sử dụng dấu ngoặc nhọn sau mỗi lần ifthực hiện mã rất dễ bị lỗi: nhìn vào nó, chúng tôi có thể tin rằng lần thứ hai iflà chỉ thực hiện khi điều đầu tiên iflà đúng, đó không phải là trường hợp.

Trong trường hợp thứ hai, tất cả các nhà phát triển tuân theo cùng một tiêu chuẩn. Một số người trong số họ có thể không hài lòng, vì họ thích thụt hai khoảng trắng hoặc vì họ đã quen với các phương thức bắt đầu bằng một chữ cái nhỏ. Thực tế là mã vẫn dễ đọc hơn theo cách này, và vẫn sẽ là nếu họ đang sử dụng bất kỳ tiêu chuẩn khác nhau.

Bằng cách có một tiêu chuẩn thống nhất, nghiêm ngặt, nó làm cho mã dễ đọc hơn.

2. Tại sao tiêu chuẩn của họ tốt hơn so với tiêu chuẩn mà tôi đã phát minh ra bây giờ?

Nếu một tiêu chuẩn được sử dụng bởi hàng trăm ngàn nhà phát triển trên toàn thế giới, chỉ cần gắn bó với nó. Đừng phát minh ra của riêng bạn: ngay cả khi nó tốt hơn, bạn sẽ dễ dàng di chuyển đến tiêu chuẩn toàn cầu hơn là hàng trăm ngàn nhà phát triển bắt đầu sử dụng của bạn.

Ví dụ: trong công ty của riêng tôi, tôi có một quy ước cụ thể để đặt tên các khóa và chỉ mục chính và ngoại khóa trong cơ sở dữ liệu. Những cái tên đó trông giống như:

• [FK for Application: CreatedByApplicationId],
• [IX for SessionIPAddress: SessionId] hoặc là
• [PK for RoleOfPassword: RoleId, PasswordId].

Cá nhân, tôi thấy hội nghị này xuất sắc và cực kỳ rõ ràng. Cho tôi. Nhưng nó hoàn toàn hút. Nó tệ, bởi vì nó là của tôi và bởi vì không ai trong số hàng ngàn quản trị viên cơ sở dữ liệu không bao giờ sử dụng nó. Điều này có nghĩa rằng:

• Khi tôi sẽ thuê một DBA, anh ta sẽ bị buộc phải học quy ước mới, thay vì bắt đầu công việc của mình ngay bây giờ,

• Tôi không thể chia sẻ các đoạn mã trên internet như sau: những cái tên lạ lùng đó sẽ phá vỡ những người sẽ đọc mã của tôi,

• Nếu tôi lấy mã từ bên ngoài để sử dụng nó cho riêng mình, tôi sẽ buộc phải sửa đổi tên để làm cho nó thống nhất,

• Nếu một ngày tôi quyết định sử dụng một số tiêu chuẩn nổi tiếng, tôi sẽ buộc phải đi và sửa đổi mỗi một vài trăm tên.

3. Vậy, viết hoa thì sao?

Các thuộc tính có phạm vi hoặc mức độ hiển thị lớn hơn các trường hoặc các biến cục bộ. Làm cho các thuộc tính bắt đầu bằng một chữ in hoa, các trường và các biến - với một ký tự nhỏ đi theo hướng này.

Nếu bạn xem xét C #, logic này là đủ phù hợp.

Nếu bạn xem xét Java, các phương thức bắt đầu bằng các chữ cái nhỏ, không tuân theo logic.

Vì vậy, không có bằng chứng chắc chắn rằng quy ước này là tốt hơn sau đó của bạn. Chỉ là cái đó được sử dụng trên toàn cầu, còn bạn thì không. Không có gì là tốt hơn .

Trong JavaScript, các hàm bắt đầu bằng một chữ cái nhỏ, trừ khi chúng yêu cầu newtrước chúng. Cách khác có tốt hơn không? Có lẽ. Thực tế là trong nhiều năm, các nhà phát triển JavaScript đã sử dụng tiêu chuẩn này chứ không phải ngược lại. Viết lại mỗi cuốn sách và buộc mọi nhà phát triển thay đổi phong cách bây giờ sẽ hơi phức tạp.

Về mặt kỹ thuật, điều đó không thành vấn đề (hoặc ít nhất, trong hầu hết các ngôn ngữ, điều đó không xảy ra).

Tuy nhiên, hầu hết các cộng đồng lập trình (cho dù đó là các cộng đồng trên toàn thế giới đã hình thành xung quanh một ngôn ngữ cụ thể, các nhóm phụ của các cộng đồng đó, các nhóm đã hình thành xung quanh một số thư viện hoặc bộ công cụ phổ biến hoặc chỉ các nhóm riêng lẻ) đã phát triển các tiêu chuẩn mã hóa được thiết lập. Các chi tiết chính xác là tương đối không quan trọng (mặc dù trong nhiều trường hợp, một cuộc tranh luận tốt có thể được thực hiện đối với họ), những gì là quan trọng là bạn dính vào họ.

Không phải vì chúng là tốt nhất, mà bởi vì chúng là thứ mà mọi người khác sử dụng; nếu bạn tuân thủ tiêu chuẩn, mã của bạn sẽ phù hợp với hầu hết các mã khác mà cuối cùng bạn sẽ sử dụng - thư viện, mã của đồng đội, ngôn ngữ tích hợp. Đặt tên nhất quán là một vũ khí năng suất mạnh mẽ, bởi vì nó có nghĩa là khi bạn đoán tên của một cái gì đó, bạn thường sẽ đoán đúng. Có file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? Quy ước đặt tên sẽ cho bạn biết.

Mang sở thích cá nhân của bạn vào mọi ngôn ngữ bạn gặp phải đặc biệt nguy hiểm, vì trước hết, mỗi ngôn ngữ đều có văn hóa riêng và các quy ước đặt tên thường không tương thích; và thứ hai, có nhiều sự khác biệt tinh tế giữa các ngôn ngữ liên quan đến việc đặt tên.

Chỉ cần một ví dụ: trong C #, các loại và biến sống trong các không gian tên riêng biệt; trình biên dịch đủ thông minh để biết sự khác biệt. Tuy nhiên, trong C, cả hai loại tên đều có chung một không gian tên, vì vậy bạn không thể có một loại và một biến có cùng tên trong cùng một phạm vi. Do đó, C cần một quy ước đặt tên để phân biệt các loại với các biến, trong khi C # thì không.

Tôi ngạc nhiên không ai khác nói điều này, nhưng tôi nghĩ rằng sự khác biệt về vốn hóa là hữu ích đáng kinh ngạc vì một lý do: thật tuyệt vời và thuận tiện để có thể biết liệu một biến chỉ có phạm vi cục bộ hay không. Nếu biến là cục bộ hơn tôi không lo lắng nhiều về tác dụng phụ của việc thay đổi nó, chẳng hạn như tái cấu trúc tên. Vì vậy, tôi thích một quy ước phân biệt các thành viên lớp với các biến lớp riêng so với các biến cục bộ.

Với Intellisense hiện đại, điều này ngày càng ít đi, nhưng nó vẫn cho tôi một số mốc khi tôi đọc mã để biết nơi tôi nên tìm để tìm định nghĩa.

Và một chút công bằng của điều này có thể còn sót lại từ phong cách tồi tệ hơn của tôi nhiều năm trước, khi các phương pháp không phù hợp với một màn hình.

Điều này có vẻ giống như một câu hỏi về quy ước hơn là quy ước cụ thể của bạn.

Đối với mỗi quy ước bạn phá vỡ, bạn chỉ cần thêm nhiều công việc cho những người khác. Có lẽ trong một thế giới hoàn hảo, toàn bộ công ty hoạt động trên một sản phẩm duy nhất trong suốt cuộc đời của họ ... tuy nhiên, trên thực tế, điều này không đúng. Mọi người nhảy vào giữa các dự án, đôi khi trên khắp các công ty hoặc thậm chí để giải trí. Mã càng ngẫu nhiên thì càng khó và tốn kém hơn khi làm việc. Là chủ sở hữu doanh nghiệp hoặc các bên liên quan, tôi sẽ không muốn thuê các nhà phát triển suy nghĩ ích kỷ hơn là vì lợi ích của dự án.

Điều này dẫn đến sự chuyên nghiệp: đôi khi chúng ta cần đặt phong cách cá nhân sang một bên và đi với những gì hiệu quả hơn để áp dụng đại trà. Điều này khuyến khích sự hợp tác và loại bỏ các rào cản bên ngoài không nên có ở nơi đầu tiên.

Đối với quy ước thực tế của bạn, CapitalCamelCase thường được dành riêng cho tên lớp (hoặc trong Javascript, các hàm tạo). Nếu tôi thấy một biến được viết hoa, một phỏng đoán có giáo dục sẽ ra lệnh tôi sẽ cần phải khởi tạo nó để sử dụng nó. Nếu đó là sai, tôi sẽ tức giận vì mã không tuân theo các tiêu chuẩn cộng đồng. Ngay cả với hầu hết các ngôn ngữ khác, mọi người khác nhìn vào nó lần đầu tiên ngay lập tức bị đánh lừa. Tôi muốn mã là rõ ràng, không gây hiểu lầm.

"bởi vì trường hợp thích hợp đầy đủ nên được dành riêng cho các thuộc tính và các phương thức void. Biến cục bộ và các phương thức trả về một giá trị nên có từ đầu tiên bằng chữ thường" và vì nó là quy ước chuẩn.

Các lập trình viên khác đang lấy mã của bạn ngay bây giờ và nghĩ rằng đây là một tài sản và nó thực sự là một biến cục bộ, khiến công việc của họ trở nên khó khăn hơn.

Như những người khác đã nói không có lý do thực sự, ngoại trừ việc có được một quy ước đặt tên xuống pat. Nếu bạn có thể đưa cả nhóm của mình vào cùng một trang, bạn có thể tiết kiệm thời gian cho mình. Ví dụ, cá nhân tôi đã bắt đầu một thứ tiêu chuẩn mã hóa đi vào điều này và chúng tôi đã sử dụng camelCase cho tất cả các phương sai riêng tư cũng như những thứ được truyền bởiVal, trong khi chúng tôi sử dụng PascalCase cho những thứ công khai cũng như những thứ được thông qua bởi Ref.

Các dòng có một chút mờ khi xử lý những thứ như được bảo vệ hoặc Out hoặc một cái gì đó.

Ngôn ngữ (với khía cạnh chính thức và thông thường) rất quan trọng để tổ chức những suy nghĩ của bạn, nó có sức mạnh đối với cách suy nghĩ của bạn. Vì vậy, nó chỉ là một nỗi đau để chuyển từ phong cách này sang phong cách khác.

Các ký hiệu chữ hoa và chữ thường có sự khác biệt lớn về ngữ nghĩa trong Haskell, ngoài ra chúng khác nhau nhẹ ở Scala và tôi đã sử dụng cả hai. Các ngôn ngữ khác tôi sử dụng không có sự khác biệt giữa hai loại định danh này, nhưng giữ suy nghĩ theo cách nhận dạng nhận thức của Haskell đối với tôi dễ dàng hơn nhiều so với việc phân chia tâm trí tôi cho các ngôn ngữ khác nhau.

Đối với tôi nó đi xuống để mong đợi.

Khi tôi đọc hầu hết các mã, tôi mong đợi bất cứ điều gì bắt đầu bằng một lowerCasebiến cục bộ hoặc một hàm (trong C # sẽ chỉ là một biến). Nếu tôi thấy một biến cục bộ trongProperCase , tôi có thể sẽ vấp ngã và bối rối trong một thời gian, nghĩ rằng đó là tên lớp hoặc thuộc tính hoặc một cái gì đó khác. Điều đó sẽ khiến tôi đọc lại mã, và sẽ làm phiền tôi.

Đó có thể là những gì xảy ra trong trường hợp của bạn.

Thêm vào đó, thật tiện lợi khi có thể biết vai trò của biến chỉ bằng cách nhìn vào chữ cái đầu tiên và nó tránh được xung đột giữa tên đối tượng và tên lớp.

Chữ thường nên được sử dụng cho các biến cục bộ để dễ gõ (tốc độ / không có phím shift). Chữ hoa được sử dụng để giúp dễ đọc bằng cách tách các từ trong tên. Mã với các tên biến cục bộ một từ (nên phổ biến) rất nhanh và dễ gõ. Việc sử dụng chữ hoa cho mỗi từ mới trong tên cũng nhanh hơn (và ít không gian hơn) so với sử dụng dấu gạch dưới có thêm ký tự khác - đây còn được gọi là trường hợp lạc đà.

Tôi đồng ý với OP ở đây. camelCase chỉ nhìn sai. Tôi cũng đồng ý với thực tế rằng đó là tiêu chuẩn và chúng ta phải tuân theo cùng một tiêu chuẩn hoặc quan điểm của việc có một tiêu chuẩn là gì. Cũng có nghĩa là PascalCaps được sử dụng cho các phương thức vv và camelCase cho các biến của riêng bạn, v.v ... như một cách khác biệt khi không sử dụng IDE tạo màu cho phương thức của bạn.

Để giải quyết vấn đề này, tôi luôn đặt tiền tố tên của đối tượng của mình với loại đối tượng. Vì vậy, nếu đó là một biến chuỗi, tôi gọi strMyVariable. Nếu nó là một loại đối tượng tôi gọi nó là objMyObject, v.v ... Bằng cách đó, nó bắt đầu với các chữ hoa nhỏ theo tiêu chuẩn và nó có vẻ đúng.