Những gì đặt tên chống mẫu tồn tại? [đóng cửa]

Có một số tên, trong đó nếu bạn thấy mình đang tìm kiếm những cái tên đó, bạn biết bạn đã nhầm lẫn một cái gì đó.

Ví dụ:

XxxManager
Điều này là xấu vì một lớp nên mô tả những gì lớp làm. Nếu từ cụ thể nhất bạn có thể nghĩ ra cho những gì lớp học làm là "quản lý" thì lớp đó quá lớn.

Những gì chống đặt tên khác tồn tại?

Để làm rõ, tôi không hỏi "tên gì là xấu" - câu hỏi đó hoàn toàn chủ quan và không có cách nào để trả lời nó. Tôi đang hỏi, "những cái tên nào chỉ ra các vấn đề thiết kế tổng thể với hệ thống." Đó là, nếu bạn thấy mình muốn gọi một thành phần Xyz, điều đó có thể cho thấy thành phần đó bị che giấu. Cũng lưu ý ở đây rằng có các ngoại lệ cho mọi quy tắc - Tôi chỉ tìm kiếm các cờ cảnh báo khi tôi thực sự cần dừng và suy nghĩ lại về một thiết kế.

Các kiểu chống đặt tên sau đây có liên quan đến .NET và đặc biệt là C #:

• Mâu thuẫn . Nếu bạn quyết định bắt đầu mọi tên trường bằng dấu gạch dưới hàng đầu, hãy bám vào nó .
• Chữ viết tắt Ambiguos với nguyên âm bị thiếu . Tôi đã nghiêm túc nhìn thấy tên trường như cxtCtrlMngr. Bạn khó có thể đoán được những gì được cho là đại diện cho.
• Tên biến quá dài và dài dòng . ILoginAttemptRepositorylà tốt và mô tả - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMappinglà mô tả, nhưng chắc chắn không tốt.

Một cái mà tôi gặp phải thường là, đơn giản, không sử dụng bất kỳ mẫu đặt tên nào cả. Điển hình cho thấy sự thiếu hiểu biết của nhà phát triển (rằng các mẫu đặt tên là một điều tốt ) và cả kiểu chống này có xu hướng vi phạm nghiêm trọng SRP bằng cách nhồi nhét tất cả các loại phương thức liên quan đến một lớp vào chính lớp đó, ví dụ như một Khách hàng lớp có các thuộc tính, phương thức CRUD, mọi thứ liên quan từ xa đến Khách hàng mà một phần của ứng dụng cần.

Tôi cũng sẽ thêm rằng việc sử dụng "Engine" làm hậu tố cũng giống như sử dụng "Manager". Điều này rất mơ hồ và một lớp được gọi là XxxEnginecó xu hướng tương đương với Mô-đun kiểu VB có chứa một loạt các phương thức để nó ở một điểm "dễ sử dụng", mà không có bất kỳ kiến ​​thức hay ý tưởng nào về lập trình hướng đối tượng.

