Làm thế nào để tìm hiểu xem lỗi chính tả trong mã nguồn có phải là một vấn đề nghiêm trọng hay không? [đóng cửa]

Tôi thấy rất nhiều lỗi chính tả mà tôi thấy hàng ngày trong cơ sở mã của chúng tôi, từ đó tôi sẽ tái tạo một ví dụ rất ngắn nhưng mang tính đại diện:

ArgumnetCount
Timeount
Gor message from queue 

Thật không may, điều này là không giới hạn ở một người. Có rất nhiều người nói tiếng Anh không phải là người bản ngữ trong nhóm của chúng tôi đã góp phần vào đó, tuy nhiên tôi cũng có thể xác định một số lỗi chính tả tồi tệ nhất đối với Kiến trúc sư phần mềm của chúng tôi là người Mỹ, sinh ra và lớn lên.

Chúng cũng được tìm thấy ngay cả trong email, bài thuyết trình, tài liệu, bất kỳ mẩu thông tin bằng văn bản nào chúng tôi có trong một công ty phát triển phần mềm.

Tôi muốn biết làm thế nào để tìm hiểu nếu nó là một vấn đề nghiêm trọng hay không?

_{Tôi luôn gặp phải những lỗi chính tả này, nhưng chính sách cá nhân, chính thức của tôi là chúng tôi không được trả tiền để đánh vần đúng, chúng tôi được trả tiền để hoàn thành công việc, vì vậy trong công ty tôi không bao giờ thực sự chỉ trích bất cứ ai về điều đó. Nhưng tôi đã nêu ra vấn đề này với một số người bạn thân của tôi, và không bao giờ giải quyết nó cho tốt.}

Lỗi chính tả có thể có nghĩa là một trong hai điều sau:

• Người làm cho họ không thành thạo tiếng Anh và không dành thời gian để bù lại bằng cách sử dụng các công cụ thích hợp (từ điển, kiểm tra chính tả, v.v.)
• Người làm cho họ thành thạo tiếng Anh, nhưng không quan tâm đến chính tả.

