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? [đóng cửa]

106

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ả 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 bằng cách nhận thấy những điều này?

code-reviews grammar

— La Mã
nguồn

3

Tôi có thể cẩn thận rằng người đó thực sự muốn giúp đỡ với tiếng Anh của họ, nếu đó không phải là ngôn ngữ thứ hai của họ. Một số người hài lòng khi biết rằng họ không có khả năng thể hiện suy nghĩ có cấu trúc, rằng họ chỉ không có khả năng nói tiếng Anh đúng đắn. Nếu tiếng Anh là tiếng mẹ đẻ của họ, thì có, tôi nghĩ ngữ pháp xấu là một vấn đề.

— Rei Miyasaka

31

Đúng. Thật là bực bội khi bạn có một API sai chính tả. Nó lan rộng như ngọn lửa. Vì vậy, tốt hơn là sửa nó càng sớm càng tốt.

9

@Rei: tiếng Anh có phải là ngôn ngữ mẹ đẻ của họ hay không nên không liên quan trong môi trường chuyên nghiệp; nếu nó không quá tệ với họ nhưng không có lý do gì, họ nên được giữ theo cùng tiêu chuẩn.

— Thomas Bonini

4

@Rei, nhiều công việc lập trình tôi thấy được quảng cáo đòi hỏi sự thành thạo Ngôn ngữ bản địa vì lý do này. Có thể thảo luận các yêu cầu, thiết kế, đặc điểm kỹ thuật và xây dựng đều rất quan trọng đối với toàn bộ sản phẩm phần mềm.

— Stephen Furlani

11

HTTP-Refererlàm phiền tôi thường xuyên vi.wikipedia.org/wiki/HTTP_Vferrer#Origin_of_the_term_Vferer

— một mọt sách được trả tiền

205

Mã với 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à phạm vi, 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ề chất lượng viết , mã duy trì .

— Hàng rào
nguồn

7

+1 Đôi khi, việc tiết lộ cảm xúc của ai đó rất quan trọng, nhưng khi đó là đánh giá mã ... nếu bạn nắm bắt được, đó là trò chơi công bằng để bình luận. Công ty của tôi sử dụng nồi nấu kim loại để đánh giá mã, cho phép tất cả các đánh giá thấy rằng nó đã bị bắt và cho phép người đánh giá đánh dấu nó không phải là một khiếm khuyết, mà là phong cách.

— opello

15

+1 - Một khi lỗi chính tả và ngữ pháp xâm nhập vào API, chúng không thể thoát ra được nữa. Tôi đã dành phần tốt hơn trong ba năm để viết "Avtivity" thay vì "Hoạt động", và nó luôn bị tổn thương về mặt thể chất .

— John Bode

7

Để tốt hơn hoặc tồi tệ hơn, thực hành lập trình tốt thường đi xuống một cái gì đó rất giống như nghề giáo. Thêm vào đó, tôi muốn tìm người viết sai chính tả Referrertrong thông số HTTP gốc và đá anh ta vào mắt cá chân. Tất nhiên, đó có lẽ là Berners-Lee và vì vậy tôi cảm thấy có lỗi sau đó ...

— Malvolio

2

@Stephan Furlani: đó là điểm tôi đang cố gắng thực hiện; nó là một phần của API mà chúng tôi không sở hữu. Chúng tôi không thể sửa nó ở cuối, và quá trình sửa nó là xấu và đủ dài để không ai muốn gây rối với nó.

— John Bode

2

@ John Bode, tôi nghĩ bạn nên tạo một hàm bao bọc :) C # có một thủ thuật gọn gàng cho điều đó (mặc dù tôi quên tên của nó).

— Công việc

38

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

— Jason Baker
nguồn

29

Đừ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à UserB nhớBmus () và anh ta chỉ bỏ qua thay đổi ngữ pháp.

— John R. Strohm
nguồn

12

Nói về nhận thức của người khác làm cho nó có vẻ không quan trọng. Nói sự thật - họ đang làm cho mã khó hơn để duy trì và xây dựng.

— HedgeMage

5

@HedgeMage: Kinh nghiệm cá nhân của tôi với những thứ như thế này là một số người TUYỆT VỜI cảm động về những điều họ cho là chỉ trích bản thân. Tồi tệ hơn, có thể có những hậu quả chính trị xấu xí, nếu người mà bạn tỏ ra chỉ trích được quản lý yêu quý. (Vâng, tôi có những vết sẹo để chứng minh điều này.) Cảm nhận cá nhân của tôi là bạn có cơ hội tốt hơn để sửa chữa nó, với những cơn đau đầu khác, nếu bạn đi nhẹ nhàng.

— John R. Strohm

12

@ John Tôi chắc chắn có thể thấy rằng một tình huống làm việc tồi tệ có thể buộc ai đó phải đi trên vỏ trứng như thế - nhưng đó là một tình huống tồi tệ nếu đó là một vấn đề ngay từ đầu. Một người có cái tôi quá mong manh (và văn hóa nơi làm việc cho phép các shenanigans của họ) không tốt cho việc kinh doanh bắt đầu.

