Đúng: "bổ sung"
chứ không phải,
Sai: "bổ xung"
"bổ sung": 40 triệu kết quả
"bổ xung": 1.9 triệu kết quả.
Như vậy, nói chung dân ta vẫn dùng đúng chính ta.
Khi review, sai chính tả là rất bad smell, nói chung code sai chính tả là ẩu,khả năng lỗi rất lớn.
Spelling errors can mean one of two things:
The person who makes them is not proficient in English, and doesn't take the time to compensate by using appropriate tools (dictionaries, spell checkers, etc.)
The person who makes them is proficient in English, but doesn't care about spelling at all.
Either is a fairly bad sign, because it means the person in question doesn't have readability, maintainability and elegance high on their priority list; if the cause is a lack of English language proficience, it also means that the person lacks two essential skills - written English communication, and a general feeling for languages (if you can't express your thoughts clearly in English, chances are you can't express them well in a programming language either).
But why exactly are spelling errors bad, all else being equal? After all, the code works, and the compiler doesn't care at all how you name your identifiers, as long as they don't violate the syntax rules. The reason is that we write code not only for computers, but also and most of all, for humans. If that weren't the case, we'd still be using assembly. Source code is written once, but read hundreds of times during its lifecycle. Spelling errors make reading and understanding the source code harder - mild errors cause the reader to stumble for a fraction of a second, many of them can cause considerable delays; really bad errors can render source code completely unreadable. There is another issue, which is that most of the code you write will be referred to by other code, and that code more often than not is written by someone else. If you misspell your identifiers, someone else will have to remember (or look up) not only what the name is, but also how exactly it is misspelled. This takes time and breaks the programming flow; and since most code gets touched more than once in maintenance, each spelling error causes a whole lot of interruptions.
Consider how developer time equals salary equals expenses, I think it should be easy enough to make a case of this; after all, breaking the flow and getting back into it can take up to 15 minutes. This way, a severe spelling error can easily cost a few hundred dollars in further development and maintenance (but they're indirect costs, not directly visible in estimates and evaluations, so they often get ignored by management).