Lỗi chính tả để tránh những từ dành riêng

Tôi thường thấy mã bao gồm lỗi chính tả của các từ phổ biến mà tốt hơn hoặc xấu hơn đã trở thành các từ dành riêng:

• klasshoặc clazzcho lớp học :Class clazz = ThisClass.class
• kountđể tính trong SQL:count(*) AS kount

Cá nhân tôi thấy điều này làm giảm khả năng đọc. Trong thực tế của riêng tôi, tôi đã không tìm thấy quá nhiều trường hợp mà một cái tên tốt hơn không thể được sử dụng - itemClasshoặc recordTotal.

Một ví dụ từ JavaDocs cho Class cho thấy điều này trong các tham số:

 public <U> Class<? extends U> asSubclass(Class<U> clazz)

Điều này cho thấy một trường hợp sử dụng hợp lý?

IMHO, đây là một ý tưởng rất xấu. Các từ dành riêng được dành riêng cho một lý do và làm điều này không làm giảm khả năng đọc.

Tôi cũng hoàn toàn đồng ý với điểm thứ hai của bạn. Đặt tên cho một biến class, ngay cả khi bạn có thể làm điều đó, cũng sẽ tệ như đặt tên cho nó tmphoặc a. Loại nào? Một lớp học của những gì? Tên nên được mô tả.

Hướng dẫn phong cách của Python gọi vấn đề này một cách cụ thể và gợi ý:

Nếu tên thuộc tính công khai của bạn va chạm với một từ khóa dành riêng, hãy thêm một dấu gạch dưới duy nhất vào tên thuộc tính của bạn. Điều này là tốt hơn để viết tắt hoặc viết sai chính tả.

Đây có vẻ như là một quy tắc chung khá tốt, giả sử nó không mâu thuẫn với ngữ nghĩa của một ngôn ngữ cụ thể.

Mùi mã.

string stringVariable = "";

Các mã trên không cho tôi biết gì về các biến dự định sử dụng.

class Klass

Cùng một vấn đề

string UserNameString = "bmackey"

Đoạn mã trên không được yêu cầu chuỗi từ khóa được gắn vào tên biến. Nếu bạn thấy mình cần xác định các loại theo tên biến, mã của bạn quá dài. Ngưng tụ-tái cấu trúc.

Cá nhân, tôi nghĩ rằng đó là một lựa chọn hoàn toàn hợp lệ cho kiểu mã của bạn.

Chúng là những từ dành riêng để trình biên dịch không phải quyết định xem bạn có nghĩa là cơ chế ngôn ngữ hay biến của bạn. Với ý nghĩ đó, nó ngụ ý rằng họ mong đợi mọi người có nhu cầu về một biến như một từ dành riêng.

Đi qua nguồn đi kèm với JDK 1.6 R21, tôi thấy 917 lần xuất hiện của "clazz". Rõ ràng, họ nghĩ rằng đó là phong cách chấp nhận được.

Làm thế nào để nhóm của bạn cảm thấy về nó? Nếu bạn nghĩ nó tệ, nhưng 9 người khác trong đội của bạn nghĩ nó tốt, thì bạn phải cắn viên đạn và chấp nhận nó. Miễn là có thông tin liên lạc về những gì ổn và những gì không, và bạn đang đưa ra những vấn đề bạn thấy khi bạn nhìn thấy, thì mọi chuyện sẽ ổn thôi.

Làm thế nào nhóm của bạn cảm thấy về phong cách mã quan trọng hơn ý kiến ​​của tôi, hoặc bất cứ ai khác trong bài viết này . Điều đó đúng với điều này và bất kỳ quyết định kiểu mã nào khác mà bạn có thể có.

Lỗi chính tả để tránh những từ dành riêng là một ý tưởng tồi.

• Lỗi chính tả rất khó phân biệt với chính tả, do đó chúng làm cho mã khó đọc hơn.