Hoặc là một dấu hiệu khá xấu, bởi vì điều đó có nghĩa là người được hỏi không có khả năng đọc, duy trì và thanh lịch cao trong danh sách ưu tiên của họ; nếu nguyên nhân là do thiếu thông thạo tiếng Anh, điều đó cũng có nghĩa là người đó thiếu hai kỹ năng thiết yếu - giao tiếp bằng tiếng Anh và cảm nhận chung về ngôn ngữ (nếu bạn không thể diễn đạt rõ ràng bằng tiếng Anh, rất có thể bạn có thể ' t thể hiện chúng tốt trong một ngôn ngữ lập trình).

Nhưng tại sao chính xác là lỗi chính tả xấu, tất cả những người khác đều bằng nhau? Rốt cuộc, mã hoạt động và trình biên dịch hoàn toàn không quan tâm đến cách bạn đặt tên định danh của mình, miễn là chúng không vi phạm các quy tắc cú pháp. Lý do là chúng tôi viết mã không chỉ cho máy tính, mà còn và hầu hết, cho con người. Nếu đó không phải là trường hợp, chúng tôi vẫn sẽ sử dụng lắp ráp. Mã nguồn được viết một lần, nhưng đọc hàng trăm lần trong vòng đời của nó. Lỗi chính tả làm cho việc đọc và hiểu mã nguồn khó hơn - lỗi nhẹ khiến người đọc vấp ngã trong một phần của giây, nhiều trong số đó có thể gây ra sự chậm trễ đáng kể; lỗi thực sự xấu có thể khiến mã nguồn hoàn toàn không thể đọc được. Có một vấn đề khác, đó là hầu hết các mã bạn viết sẽ được gọi bằng mã khác và mã đó thường xuyên hơn không được viết bởi người khác. Nếu bạn viết sai chính tả, người khác sẽ phải nhớ (hoặc tra cứu) không chỉ tên đó là gì, mà còn chính xác nó bị sai chính tả như thế nào. Điều này làm mất thời gian và phá vỡ dòng chảy lập trình; và vì hầu hết các mã được chạm nhiều lần trong bảo trì, mỗi lỗi chính tả gây ra rất nhiều gián đoạn.

Xem xét làm thế nào thời gian của nhà phát triển bằng tiền lương bằng với chi phí, tôi nghĩ rằng nó đủ dễ để thực hiện một trường hợp này; Rốt cuộc, phá vỡ dòng chảy và quay trở lại vào nó có thể mất tới 15 phút. Bằng cách này, một lỗi chính tả nghiêm trọng có thể dễ dàng tiêu tốn vài trăm đô la để phát triển và bảo trì hơn nữa (nhưng chúng là chi phí gián tiếp, không thể nhìn thấy trực tiếp trong các ước tính và đánh giá, do đó chúng thường bị quản lý bỏ qua).

Tôi thực sự nghi ngờ liệu "Timeount" có phải là vấn đề không phải là người bản ngữ hay không. Mọi người tạo ra hàng tấn lỗi chính tả trong ngôn ngữ đầu tiên của họ. Tôi sẽ không đủ điều kiện cho những ví dụ cụ thể này là "Tham gia".

Phải nói rằng, tôi hiểu rằng đó không phải là về những ví dụ cụ thể này. Tôi đồng ý với bạn về nguyên tắc. Tôi đã gặp những rắc rối thực tế gây ra bởi loại công cụ này ("nếu không có cột có tên đính kèm, hãy tạo tệp đính kèm").

Trở thành một lập trình viên là về sự chính xác và cẩn thận với các lỗi chính tả, dấu phẩy, dấu chấm phẩy, dấu chấm, hầu hết thời gian là ngôn ngữ của con người.

Lần đầu tiên bạn lãng phí thời gian để tìm kiếm Timeoutbiến chỉ để tìm ra nó được viết Timeount, bạn sẽ biết một lý do khác tại sao chính tả lại quan trọng.

Nếu vấn đề này làm phiền bạn, hầu hết các IDE hiện nay đều cho phép kiểm tra chính tả trong các bình luận để ít nhất chứng khó đọc có thể trông giống như họ biết cách đánh vần. Nó chắc chắn giúp tôi! Do đó, một "sửa chữa" tầm thường để có chính tả tốt.

Lỗi chính tả trong tên và phương thức lớp công khai chỉ đơn giản là không chuyên nghiệp. Họ tốn thời gian và tiền bạc. Chúng gây đau đớn trong các ngôn ngữ được gõ tĩnh như Java, nơi IDE có thể tạo ra một menu các tên lớp và phương thức. Họ không thể chịu đựng được trong các ngôn ngữ gõ động.

Thậm chí tệ hơn là lỗi chính tả trong tên bảng cơ sở dữ liệu và tên cột.

Theo kinh nghiệm của tôi, chính tả chỉ liên quan một chút đến trình độ tiếng Anh của người viết mã. Tôi đã thấy những người nói tiếng Anh bản địa sản xuất mã với các lỗi chính tả và ngắt từ ngẫu nhiên, và đã thấy những người nói tiếng Anh không phải là người bản ngữ cẩn thận để tạo ra cách viết đúng. Nhưng chính tả có liên quan cao đến chất lượng mã tổng thể. Lập trình viên có khả năng, bất kể trình độ tiếng Anh của họ, quan tâm đến chất lượng công việc của họ, và cẩn thận với việc đặt tên.

Trong mã nguồn, các bài thuyết trình và tài liệu nội bộ, v.v ... những lỗi chính tả nhỏ không làm thay đổi ý nghĩa hoặc cản trở sự hiểu biết không phải là một biểu tượng. Chỉ cần sửa chúng trong nguồn nếu bạn thấy chúng khó chịu.

Ngoài ra, đặc biệt trong các ý kiến, chất quan trọng hơn hình thức. Không có Engrish ở đây:

Chuỗi s = "Wikipedia"; / * Gán giá trị "Wikipedia" cho biến s. * /

Thực tế là một số người tự nhiên là nhà văn cẩn thận hơn một số người khác (cho dù điều này là do giáo dục, hoặc do thái độ, hoặc do trí thông minh hoặc bất cứ điều gì, không liên quan). Bao nhiêu nỗ lực để sửa chữa đó là một câu hỏi giá trị kinh doanh: bạn có nhận được nhiều giá trị hơn từ việc sửa lỗi chính tả, hơn là bạn dành nỗ lực để sửa chúng không? Trong trường hợp nội bộ, câu trả lời thường là không. Khách hàng của bạn sẽ không phàn nàn về lỗi chính tả trong các nhận xét về mã nguồn của bạn (trừ khi bạn đang làm nguồn mở).

Việc đánh máy sai và nhận xét không phù hợp là không chuyên nghiệp và nên tránh, nhưng trọng tâm phải là những thứ quan trọng (nghĩa là tạo ra giá trị kinh doanh, nếu bạn làm việc cho doanh nghiệp).

Công cụ hiển thị công khai tất nhiên phải được đọc bằng chứng cẩn thận.

Vấn đề ở đây không phải là bản thân người Anh mà là sự thiếu nhận xét rõ ràng. Tiếng Anh hoàn hảo là không cần thiết, tiếng Anh rõ ràng là. Nó tầm thường để chạy một cái gì đó thông qua google để nhận các lỗi rõ ràng.

Ví dụ, nó không rõ ràng từ cái nhìn đầu tiên nếu Gor message from queuecó nghĩa là "nhận được tin nhắn từ hàng đợi" hoặc "tin nhắn GOR từ hàng đợi". Bạn sẽ cần phải đọc mã để hiểu ý nghĩa của bình luận (do đó đánh bại đối tượng của bình luận).

Bạn nên yêu cầu thực hiện đánh giá mã trong công ty của bạn. Sau đó, bạn có thể "chỉ trích" mọi người theo cách xây dựng trong khi họ làm điều tương tự với bạn.

Rõ ràng là trình biên dịch không quan tâm đến lỗi chính tả, miễn là bạn đang sử dụng cùng một cách viết, ví dụ như khi tham chiếu một biến. Câu hỏi sau đó là liệu lỗi chính tả có tác động tiêu cực đến khả năng duy trì mã của các thành viên trong nhóm hay không.

Cách duy nhất tôi có thể thấy để làm điều đó là nói chuyện với những người đang bảo trì và bạn có thể bắt đầu bằng cách hỏi liệu có ai gặp khó khăn hơn khi tuân theo mã có lỗi chính tả không.

Tôi không nghĩ có cách nào để loại bỏ hoàn toàn tính chủ quan khỏi vấn đề này, nhưng để giảm bớt nó, bạn có thể (bằng tay hoặc thông qua một tập lệnh) quét nguồn để có được một số lỗi chính tả ước tính cho một mô-đun mã cụ thể và xem nếu bảo trì trên các mô-đun có số lỗi sai chính tả trung bình mất nhiều thời gian hơn so với các mô-đun có ít lỗi chính tả hơn.

Tất nhiên, không phải tất cả các mô-đun đều được thực hiện như nhau, vì vậy bạn có thể suy nghĩ về việc cân nhắc kết quả của mình với các số liệu khác nhau, chẳng hạn như độ phức tạp theo chu kỳ của mô-đun.

Theo kinh nghiệm của tôi, các lỗi chính tả cơ bản như vậy là rắc rối, và có thể là triệu chứng của các vấn đề sâu hơn. Mỗi dự án tôi đã làm việc với các lỗi "tầm thường" như vậy có vấn đề thực sự trong thiết kế, bằng cách nào đó, nó đã vượt qua quá trình xem xét chỉ để phát triển trong quá trình phát triển, đó không phải là khi bạn muốn tìm hiểu rằng chức năng quan trọng mà bạn thực sự cần không có ở đó

Tôi sẽ kiểm tra kỹ các thông số kỹ thuật cho hệ thống (nếu chúng tồn tại) và kiểm tra thiết kế tổng thể; Tôi sẽ không ngạc nhiên nếu bạn tìm thấy một số lỗ hổng.

Đây thực sự là hai vấn đề riêng biệt, nhưng có liên quan. Nó phụ thuộc vào vị trí sai chính tả:

1) Trong mã nguồn. Nếu bạn có một mã định danh như thế ArgumnetCount, điều đó có thể tạo ra các vấn đề thực sự khi có ai đó xuất hiện và sử dụng đúng chính tả. Vì vậy, bạn nên sửa chữa những sai lầm bất cứ khi nào có thể. Nếu bạn cần duy trì khả năng tương thích API ngược, bạn có thể làm một số việc như:

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2) Trong văn bản có thể đọc được của con người (email, tài liệu, nhận xét mã). Viết chính xác là rất quan trọng, nhưng tôi sẽ nói đó là ưu tiên thấp hơn, vì phần mềm phân tích cú pháp trong đầu bạn dễ tha thứ hơn rất nhiều. Nếu bạn thấy một văn bản có một vài lỗi, điều đó vẫn có thể đọc được, thì đừng lo lắng về nó - đó không phải là vấn đề của bạn. Nhưng nếu ai đó gửi cho bạn một số thứ vô nghĩa liên quan miễn phí và mong bạn sử dụng thứ vô nghĩa đó làm bản thiết kế cho một ứng dụng web nhiều người dùng, thì bạn nên gửi cho tác giả một ghi chú lịch sự yêu cầu làm rõ (đại loại như: "Bạn không biết chữ, làm thế nào bạn mong tôi hiểu chuyện này à? ")

