Có gì sai với chuỗi ma thuật?

Là một nhà phát triển phần mềm có kinh nghiệm, tôi đã học được cách tránh các chuỗi ma thuật.

Vấn đề của tôi là đã rất lâu kể từ khi tôi sử dụng chúng, tôi đã quên hầu hết các lý do tại sao. Kết quả là, tôi gặp khó khăn khi giải thích lý do tại sao chúng là vấn đề với các đồng nghiệp ít kinh nghiệm của tôi.

Những lý do khách quan là có để tránh chúng? Họ gây ra vấn đề gì?

1. Trong ngôn ngữ biên dịch, giá trị của chuỗi ma thuật không được kiểm tra tại thời điểm biên dịch . Nếu chuỗi phải khớp với một mẫu cụ thể, bạn phải chạy chương trình để đảm bảo nó phù hợp với mẫu đó. Nếu bạn đã sử dụng một cái gì đó như enum, giá trị ít nhất là hợp lệ tại thời gian biên dịch, ngay cả khi nó có thể là giá trị sai.

2. Nếu một chuỗi ma thuật đang được viết ở nhiều nơi, bạn phải thay đổi tất cả chúng mà không có bất kỳ sự an toàn nào (chẳng hạn như lỗi thời gian biên dịch). Điều này có thể được chống lại bằng cách chỉ khai báo nó ở một nơi và sử dụng lại biến.

3. Typose có thể trở thành lỗi nghiêm trọng. Nếu bạn có một chức năng:

   func(string foo) {
       if (foo == "bar") {
           // do something
       }
   }
   

   và ai đó vô tình gõ:

   func("barr");
   

   Điều này tệ hơn là chuỗi hiếm hơn hoặc phức tạp hơn, đặc biệt nếu bạn có các lập trình viên không quen thuộc với ngôn ngữ bản địa của dự án.

4. Chuỗi ma thuật hiếm khi tự ghi lại. Nếu bạn thấy một chuỗi, điều đó cho bạn biết không có chuỗi nào khác có thể / nên có. Bạn có thể sẽ phải xem xét việc triển khai để chắc chắn rằng bạn đã chọn đúng chuỗi.

   Loại triển khai đó bị rò rỉ , cần tài liệu bên ngoài hoặc quyền truy cập vào mã để hiểu những gì nên được viết, đặc biệt là vì nó phải hoàn hảo về nhân vật (như ở điểm 3).

5. Thiếu các hàm "tìm chuỗi" trong IDE, có một số lượng nhỏ các công cụ hỗ trợ mẫu.

6. Bạn có thể tình cờ sử dụng cùng một chuỗi ma thuật ở hai nơi, khi thực sự chúng là những thứ khác nhau, vì vậy nếu bạn đã thực hiện Tìm & Thay thế và thay đổi cả hai, một trong số chúng có thể bị hỏng trong khi cái kia hoạt động.

Đỉnh cao của những gì các câu trả lời khác đã nắm được, không phải là "giá trị ma thuật" là xấu, mà là chúng phải là:

1. định nghĩa rõ ràng là hằng số;
2. chỉ được xác định một lần trong toàn bộ miền sử dụng của họ (nếu có thể về mặt kiến ​​trúc);
3. được định nghĩa cùng nhau nếu chúng tạo thành một tập các hằng số có liên quan đến nhau;
4. được định nghĩa ở một mức độ tổng quát thích hợp trong ứng dụng mà chúng được sử dụng; và
5. được định nghĩa theo cách để hạn chế việc sử dụng chúng trong các bối cảnh không phù hợp (ví dụ: có thể sửa đổi kiểu kiểm tra).

Điều thường phân biệt "hằng số" được chấp nhận với "giá trị ma thuật" là một số vi phạm một hoặc nhiều quy tắc này.

Được sử dụng tốt, các hằng chỉ đơn giản cho phép chúng ta thể hiện các tiên đề nhất định của mã.

Điều này đưa tôi đến một điểm cuối cùng, đó là việc sử dụng quá mức các hằng số (và do đó có quá nhiều giả định hoặc ràng buộc được biểu thị theo các giá trị), ngay cả khi nó tuân thủ các tiêu chí trên (nhưng đặc biệt là nếu nó lệch khỏi chúng), có thể ngụ ý rằng giải pháp được đưa ra không đủ chung chung hoặc có cấu trúc tốt (và do đó chúng tôi không thực sự nói về ưu và nhược điểm của các hằng số nữa, mà là về ưu và nhược điểm của mã có cấu trúc tốt).