• Lỗi chính tả rất khó nhớ, do đó một số lỗi chính tả không nhất quán có khả năng cạnh tranh trong mã, khiến mã khó viết hơn và khó đọc hơn.

• Các từ dành riêng đề cập đến ngôn ngữ đang được sử dụng để giải quyết vấn đề, chứ không phải cho chính vấn đề. Một tên biến nên trỏ đến một khái niệm liên quan đến vấn đề.

Do đó, tốt hơn là chọn một tên thay thế, mô tả hoặc nếu không có sự thay thế thỏa mãn tồn tại, để đủ điều kiện từ dành riêng như trong:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> benchmarkedClass = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(benchmarkedClass, benchmark.generatedMethod());
}

Class clazzcó mùi như "Tôi không buồn cố gắng đưa ra một cái tên hay". Một biến luôn đại diện cho một cái gì đó, và một cái tên hay mô tả điều đó. Tôi từ chối tưởng tượng rằng clazzví dụ trong mọi trường hợp là tên tốt nhất có thể. Có phải nó là một tham chiếu đến một lớp -> class_Vference, là một bản sao của một đối tượng lớp -> class_copy, v.v. Có thể cũng bỏ "lớp" và chỉ sử dụng từ mô tả, ví dụ:

java.lang.SecurityManager.checkMemberAccess(Class<?> clazz, int which)
Parameters
    clazz -- the class that reflection is to be performed on.

Ở đây clazz là lớp mục tiêu mà kiểm tra sẽ được thực hiện trên, vì vậy

checkMemberAccess(Class<?> target, int which)

sẽ mô tả tốt hơn những gì tham số được sử dụng cho hơn clazz từng có.

Nếu họ sử dụng tên dành riêng cho một biến, thì đó là biến được đặt tên kém. Ngay cả khi đó là một tên hợp pháp, chẳng hạn như Class cho phần mềm lớp học.

Các biến được đặt tên kém là dấu hiệu của suy nghĩ kém hoặc mã thông thường - hãy cẩn thận với các vấn đề khác trong Phần mềm bạn đang duy trì.

Tôi nghĩ rằng lỗi chính tả hoặc viết tắt có chủ ý là một ý tưởng tốt nếu được sử dụng cẩn thận và nhất quán .

Xem xét trong Java:

class X { public X() { } }
X x = new X();
x.getClass;  // Wha?  How does "get" help anything?
x.class;     // Best, but requires more lexer/parser work
x.klass;     // At least as good as getClass
x.clazz;     // Same

Nơi để sử dụng lỗi chính tả là nơi mà từ dành riêng rõ ràng là từ tốt nhất cho công việc. Có hai nơi không sử dụng lỗi chính tả mà bạn có thể bị cám dỗ.

1. Bạn không cảm thấy nghĩ về một cái tên hay
2. Bạn chỉ muốn một biến giả và nó không cần một tên mô tả

Trong trường hợp đầu tiên, khá rõ ràng rằng sự lười biếng hiếm khi là một chính sách tốt để tạo mã chất lượng. Trong trường hợp thứ hai, chọn một biến thực sự ngắn. Đó là những gì các nhà toán học làm mọi lúc, và các lập trình viên làm cho các chỉ số. Không có lý do gì để giới hạn bản thân bạn làm điều này cho các chỉ số nếu nó thực sự chỉ là một biến giả:

boolean isMyName(String testName) { return myName.equals(testName); }
boolean isMyName(String s) { return myName.equals(s); }

Date nextMeeting(Klass klass) { return /* something */ }
Date nextMeeting(Klass k) { return /* something */ }

Bạn không mất bất cứ thứ gì có tên biến ngắn khi phương thức hoặc cấu trúc của mã cho bạn biết cái gì phải ở đó.

Tôi đã thấy những cách sử dụng hợp pháp Class klasskhi thực hiện phản xạ nơi bạn thực sự làm việc với một thể hiện của Classlớp.