Tiếng Anh đánh vần đúng là phải có trong mã. Tôi cũng có một codebase lớn chứa đầy sự vô nghĩa trong đó và đó là một cơn ác mộng để duy trì.

Đừng để điều này ra khỏi tầm tay. Cố gắng giáo dục mọi người rằng những người duy trì mã không làm phiền người đọc.

Vâng, đây là một vấn đề văn hóa nhiều mặt.

Phát biểu từ quan điểm của người Đức: chúng tôi nhận thấy cách ngôn ngữ của chúng ta ngày càng bị ảnh hưởng bởi các thuật ngữ tiếng Anh. Điều này đi xa như các công ty quốc gia có khẩu hiệu tiếng Anh hoặc quảng cáo. Một số người, đặc biệt là ở các vị trí quản lý trong khi đó dường như không thể nói ra nhưng một câu bằng tiếng Đức. Bài phát biểu của họ chứa đầy những từ ngữ ồn ào và tiếng lóng quản lý khó hiểu. Chúng tôi nói những người như vậy đang nói "denglish".

Do tình trạng này và tiếng Anh là "ngôn ngữ chung" đặc biệt là trong kinh doanh phần mềm, không thể tránh khỏi việc tiếng Anh bị ảnh hưởng bởi số lượng lớn người không nói tiếng mẹ đẻ. Nhưng đối với người bản ngữ nói tiếng Anh, điều này vẫn tốt hơn là phải nói dối, nói, tiếng Trung để tham gia vào ngành công nghiệp SW.

