Sửa một lỗi chính tả trong một tên phương thức

73

Một trong những phương pháp mà tôi thường sử dụng trong cơ sở mã của chúng tôi là sai chính tả (và nó có trước tôi).

Điều này thực sự gây khó chịu cho tôi không chỉ đơn giản vì nó bị viết sai mà quan trọng hơn là nó khiến tôi LUÔN LUÔN bị nhầm tên ngay lần đầu tiên tôi gõ nó (và sau đó tôi phải nhớ "Ồ, đúng rồi, nó nên bị hiểu sai thành ...")

Tôi đang thực hiện một vài thay đổi xung quanh phương thức ban đầu. Tôi có nên tận dụng cơ hội để đổi tên phương pháp quái đản không?

refactoring

— Một hai ba
nguồn

12

Bạn có thể đổi tên nó? Nếu nó được sử dụng bởi mã mà bạn không kiểm soát, bạn cần chứng minh sự phá vỡ tính tương thích ngược.

16

*sai chính tả. Và bạn sẽ phải thay đổi nó ở mọi nơi mà phương thức đó được gọi.

— JohnP

2

* sai chính tả ... hoặc có thể là một cách viết khác?

— HorusKol

2

@ John John Có ba, bây giờ Một đã được sửa và Hai vẫn không chính xác. Thật trùng hợp với tên của OP khá độc đáo. :)

— vỡ mộng

3

Chúng tôi phải cho phép không có gì được viết sai!

— Magus

136

Tôi có nên tận dụng cơ hội để đổi tên phương pháp quái đản không?

Chắc chắn rồi.

Điều đó nói rằng, nếu mã của bạn đã được phát hành dưới dạng API, bạn thường nên bỏ phương thức sai chính tả và chuyển tiếp sang phương thức được đặt tên chính xác (đánh dấu nó là lỗi thời nếu ngôn ngữ của bạn hỗ trợ những thứ đó).

— Telastyn
nguồn

33

Ý tưởng "chuyển tiếp đến phương pháp được đặt tên chính xác" rất đơn giản và tuyệt vời. Liên kết thú vị trên lý thuyết cửa sổ bị hỏng, là tốt.

— dev_feed

2

Lưu ý rằng nếu đây là một phần của API công khai, đây có thể không phải là thay đổi tương thích ngược (tùy thuộc vào ngôn ngữ). Điều này không phải là không thể xảy ra vì nó có vẻ như .. nếu tôi phải kế thừa từ một API hiện có với một tên sai chính tả, tôi chắc chắn sẽ sửa nó.

— Voo

10

@voo - hả? Ngôn ngữ nào sẽ khiến việc thêm một phương thức mới (và thay đổi cách thực hiện một phương thức để thực hiện cùng một hành vi chính xác) không tương thích ngược?

— Telastyn

3

@Telastyn đôi khi có thể khó để thêm các phương thức để nói các dịch vụ web. Một số khách hàng chùn bước khi thay đổi WSDL chẳng hạn, đột nhiên từ chối nói chuyện với máy chủ. Đó là một vấn đề triển khai trong máy khách, nhưng nếu máy khách là một vấn đề quan trọng mà bạn không muốn làm phiền thì rất có thể ngăn bạn thay đổi giao diện của mình.

— jwenting

17