Chà, câu trả lời đơn giản trước tiên: hãy nhập tên tiếng Anh ( http://mindprod.com/jgloss/unmainnaming.html , cũng có một số ý tưởng tuyệt vời khác. Một cái nhìn cân bằng hơn về khi mà Drake không xấu xa, http://www.joelonsoftware.com /articles/Wrong.html )

Tiền tố một 'Tôi' với tên của một giao diện, hoặc 'Trừu tượng' với tên của một lớp trừu tượng. Điều này có thể dễ dàng sử dụng trong các ngôn ngữ không có khái niệm về các lớp trừu tượng hoặc không phân biệt giữa các giao diện và các lớp trừu tượng - nhưng trong Java, chẳng hạn, đó luôn là một ý tưởng tồi.

Ngoài ra, tôi không đồng ý với bạn về điều Manager. Đôi khi tôi sử dụng mô hình đó và điều đó chỉ có nghĩa là nếu tôi cố gắng đặt tên cho cái gì đó khác, thì tên đó sẽ không được mô tả nhiều hơn XxxxxManager. Có một số nhiệm vụ (không nhất thiết phải phức tạp) mà không thể tóm tắt gọn gàng trong một hoặc hai từ.

Cảm giác:

Tôi có một khuyết tật nghiêng và không thể đánh vần. Với trình kiểm tra chính tả, tôi bất lực, tôi cố gắng sao chép tất cả các tên tôi tạo vào một trình xử lý văn bản để xác minh nhưng tôi luôn bỏ lỡ một số. Trong dự án cuối cùng của tôi, tôi đã viết một phần lớn của api và tôi đoán rằng tôi đã không kiểm tra chính tả ngay lần đầu tiên tôi sử dụng từ responce và tôi cho rằng nó đúng vì không ai nói với tôi. Chúng tôi đã có ít nhất 50 chức năng với mặt nạ trong đó. Một người mới vào đội và hỏi tại sao chúng tôi sử dụng responce tôi cảm thấy thật ngớ ngẩn.

Vâng, tôi sợ ý kiến ​​của tôi là một chút tranh cãi. Nhưng hãy thử ...

Theo như tôi quan tâm, tôi phải đồng ý với Mike Baranczak, những cái tên như XxxControll, XxxHandler là thứ chúng tôi thực sự thường sử dụng. Đối với chúng tôi, Bộ điều khiển giống như một điểm khởi đầu cho một cái gì đó "được gói gọn", ví dụ như quản lý các giao dịch, xử lý các lỗi không mong muốn, gọi XxxHandler để thực hiện công việc thực tế. Tôi muốn nói XxxManager là từ đồng nghĩa với bộ điều khiển. Tôi nghĩ điều quan trọng là không sử dụng Trình quản lý trong một trường hợp và Trình điều khiển trong trường hợp khác. Sự nhất quán là rất quan trọng nếu bạn làm việc trong một nhóm.

Sẽ rất khó hoặc thậm chí có thể không tìm được tên tốt hơn cho những thứ như thế này. Xxx nên được lựa chọn tốt để làm cho tình hình rõ ràng hơn.

Điều cá nhân tôi không thích là, khi một phương thức gọi là get ... hoặc set ... không chỉ là một công cụ truy cập đơn giản. Tôi thích Det ... để xác định.

Một điều khác, điều đó xuất hiện trong tâm trí của tôi: Theo chú Bob. Một "Và" trong một tên phương thức là một dấu hiệu của việc làm nhiều. Nhưng cuộc sống không phải lúc nào cũng chỉ là đen trắng - có những tình huống mà tôi nghĩ nó ổn - ví dụ. do vấn đề về hiệu suất (khi bạn đã có dữ liệu do kiểm tra tại sao không xử lý chúng) ...

Cá nhân tôi cũng là một fan hâm mộ lớn của các ký hiệu của hệ thống - hầu hết thời gian bạn đang xử lý mã nguồn trong một IDE đều ổn. Nhưng thường thì bạn đang sử dụng chỉ một trình soạn thảo hoặc bạn đang duyệt repo trong trình duyệt. Một nhược điểm có thể là hỗ trợ công cụ do tiền tố loại ...

Tôi nghĩ rằng điều quan trọng nhất là sự đồng ý nuôi ong - một quy ước dưới mức tối ưu - đối với tôi - tốt hơn là không có quy ước ...

Có lẽ cách chống tên xấu nhất là cái này:

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

Chúng tôi có một danh sách ba yếu tố của các cặp [foo, bar]. Nếu chúng ta cần một thứ tư, chúng ta sẽ phải thêm các cột mới vào bảng.

Dẫn đến mã như thế này:

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

Một bảng riêng biệt phải được tạo với các cột foo và thanh và được liên kết với bảng thứ:

create table fubar(foo string, bar string, stuff_id long)

Điều tồi tệ thứ hai là đây:

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

Ở đây chúng tôi có sáu trường thay vì hai trường hợp của một lớp Địa chỉ.

Mẫu chống này được đánh dấu bằng một loạt các tên hai phần liệt kê mọi kết hợp của hai bộ, ví dụ: [foo, bar] x [1,2,3] hoặc [home, perm] x [street, city, state]

Bất kỳ lớp hoặc giao diện đặt tên nào là tautology đều là một thứ xấu, không chỉ trong Java mà liên kết nói về, mà trong bất kỳ ngôn ngữ nào.

Tautology (hùng biện), sử dụng các từ khác nhau để nói cùng một điều ngay cả khi sự lặp lại không cung cấp rõ ràng.

Tôi thường xuyên bắt gặp các thư viện phần mềm có tên chung như Libraryhoặc Common. Chúng chỉ ra thiết kế dưới mức tối ưu: các nhà phát triển nỗ lực để tránh sao chép mã nhưng không có bất kỳ nỗ lực nào để tạo ra một thiết kế bị phân tách trên cơ sở chức năng.

Từ Microsoft về cách đặt tên, tôi có thể cung cấp danh sách này cho các tên xấu:

1. Chúng không phải là ngữ nghĩa, có nghĩa là chúng có tên thay vì nhấn mạnh vào những gì nó làm, nhấn mạnh vào công nghệ mà nó sử dụng hoặc mẫu mà nó dựa trên .
2. Họ không tuân theo một sự thống nhất cú pháp. Ví dụ, một phần của tên là vỏ lạc đà, trong khi phần khác là vỏ pascal.
3. Chúng là những từ viết tắt, rất khó hiểu, như ScrollableX thay vì CanScrollH theo chiều ngang
4. Họ được chọn sao cho họ lộn xộn với các từ khóa của môi trường đó.