Các ngôn ngữ cấp cao có cấu trúc cho các mẫu trong các ngôn ngữ cấp thấp hơn sẽ phải sử dụng các hằng số. Các mẫu tương tự cũng có thể được sử dụng trong ngôn ngữ cấp cao hơn, nhưng không nên như vậy.

Nhưng đó có thể là một phán đoán của chuyên gia dựa trên ấn tượng về tất cả các tình huống và giải pháp phải như thế nào, và chính xác cách phán quyết đó sẽ được biện minh sẽ phụ thuộc rất nhiều vào bối cảnh. Thật vậy, nó có thể không chính đáng theo bất kỳ nguyên tắc chung nào, ngoại trừ để khẳng định "Tôi đủ tuổi để xem loại công việc này, mà tôi quen thuộc, làm tốt hơn"!

EDIT: đã chấp nhận một chỉnh sửa, từ chối một chỉnh sửa khác và hiện đã thực hiện chỉnh sửa của riêng tôi, bây giờ tôi có thể xem xét định dạng và dấu chấm câu trong danh sách quy tắc của mình để được giải quyết một lần và mãi mãi haha!

• Họ rất khó để theo dõi.
• Thay đổi tất cả có thể yêu cầu thay đổi nhiều tệp trong nhiều dự án (khó duy trì).
• Đôi khi thật khó để nói mục đích của họ chỉ là nhìn vào giá trị của họ.
• Không sử dụng lại.

Ví dụ thực tế: Tôi đang làm việc với một hệ thống bên thứ ba trong đó "thực thể" được lưu trữ với "các trường". Về cơ bản là một hệ thống EAV . Vì khá dễ dàng để thêm một trường khác, bạn có quyền truy cập vào một trường bằng cách sử dụng tên của trường dưới dạng chuỗi:

Field nameField = myEntity.GetField("ProductName");

(lưu ý chuỗi ma thuật "ProductName")

Điều này có thể dẫn đến một số vấn đề:

• Tôi cần tham khảo tài liệu bên ngoài để biết rằng "ProductName" thậm chí còn tồn tại và chính tả của nó
• Thêm vào đó tôi cần tham khảo tài liệu đó để xem kiểu dữ liệu của trường đó là gì.
• Typose trong chuỗi ma thuật này sẽ không bị bắt cho đến khi dòng mã này được thực thi.
• Khi ai đó quyết định đổi tên trường này trên máy chủ (khó khăn trong khi ngăn chặn dataloss, nhưng không phải là không thể), thì tôi không thể dễ dàng tìm kiếm thông qua mã của mình để xem nơi tôi nên điều chỉnh tên này.

Vì vậy, giải pháp của tôi cho việc này là tạo các hằng số cho các tên này, được sắp xếp theo loại thực thể. Vì vậy, bây giờ tôi có thể sử dụng:

Field nameField = myEntity.GetField(Model.Product.ProductName);

Nó vẫn là một hằng chuỗi và biên dịch thành cùng một nhị phân, nhưng có một số lợi thế:

• Sau khi tôi đã gõ "Model.", IDE của tôi chỉ hiển thị các loại thực thể có sẵn, vì vậy tôi có thể dễ dàng chọn "Sản phẩm".
• Sau đó, IDE của tôi chỉ cung cấp các tên trường có sẵn cho loại thực thể này, cũng có thể chọn.
• Tài liệu được tạo tự động cho thấy ý nghĩa của trường này là gì với kiểu dữ liệu được sử dụng để lưu trữ các giá trị của nó.
• Bắt đầu từ hằng số, IDE của tôi có thể tìm thấy tất cả những nơi sử dụng hằng số chính xác đó (trái ngược với giá trị của nó)
• Typose sẽ bị bắt bởi trình biên dịch. Điều này cũng áp dụng khi một mô hình mới (có thể sau khi đổi tên hoặc xóa một trường) được sử dụng để lấy lại các hằng số.

Tiếp theo trong danh sách của tôi: ẩn các hằng số này phía sau các lớp được gõ mạnh - sau đó cũng là kiểu dữ liệu được bảo mật.

Chuỗi ma thuật không phải lúc nào cũng xấu , vì vậy đây có thể là lý do bạn không thể đưa ra lý do chăn để tránh chúng. (Theo "chuỗi ma thuật" Tôi giả sử bạn có nghĩa là chuỗi ký tự là một phần của biểu thức và không được định nghĩa là hằng số.)