@Telastyn Nếu tên phương thức sai chính tả trên một giao diện (như trong loại giao diện được sử dụng trong Delphi / Java / C #), thì việc thêm một phiên bản chính tả của tên có thể sẽ phá vỡ tất cả các triển khai hiện có của giao diện đã nói.

— vỡ mộng

52

Có những trường hợp bạn nên tránh thực hiện tái cấu trúc như vậy:

Nếu phương thức được sử dụng trong giao diện công cộng. Một ví dụ điển hình là lỗi chính tả của người giới thiệu trong trình giới thiệu HTTP , lỗi chính tả được giữ lại, bởi vì việc thay đổi chính tả bây giờ sẽ có quá nhiều hậu quả.
Nếu cơ sở mã không được bao phủ bởi bất kỳ thử nghiệm. Bất kỳ tái cấu trúc nào cũng phải được thực hiện trên mã được kiểm tra để có thể thực hiện kiểm tra hồi quy. Tái cấu trúc cơ sở mã không được kiểm tra là rất rủi ro. Nếu bạn có nhiều thời gian, hãy bắt đầu bằng cách thêm các bài kiểm tra; nếu bạn làm việc dưới áp lực thời gian, mạo hiểm giới thiệu các lỗi tinh vi không phải là điều tốt nhất để làm nếu bạn muốn giao hàng đúng giờ.
Nếu phương thức này có thể được sử dụng theo một cách khác thường , điều này khiến cho việc sử dụng nó thực tế không thể tìm thấy (thông qua Ctrl + F hoặc bằng một công cụ tái cấu trúc tự động). Ví dụ, trong C #, một phương thức có thể được gọi thông qua Reflection, làm cho hộp thoại Đổi tên của Visual Studio không hiệu quả. Trong JavaScript, hàm được gọi bên trong eval()cũng khó tìm. Trong PHP, các biến biến có thể gây ra vấn đề.
Nếu quy mô của dự án là rất lớn và phương pháp có thể được sử dụng bởi các đội khác. Điều này tương tự như điểm đầu tiên, tức là giao diện bạn cung cấp cho các đội khác có thể được coi là giao diện chung.
Nếu bạn đối phó với một dự án quan trọng trong cuộc sống. Rất có thể, lỗi chính tả không quá quan trọng để biện minh cho một vài tháng làm giấy tờ để thay đổi tên của phương pháp và đảm bảo nó sẽ không khiến bất kỳ bệnh nhân nào nhận được bức xạ được ủy quyền gấp mười lần hoặc bất kỳ con thoi nào để tính toán sai tốc độ của nó.

Trong mọi tình huống khác, vui lòng đổi tên phương thức.

— Mourzenko
nguồn

1

+1 cho bình luận đề cập đến Reflection, nó đã cắn tôi nhiều lần.

— DaveShaw

33

Nếu dự án quan trọng trong cuộc sống của bạn đủ mong manh để việc tái cấu trúc nhỏ nhất có khả năng giết chết ai đó, thì nó đủ mong manh để không ai có thể tin tưởng vào cuộc sống của họ. Làm thế nào bạn có thể tự tin rằng tính năng mới hoặc giao diện người dùng được sắp xếp hợp lý của bạn không đưa ra các lỗi đe dọa đến tính mạng nếu bạn thậm chí không thể đổi tên một phương thức?

— user2357112

2

Tương tự, nếu một tên phương thức thay đổi gây ra thêm vài tháng giấy tờ (thay vì nói, chủ yếu được chăm sóc bởi giấy tờ cho tất cả các công cụ khác thay đổi cùng một lúc), thì số dư lập trình từ giấy tờ bị lệch theo một số đơn đặt hàng lớn và không thể thực hiện bất kỳ cải tiến lớn nào mà không thay đổi hệ thống.

— dùng2357112

8

@ user2357112: Tôi chưa bao giờ nói rằng việc tái cấu trúc nhỏ nhất có khả năng giết chết ai đó. Đó không phải là về việc giết một ai đó, mà là làm cho mọi thứ có thể giảm thiểu 0,001% nguy cơ còn lại của một lỗi. Điều này đòi hỏi proff chính thức. Điều này đòi hỏi một vài lớp thử nghiệm. Điều này đòi hỏi hình thức. Điều này cấm "Tôi muốn nhanh chóng đổi tên phương pháp này, hy vọng nó sẽ hoạt động!" hành vi. Các dự án quan trọng trong cuộc sống sử dụng các kỹ thuật sẽ bị coi là lãng phí hoàn toàn thời gian và tiền bạc cho bất kỳ ứng dụng kinh doanh nào. Đó là lý do tại sao chúng rất đáng tin cậy (và đắt tiền).

— Arseni Mourzenko

5

@ user2357112: như MainMa đã chỉ ra, đây không phải là về các ứng dụng kinh doanh thông thường. Đó là về loại phần mềm đặc biệt được kiểm tra / xác minh rộng rãi. Điều gì xảy ra nếu phương thức được gọi bằng phản xạ ở đâu đó? Điều gì nếu một số công cụ biên dịch trước / sau làm một cái gì đó với nó? Những gì về tài liệu? Còn các đội khác sử dụng nó thì sao? Họ có sử dụng sự phản chiếu? Điều gì sẽ xảy ra nếu ... Cuộc sống thực đôi khi khá phức tạp. Và đôi khi tốt hơn là để một tên phương thức không bị ảnh hưởng thay vì xác minh nếu có bất kỳ hậu quả nào theo cách chống đạn.

— dagnelies

30

Tôi đã làm điều này một vài tháng trước (vì những lý do khác nhau). Các bước tôi đã thực hiện (ngôn ngữ là Perl):

Đổi tên phương thức. Bí danh tên cũ thành tên mới (điều này không nên phá vỡ bất kỳ mã nào, vì phương thức có thể được gọi bằng một trong hai tên).
Thông báo cho các nhà phát triển còn lại về việc thay đổi tên và tại sao, bảo họ sử dụng tên mới kể từ bây giờ.
Grep cơ sở mã cho tên cũ, sửa chữa bất kỳ sự cố.
Ghi lại bất kỳ việc sử dụng tên cũ (sử dụng tên cũ vẫn còn hoạt động tại thời điểm này). Khắc phục những trường hợp đó.
Đợi (trong khi thực hiện 4.), cho đến khi không còn mục nào xuất hiện trong nhật ký.
Phá vỡ bí danh. Tạo một phương thức bằng cách sử dụng tên cũ ném ra một ngoại lệ nghiêm trọng bằng một thông báo về việc thay đổi tên.
Sau một thời gian, loại bỏ phương thức với tên cũ.

Tất nhiên, số dặm của bạn sẽ thay đổi.

— Abigail
nguồn

Một cải tiến - không dựa vào grep để tìm người dùng tên cũ, cũng đăng nhập vào bên trong giao nhận.

— Ben Voigt

@BenVoigt Không phải đó là những gì # 4 làm?

— Bob

6

Một cách tốt để không phá vỡ bất kỳ mã hiện có nào là xâu chuỗi tên phương thức mới thành cái cũ theo cách như

private void MyNewMethodName()
{
    TheOldMethodName();
}

và sau đó đánh dấu phương thức cũ là lỗi thời (nếu ngôn ngữ của bạn hỗ trợ điều này). Bằng cách này, bất kỳ mã hiện có nào vẫn sẽ hoạt động và bạn có thể dần dần loại bỏ tất cả các lỗi chính tả cũ ra khỏi cơ sở mã của mình. Cuối cùng, bạn thậm chí có thể sao chép / dán phần thân phương thức vào phương thức mới và xóa phần thân cũ.

/ Chỉnh sửa Như ivo đã nói trong nhận xét: Một điều thậm chí tốt hơn để làm là di chuyển mã từ TheOldMethodNamevào MyNewMethodNamevà gọi phương thức mới từ phương thức cũ. Điều này cũng sẽ có lợi thế để giúp các nhà phát triển có được đầu của họ xung quanh nơi mã thuộc về.

— Rémi
nguồn

2

Tôi đồng ý với phương pháp của bạn; Tôi sẽ làm như vậy. Đó là phương pháp tái cấu trúc lành mạnh, rõ ràng và an toàn nhất. Điều cũng có thể là một cách hay là chuyển mã từ phương thức cũ sang phương thức mới và làm cho phương thức cũ sử dụng phương thức mới. Khi codebase là một vài lần lặp xuống dòng thời gian, bạn chỉ cần loại bỏ phương thức cũ không dùng nữa.

— Ivo Limmen

1

@IvoLimmen Đó là một gợi ý thực sự tốt. Bằng cách này, mọi người thậm chí còn tập trung hơn bằng cách sử dụng phương thức mới và điều này sẽ loại bỏ một cảnh báo từ cuộc gọi lỗi thời sang phương thức cũ từ bên trong phương thức mới. Tôi sẽ thêm điều này vào câu trả lời của tôi.

— Rémi

1

Đổi tên phương thức:

Làm điều đó thông qua tái cấu trúc kẻo bạn có nhiều việc phải làm hơn bạn muốn
Nếu IDE của bạn hỗ trợ tự động hoàn thành, hãy sử dụng nó khi tham khảo phương thức đó

Đó là hai lựa chọn bạn có thể đi. Tôi thích tự động hoàn thành (ví dụ: IDE Eclipse) và không cần phải gõ tên phương thức. Đi đổi tên; chỉ cần chắc chắn rằng bạn tìm ra những gì gọi phương thức đó và thay đổi các tham chiếu trực tiếp ở mỗi nơi. Tái cấu trúc sẽ là người bạn của bạn cho điều đó nhưng hãy cẩn thận nhất khi làm như vậy.

— Nấm
nguồn

0

Tôi thường khuyên bạn nên có, đổi tên nó.

Các câu trả lời khác ở đây đã liệt kê các lý do chính đáng tại sao bạn có thể không muốn đổi tên nó, vì vậy nếu bạn thấy mình trong một tình huống như vậy, bạn có thể tạo một phương thức mới với tên và cách thực hiện phù hợp, và thay đổi phương thức cũ để gọi phương thức mới . Sau đó đánh dấu cái cũ là không dùng nữa nếu ngôn ngữ của bạn hỗ trợ nó.

— Brian
nguồn