it-swarm-vi.com

Tôi có nên chỉ ra các lỗi liên quan đến chính tả / ngữ pháp trong mã của ai đó không?

Trong khi xem xét mã của đồng nghiệp, tôi đã gặp một số lỗi chính tả trong tên hàm và cả các lỗi ngữ pháp như doesUserHasPermission() thay vì doesUserHavePermission() trong tên hàm và tên biến.

Tôi nên chỉ ra những điều này cho anh ta hay tôi quá tầm phào khi nhận thấy những điều này?

109
Rahul

Mã có lỗi chính tả và ngữ pháp là không thể nhầm lẫn .

  • Mọi người sẽ không nhớ ngữ pháp xấu, vì vậy họ sẽ cố gắng gọi hàm như nó đã được viết và đó là cách các lỗi xảy ra.

  • Bạn không thể grep cho một cái gì đó trong mã nếu bạn không biết nó được đánh vần như thế nào.

  • Hầu hết những người tạo ra ngữ pháp/chính tả làm điều đó không nhất quán, vì vậy họ sẽ giới thiệu nhiều lỗi với cách đặt tên không khớp. Điều này đặc biệt có vấn đề trong các ngôn ngữ không yêu cầu các biến phải được khai báo rõ ràng trước khi sử dụng, bởi vì bạn có thể đưa ra một cách viết mới và mã của bạn sẽ không dừng lại để cho bạn biết bạn đã sai lầm.

Sửa chữa những vấn đề này không phải là vấn đề mang tính mô phạm, cũng không bắt buộc chủ yếu bởi ý kiến ​​của người khác về trí thông minh, khả năng đọc viết, v.v. (mặc dù đó là một tác dụng phụ lớn); đó là về cách viết chất lượng, mã duy trì.

210
HedgeMage

Vâng chắc chắn. Việc nhớ tên sẽ dễ hơn nếu đúng về mặt ngữ pháp. Cố gắng nhớ tên lỗi ngữ pháp là một điều hoàn toàn khác.

39
Jason Baker

Đừng chỉ ra chúng là khuyết điểm trong đánh giá mã chính thức. Thay vào đó, đánh dấu một danh sách và nói chuyện với anh ấy/cô ấy RIÊNG TƯ về họ. Hãy ngoại giao hết mức có thể về nó, chỉ là "Này, một điều tôi nhận thấy và tôi đã gặp phải những người THỰC SỰ xem thường loại chuyện này, họ nghĩ rằng nó làm cho lập trình viên trông bất cẩn và cẩu thả."

Nếu đây là mã mà khách hàng sẽ thấy, nó hoàn toàn PHẢI được sửa. Dù muốn hay không, điều đó phản ánh về danh tiếng của công ty bạn.

Đối với ví dụ bạn đã đưa ra, tôi nghi ngờ nó bắt đầu là UserHasPermission và một người khác nói với anh ta rằng thực tiễn địa phương là doesUserBlahBlah () chứ không phải là UserBlahBlah (), và anh ta chỉ bỏ qua thay đổi ngữ pháp.

28
John R. Strohm

Tự thay đổi.

Hy vọng rằng bạn đang ở trong một môi trường mà mã "quyền sở hữu" không phải là vấn đề. Nếu bạn có quyền truy cập vào dự án trong kiểm soát nguồn, chỉ cần đi vào và tự sửa nó. Nếu bạn thấy một đồng nghiệp cụ thể mắc cùng một loại lỗi ngữ pháp hoặc chính tả, bạn có thể muốn chỉ ra, nhưng điều đó sẽ phụ thuộc vào mối quan hệ của bạn, cho dù người đó là người nói tiếng Anh bản địa và khả năng tiếp thu chung của họ. Nhưng cho dù bạn có quyết định làm điều đó hay không, chỉ cần lặng lẽ đi và sửa chữa. Tôi làm điều này mọi lúc, nếu tôi thấy một lỗi đánh máy, đặc biệt là trong chữ ký phương thức hoặc tài sản công cộng, tôi chỉ sửa nó. Thỉnh thoảng tôi thậm chí không thể cưỡng lại sự cám dỗ để sửa lỗi đánh máy trong một bình luận, nhưng đó chỉ là tôi :)

10
Marcie

Tôi đoán giá trị của nó được đề cập ở đây là tiêu đề người giới thiệu HTTP trong giao thức HTTP bị sai chính tả là "người giới thiệu" (và chúng ta phải sống với nó/chúng ta đã học cách sống với nó.) :)

6
Bunny Rabbit

Tôi là một nhà phát triển có ngôn ngữ mẹ đẻ không phải là tiếng Anh, thực ra là tiếng Hà Lan và sẽ không phiền nếu ai đó chỉ cho tôi một lỗi ngữ pháp hoặc chính tả. Bằng cách đó tôi có thể liên tục cải thiện tiếng Anh của mình. Và chắc chắn không khó để sửa tất cả các lỗi trong tất cả các mã nguồn của bạn. Một tập lệnh Perl đơn giản có thể dễ dàng được viết để lặp qua tất cả các tệp trong một thư mục. Có lẽ thậm chí nó có thể được thực hiện với sed? Tôi không biết.

Vì vậy, tôi chắc chắn sẽ chỉ ra các lỗi ngữ pháp hoặc chính tả trong mã của người khác, nhưng chỉ khi tôi hoàn toàn chắc chắn rằng đó là chính xác những gì tôi đang nói.