— HedgeMage

6

Hầu hết các lập trình viên trưởng thành chấp nhận lời phê bình tốt. Rốt cuộc, đó là những đánh giá ngang hàng dành cho (và tất cả chúng ta đều thực hiện đánh giá mã, phải không?) Việc phê bình chính tả và ngữ pháp của các bình luận, tên hàm, v.v ... Nó không chỉ phản ánh về tác giả mà còn trên toàn bộ tổ chức của họ.

— quick_now

6

Tôi phải đồng ý với HedgeMage ở đây, nếu bạn không thể chỉ ra những lỗi như thế này trong quá trình đánh giá mã (đặc biệt là khi họ sai khách quan, như ví dụ trong câu hỏi) thì bạn đã gặp vấn đề lớn hơn ...

— Dean Harding

10

Tự thay đổi nó.

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ó bao giờ 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 :)

— Marcie
nguồn

5

Và sau đó bạn thấy rằng bạn vừa phá mã của người thứ ba. Bạn cần phải sửa những thứ này càng sớm càng tốt, không chỉ khi bạn có thể lấy nó sau khi anh chàng đầu tiên kiểm tra mọi thứ.

— David Thornley

Nếu bạn lo lắng rằng một bản sửa lỗi cho bất kỳ đoạn mã nào có thể phá vỡ mã "của người khác" và bạn không có cách nào để nói, thì bạn có vấn đề lớn hơn là chính tả.

— Cornel Masson

@CornelMasson: Không hẳn. Đây là một phần quan trọng trong việc thiết kế API.

— Các cuộc đua nhẹ nhàng trong quỹ đạo

6

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

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ó.) :)

— Thỏ thỏ
nguồn

10

Và chúng tôi không bao giờ muốn thấy điều đó một lần nữa.

— David Thornley

4

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.

— Mourzenko
nguồn

11

"Có lẽ nó chỉ là một bản sao-dán từ một trang web." Sau đó, người sao chép nó nên đã bắt được vấn đề và sửa nó. Sao chép nguyên văn và để lại lỗi là xấu hoặc tệ hơn là tự viết và tạo ra lỗi. "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." Trong kinh doanh, tất cả chúng ta nên cư xử như những người trưởng thành và đồng nghiệp đang cùng nhau hoàn thành một mục tiêu chung. Người đưa ra vấn đề cần sử dụng chiến thuật, và người nhận được những lời chỉ trích cần phải chấp nhận nó và phát triển từ nó.

— Tin Man

3

Tôi đồng ý 100% rằng là chuyên gia, chúng ta nên cư xử như người lớn và không nên tự nhận điều này. Nhưng nó hoàn toàn cần phải được chỉ ra và sửa chữa. Có, chiến thuật nên được sử dụng, và nó nên được tiếp cận khi cần thiết, tùy thuộc vào từng cá nhân. Nhưng nếu bạn đang ở trong một môi trường được khuyến khích để tránh vấn đề hoàn toàn, có lẽ đã đến lúc phải rời đi. Điều này sẽ chỉ ra một môi trường bị nhiễm độc.

— Mark Freedman

Bất kỳ lỗi chính tả nào cũng có thể được kiểm tra bằng một tìm kiếm google đơn giản

— JoelFan

2

Tôi sẽ khuyên bạn nên sử dụng 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ỉ ở tên của các hàm, mà trong các thông báo ngoại lệ, người dùng sẽ nhìn thấy. Một chương trình tạo ra các thông điệp đầy lỗi chính tả không truyền cảm hứng cho sự tự tin.

— La Mã Zenka
nguồn

0

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 userHasPermission và chuyển "ngữ pháp" vào mã của bạn, đại loại như thế này:

if userHasPermission() ...

— Đánh dấu Harrison
nguồn

1

Tuy nhiên, vẫn có khả năng mắc lỗi ngữ pháp tương tự, vì trong trường hợp này userHavePermission()sẽ là sai.

— Dean Harding

Nhưng đó chính xác là vấn đề !! userHasPermission()ngụ ý rằng nó trả về một bool vì ngữ pháp ~ HOẶC ~ nó có thể có nghĩa là nó đặt quyền của người dùng. (Cán bộ có cầu :: người dùng có quyền). Nó vẫn còn mơ hồ.

— Stephen Furlani

Mặc dù tôi đồng ý rằng các tên ví dụ trong Q dài không cần thiết, tôi thận trọng về việc khái quát hóa "quá dài". Trong trường hợp này, khái niệm có thể được diễn đạt bằng ít từ hơn, vì vậy nó nên ngắn hơn. Tuy nhiên, "quá dài" là gì? Có một giới hạn ký tự hoặc từ?

— LS

0