Là màu hay màu? Phiên bản có tiếng Anh làm bạn nghĩ là đúng? Một người viết đúng chính tả là một lý do khác của người đàn ông để bắt đầu một cuộc chiến có thể chiến thắng.

Nếu bạn muốn bắt đầu một cuộc chiến, hãy chọn những trận chiến của bạn một cách cẩn thận và chiến thắng chúng. Trong trường hợp của bạn, đừng lo lắng về các bình luận, hãy bớt lo lắng về nội bộ và tập trung (gần như) độc quyền vào API

Tôi có một câu châm ngôn: Mã gọn gàng không nhất thiết có nghĩa là một đầu óc gọn gàng, nhưng sự phản đối chắc chắn là đúng: mã không gọn gàng, tâm trí không gọn gàng.

Một lập trình viên không dành thời gian để đặt tên chính xác và đánh vần chính xác các bình luận gần như chắc chắn không dành thời gian để làm bất cứ điều gì khác một cách chính xác. Việc lập trình viên có phải là người nói tiếng Anh bản ngữ không là vấn đề thực sự, vì các vấn đề với tiếng Anh của anh ta có thể (và nên) được giải quyết trong quá trình đánh giá ngang hàng.

Vâng, đó là một vấn đề nghiêm trọng cho sản phẩm, cho nhóm và cho các cá nhân.

• Đối với sản phẩm: việc hiệu chỉnh có thể giới thiệu các lỗi chỉ được khách hàng bắt gặp
• Đối với nhóm: nhóm dành thời gian sửa mã hóa cẩu thả thay vì tạo giá trị
• Đối với các cá nhân: chính tả xấu làm cho bạn trông ngu ngốc và làm giảm sự chuyên nghiệp của bạn giữa các đồng nghiệp.