Tôi thường thấy mã bao gồm lỗi chính tả của các từ phổ biến mà tốt hơn hoặc xấu hơn đã trở thành các từ dành riêng:

klass hoặc clazz cho lớp: Class clazz = ThisClass. class

kount cho số đếm trong SQL: đếm (*) NHƯ kount

Cá nhân tôi thấy điều này làm giảm khả năng đọc. Trong thực tế của riêng tôi, tôi đã không tìm thấy quá nhiều trường hợp không thể sử dụng tên tốt hơn - itemClass hoặc recordTotal.

Tuy nhiên, nó phổ biến đến mức tôi không thể không tự hỏi liệu tôi có phải là người duy nhất không? Bất cứ ai có lời khuyên hoặc thậm chí tốt hơn, trích dẫn khuyến nghị từ các lập trình viên được kính trọng về thực hành này?

Đối với các biến cục bộ và các đối số chính thức, nó không thành vấn đề.

Bất kỳ tên nào cũng được miễn là nó không cố ý gây hiểu lầm hoặc gây mất tập trung. Trong ví dụ của bạn:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

không quan trọng là biến cục bộ duy nhất là "clazz" hay "klass" hay "cls" hay chỉ đơn giản là "c". Tôi có lẽ sẽ chỉ nội tuyến biểu thức:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

Độ dài của tên biến phải liên quan đến phạm vi của biến. Đối với các biến cục bộ trong các phương thức ngắn (và tất cả chúng nên ngắn), các tên rất ngắn là ổn.

Tôi nghĩ rằng lỗi chính tả luôn là một ý tưởng tồi. Nó chỉ không tốt cho độc giả của bạn. Tôi, cho một, sẽ tự hỏi liệu tôi đã bỏ lỡ một cái gì đó khi tôi nhìn thấy từ này klass. (Ý của họ là class, hay họ có nghĩa là cướp biển?) Ít nhất với tôi, tất cả các lỗi chính tả mà tôi nhận ra đều gây khó chịu.

Đối với rất ít trường hợp, trong đó từ dành riêng thực sự là điều quan trọng duy nhất được biết về biến, tôi sẽ sử dụng các từ thay thế sau:

• Nếu đó là một đối số chức năng, sử dụng aClassthay vì class.

• Nếu đó là biến cục bộ hoặc biến thành viên, hãy sử dụng myClassthay vì class.

• Nếu đó là một phụ kiện, sử dụng getClass()thay vì class().

Tất nhiên, tiền tố được thêm vào là khá vô nghĩa, và do đó chỉ nên được sử dụng như là phương sách cuối cùng. Nhưng ít nhất nó không can thiệp vào trình phân tích cú pháp tinh thần của người đọc của bạn và đó là một cách không an toàn để tránh những từ dành riêng.

Một lợi ích cho chính tả sáng tạo, là khả năng tìm kiếm tốt hơn. Tôi nghĩ rằng việc tìm kiếm mã đầy đủ cho những thứ độc đáo sẽ dễ dàng hơn nhiều so với những từ thông dụng, nơi bạn sẽ thường xuyên tìm thấy tất cả những điều sai và 1000 trong số đó. Ví dụ, tôi đã từng sở hữu kzpg.com. Google mà bây giờ và bạn sẽ chỉ thấy một vài lần truy cập. Nó là duy nhất và do đó rất dễ tìm thấy.

Nhưng theo một biện pháp tôi nghĩ câu hỏi này là một trong những ý kiến ​​nhiều hơn là chất. Cá nhân tôi đã lớn lên trên Forth, nơi tất cả là về lời nói, và rất nhiều trong số họ. Một người học được cách rất sáng tạo để cứu ngón tay của một người. Cuối cùng, tôi có khoảng 640.000 ký tự, ít nhiều trong cơ sở nguồn của tôi. Vì vậy, giữ cho các từ ngắn là quan trọng để hoàn thành công việc.