6
user11317

Tôi đồng ý với các câu trả lời khác nói rằng mã có lỗi ngữ pháp là không thể nhầm lẫn.

Tôi cũng muốn thêm một vài điều:

  • Mã thường được viết bởi những người không nói tiếng Anh tốt và/hoặc tiếng Anh không phải là ngôn ngữ mẹ đẻ của họ. Nếu có lỗi ngữ pháp trong mã bạn xem xét, điều này không có nghĩa là đồng nghiệp của bạn mắc lỗi này. Có lẽ nó chỉ là một bản sao-dán từ một trang web.
  • Nếu tiếng Anh không phải là ngôn ngữ mẹ đẻ của đồng nghiệp của bạn, thì đó có thể là một ý tưởng tốt hoặc rất xấu để nói với cô ấy/anh ấy về sai lầm này. Đến từ Pháp, tôi luôn hoan nghênh những nhận xét về những lỗi tôi mắc phải trong tiếng Anh, bởi vì đó là cách duy nhất tôi có thể tránh được chúng trong tương lai; mặt khác, tôi biết một số người cảm thấy thực sự đau lòng nếu bạn nói với họ về những lỗi ngữ pháp mà họ mắc phải.
  • Giống như John R. Strohm đã nói, đừng bao giờ làm điều đó một cách công khai. Hầu hết mọi người sẽ thực sự khó chịu vì điều này.
4
Arseni Mourzenko

Tôi sẽ khuyên bạn nên sử dụng một IDE với trình kiểm tra chính tả tích hợp. IntelliJ Idea thực hiện một công việc tuyệt vời cho các chương trình Java. Có rất nhiều lỗi chính tả mà nó bắt được, không chỉ trong tên của các hàm, nhưng trong các thông báo ngoại lệ, người dùng sẽ thấy. Một chương trình tạo ra các thông báo đầy lỗi chính tả không truyền cảm hứng cho sự tự tin.

2
Roman Zenka

Đây là một lỗi nhỏ trong mã, nhưng là một lỗi. Đối xử với nó như bất kỳ sai lầm khác mà bạn tìm thấy. Chính sách của tôi là luôn cho rằng đồng nghiệp của mình có năng lực và đối xử với họ theo cách đó cho đến khi họ chứng minh điều khác.

Nếu đó là một lỗi duy nhất tôi có thể sửa nó và kiểm tra xem. Nếu đó là một mô hình tôi có thể bắt đầu yêu cầu đồng nghiệp đó xem xét các sửa lỗi đó. Hãy cho họ biết rằng bạn nghĩ họ là một lập trình viên giỏi, nhưng đây là điều tốt để cải thiện. Tôi không nghĩ rằng tôi đã bao giờ thực hiện một vấn đề lớn về một cái gì đó như thế này mặc dù.

Miễn là bạn không coi nó như một vấn đề lớn, thật dễ dàng để đưa đồng nghiệp đó vào một vị trí mà họ có thể cải thiện mà không đặt cái tôi lên hàng đầu.

0
overstood

Áp dụng quy tắc vàng

Làm cho người khác như bạn sẽ có họ làm cho bạn.

Tôi muốn người khác quay lưng lại với việc này, vì vậy tôi giúp đỡ người khác. Trở nên duyên dáng và hỗ trợ có thể đi một chặng đường dài có lợi cho bạn.

0
kevpie

Cũng như nhiều thực tiễn lập trình tốt khác, cách duy nhất, phi chính trị và hiệu quả để thực hiện chính sách về chính tả trong các chương trình là tự động hóa nó như một phần của quy trình trước khi cam kết. Tự động hóa sẽ cứu bạn khỏi số lượng lớn khiếu nại ngay cả khi bạn phải viết công cụ của riêng mình cho mục đích này.

0
Apalala

Tôi chỉ làm nếu

  • nó ảnh hưởng đến việc sử dụng chương trình
  • nó ảnh hưởng đến tính chính xác của chương trình
  • Tôi rõ ràng biết tác giả muốn được sửa chữa.

Cũng như một ghi chú bên lề, nếu tên hàm của bạn đủ dài để có ngữ pháp, thì có lẽ chúng quá dài. Trong ví dụ đã cho, tôi sẽ gọi hàm serHasPermission và di chuyển "ngữ pháp" vào mã của bạn, đại loại như thế này:

if userHasPermission() ...
0
Mark Harrison

Điều này cũng xảy ra RẤT NHIỀU trong dự án của tôi (được phổ biến bởi những người nói tiếng Do Thái, tiếng Nga hoặc tiếng Ả Rập), nhưng thậm chí ở cấp độ cao hơn - tôi thường thấy mã sử dụng một số thuật ngữ khó hiểu xảy ra là từ điển được tạo ra để dịch những gì tác giả đã nghĩ đến, và nó không liên quan gì đến ý nghĩa của chúng ...

Cá nhân, khi nó xảy ra rất thường xuyên và bởi rất nhiều thành viên trong nhóm có thể đã viết mã ngay cả trước khi tôi tham gia dự án, tôi có xu hướng bỏ qua nó, bởi vì nó không thành vấn đề.

Tuy nhiên, nếu tôi cam kết một số tác phẩm trong cùng một tệp như mã hoặc nhận xét đã được viết từ lâu và chúng có lỗi chính tả, tôi sẽ sửa chúng chỉ vì nó không quá nhiều công việc.

0
Daniel Hershcovich