Điều này cũng xảy ra RẤT NHIỀU trong dự án của tôi (được cư trú 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.

— Daniel Hershcovich
nguồn

0

Quy tắc vàng áp dụ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.

— kevpie
nguồn

2

-1 cho sự mơ hồ - Tôi không biết bạn đang khuyên người hỏi làm gì.

— HedgeMage

@HedgeMage, tôi khuyên OP nên áp dụng en.wikipedia.org/wiki/The_Golden_Rule

— kevpie

2

Tôi quen thuộc với nó. Ngoài việc ngớ ngẩn một cách ngớ ngẩn (không có lý do nào để tin rằng cách Alice muốn được đối xử là cách Bob muốn được đối xử), nó làm sao lãng vấn đề thực sự: tạo ra mã tốt. Chắc chắn, tôi sẽ không phải là một người khó chịu về điều đó, nhưng tôi không căn cứ vào việc có nên đưa ra một vấn đề kỹ thuật về việc người viết mã xấu có muốn đưa ra hay không!

— HedgeMage

Tôi nghĩ rằng khiếu nại của @ HedgeMage có thể được minh họa như thế này: Tôi muốn mã có chất lượng cao nhất cho phép theo thời gian và tài nguyên có sẵn, bởi vì tôi quan tâm đến dự án và công việc tương lai của tôi đối với nó. Bob muốn tránh những lời chỉ trích cho những sai lầm có thể sửa chữa, bởi vì anh ta không chỉ trích tốt. Chúng tôi sẽ thực hiện "quy tắc vàng" hoàn toàn khác.

— mí mắt

Lời khuyên có nghĩa là OP vận hành cách anh ta muốn được đối xử. Không đối xử với Bob như thế nào Bob muốn được đối xử. Tôi đã khuyến khích OP sửa lỗi Bob vì anh ấy (OP) sẽ muốn được sửa chữa cho các lỗi tương tự, cụ thể là trong bối cảnh mà OP đã chia sẻ.

— kevpie

0

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.

— Apalala
nguồn

3

Nhiều lỗi quan trọng nhất không thể tự động bắt được. Điều này áp dụng cho chính tả và ngữ pháp quá. Bạn có thể thực hiện kiểm tra tự động, nhưng kết quả sẽ phải tương đương với các cảnh báo. Điều này là do trình kiểm tra chính tả tạo ra cả dương tính giả (ví dụ: danh từ riêng) và phủ định sai (hai, quá, to). Vì vậy, can thiệp bằng tay là cần thiết.

— Matthew Flaschen

Loại tự động hóa đó không giải quyết được những vấn đề này, nó chỉ bắt được một số lỗi mà mọi người mắc phải.

— overstood

Tự động sửa ??? Có rất nhiều ví dụ về tự động "không thành công" trên internet. Điều đó chắc chắn không tốt.

— Florian F

0

Đâ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 tôi 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.

— hiểu
nguồn

-1

userPermission () có lẽ? -

Lần cuối cùng tôi gặp là một vấn đề toàn cầu về kết quả tìm kiếm không được làm nổi bật vì tên lớp được đánh vần là cao. Lỗi rất tối nghĩa để phát hiện.

— mplungjan
nguồn

Downvote mà không bình luận là một gớm ghiếc.

— mplungjan

-1

Chắc chắn chỉ ra điều đó, nhưng đừng lãng phí thời gian của bạn để kiểm tra lỗi chính tả. Sử dụng một công cụ để tự động hóa điều này trên CI của bạn. Trên .net fxCop có thể làm điều này ...

— khebbie
nguồn

-2

Nó phụ thuộc phần lớn vào những sai lầm là gì, mức độ phổ biến và mức độ nghiêm trọng của chúng và liệu đó có thực sự là một sai lầm trung thực hay không chỉ là cách bạn nói từ đó.

Cá nhân tôi không thể chịu đựng được khi một tên ngốc kéo đoạn đánh giá mã 5 phút xuống còn nửa giờ vì anh ta muốn mọi thứ được đổi tên thành cách anh ta làm điều đó và tất cả các bình luận được điều chỉnh lại chỉ vì anh ta thích dán vào mái chèo của mình. không cần phải thay đổi "Đang tải các đối tượng dữ liệu" thành "Thành phần trình tải đối tượng dữ liệu sẽ tải các đối tượng dữ liệu có liên quan từ thành phần lưu trữ đối tượng dữ liệu".

/ rant :)

— JohnL
nguồn

2

Nhấn mạnh vào những thứ theo cách của tôi là một điều. Khăng khăng rằng mọi thứ sử dụng đúng chính tả và ngữ pháp là một điều hoàn toàn khác.

— David Thornley

Không hoàn toàn chắc chắn lý do tại sao câu trả lời của tôi xứng đáng với một downvote nhưng không bao giờ ... Ngoài ra, câu trả lời của tôi cho nhận xét của David đi đâu? Dù sao, ngữ pháp tiếng Anh đúng 100% không phải lúc nào cũng được mong muốn trong phát triển. Trong ví dụ trên của tôi, "Đang tải các đối tượng dữ liệu" không phải là một câu hoàn chỉnh, nhưng đó là cách diễn đạt thích hợp hơn của hai từ - ngắn gọn, dễ bản địa hóa và không chiếm nhiều không gian.

— JohnL