Trong một số trường hợp cụ thể, nên tránh các chuỗi ma thuật:

• Chuỗi tương tự xuất hiện nhiều lần trong mã. Điều này có nghĩa là bạn có thể có một lỗi chính tả một trong những nơi. Và nó sẽ là một rắc rối của các thay đổi chuỗi. Biến chuỗi thành một hằng số, và bạn sẽ tránh được vấn đề này.
• Chuỗi có thể thay đổi độc lập với mã nơi nó xuất hiện. Ví dụ. nếu chuỗi là văn bản được hiển thị cho người dùng cuối, nó có thể sẽ thay đổi độc lập với bất kỳ thay đổi logic nào. Tách chuỗi đó thành một mô-đun riêng (hoặc cấu hình bên ngoài hoặc cơ sở dữ liệu) sẽ giúp dễ dàng thay đổi độc lập
• Ý nghĩa của chuỗi không rõ ràng từ ngữ cảnh. Trong trường hợp đó, việc giới thiệu một hằng số sẽ làm cho mã dễ hiểu hơn.

Nhưng trong một số trường hợp, "chuỗi ma thuật" vẫn ổn. Giả sử bạn có một trình phân tích cú pháp đơn giản:

switch (token.Text) {
  case "+":
    return a + b;
  case "-":
    return a - b;
  //etc.
}

Thực sự không có phép thuật nào ở đây, và không có vấn đề nào được mô tả ở trên áp dụng. Sẽ không có lợi ích IMHO để xác định, string Plus="+"vv Giữ cho nó đơn giản.

Để thêm vào câu trả lời hiện có:

Quốc tế hóa (i18n)

Nếu văn bản hiển thị trên màn hình được mã hóa cứng và bị chôn vùi trong các lớp chức năng, bạn sẽ gặp khó khăn khi cung cấp bản dịch văn bản đó sang các ngôn ngữ khác.

Một số môi trường phát triển (ví dụ Qt) xử lý các bản dịch bằng cách tra cứu từ chuỗi văn bản ngôn ngữ cơ sở sang ngôn ngữ dịch. Chuỗi ma thuật nói chung có thể tồn tại điều này - cho đến khi bạn quyết định bạn muốn sử dụng cùng một văn bản ở nơi khác và nhận được một lỗi đánh máy. Thậm chí sau đó, rất khó để tìm ra chuỗi ma thuật nào cần dịch khi bạn muốn thêm hỗ trợ cho ngôn ngữ khác.

Một số môi trường phát triển (ví dụ MS Visual Studio) thực hiện một cách tiếp cận khác và yêu cầu tất cả các chuỗi dịch được giữ trong cơ sở dữ liệu tài nguyên và đọc lại ngôn ngữ hiện tại bằng ID duy nhất của chuỗi đó. Trong trường hợp này, ứng dụng của bạn với các chuỗi ma thuật đơn giản là không thể dịch sang ngôn ngữ khác mà không cần làm lại chính. Phát triển hiệu quả đòi hỏi tất cả các chuỗi văn bản phải được nhập vào cơ sở dữ liệu tài nguyên và được cấp một ID duy nhất khi mã được viết lần đầu tiên và sau đó i18n tương đối dễ dàng. Cố gắng lấp đầy điều này sau khi thực tế thường đòi hỏi một nỗ lực rất lớn (và vâng, tôi đã ở đó!) Vì vậy tốt hơn hết là làm mọi việc ngay từ đầu.

Đây không phải là ưu tiên của tất cả mọi người, nhưng nếu bạn muốn tính toán các số liệu về khớp nối / kết dính trên mã của mình theo cách tự động, chuỗi ma thuật làm cho điều này gần như không thể. Một chuỗi ở một nơi sẽ tham chiếu đến một lớp, phương thức hoặc hàm ở một nơi khác và không có cách nào dễ dàng, tự động để xác định rằng chuỗi được ghép với lớp / phương thức / hàm chỉ bằng cách phân tích mã. Chỉ khung cơ bản (Angular, ví dụ) có thể xác định rằng có một mối liên kết - và nó chỉ có thể thực hiện nó trong thời gian chạy. Để tự lấy thông tin ghép nối, trình phân tích cú pháp của bạn sẽ phải biết mọi thứ về khung công tác bạn đang sử dụng, bên trên và ngoài ngôn ngữ cơ bản mà bạn đang mã hóa.

Nhưng một lần nữa, đây không phải là điều mà rất nhiều nhà phát triển quan tâm.