1

For example, I know in c++, I can use

myString=="abc"

to check if 2 strings are equal. However, in Java, it is comparing if 2 objects are the same object. Also in other language, for example, javascript, I should use myString==="abc" instead.

In my current environment, I may switch between c++ and Java frequently, and I can't choose the language to use (eg:Java for Android, c++ for iOS). I afraid I would write stringA == stringB accidentally when switching from c++ to Java (or other languages).

So my question is, is avoiding misusing "==" in other languages a valid reason to avoid writing

myString=="abc" 

in c++ (ie:only use myString.compare("abc") ==0 )?

I'm not trying to drop unique features of a language, there may some related questions looks similar to my question:

Should we avoid language features that C++ has but Java doesn't?

Why is it bad to write something in language X as if you're writing a program in language Y in terms of using a shared coding paradigm

,but I believe my intent is different in my view : those questions seems try to drop unique features of a language, but I would keep c++ unique features (i.e.:I would use multiple inheritance if necessary), oppositely I'm trying to drop similar syntax but with different effects among other languages.

3 Answers3

12

By the reasoning that similar syntax behaves differently in C++ and Java, you should also forbid the use of new in both your C++ and your Java code. Because you might just call new in C++ and forget the corresponding call to delete.

But if you forbid the use of new on both sides, it becomes effectively impossible to write a Java program of any size. And there are so many subtle differences between the languages that regulating them all means that you just can't really write any programs any more, or at the very least not in an idiomatic way. For example, did you also consider the subtle differences in integer sizes and overflow rules?


When writing a coding guide, don't look at how other languages work but try to codify idiomatic usage and best practices of the language for which you write the coding guide.

Only when it comes to guidelines for the logical structure (use of classes, nested classes, number of classes per file, order of variables, functions, members, etc.) of the code does it make sense to look at other languages used by the teams, to see if there is an advantage in giving the code in different languages a similar structure.

3

If you always work alone for yourself, it does not matter - and you definitely don't have to ask strangers from the internet about such stylistic issues.

But if you work in a team, maybe in a team where you expect some staff changes from time to time, better try to write your code in a way your C++ specialists and your Java specialists will not fire tons of WTFs at you at the next code review. And code like myString.compare("abc") ==0 will make a C++ guy think, "WTF, did the author not understand that string comparison in C++ works differently than in Java?".

Even if you don't work in a larger team for now, you are not working in an ivory tower. You will have to read, include or discuss code from other C++ and Java devs (for example, certain open source snippets). Hence, it is best getting used to their "standard" way of doing things. You don't want to isolate yourself by sticking to some convention which will definitely look weird for people trained in either of those languages.

Doc Brown
  • 218,378
0

I'll suggest a Frame Challenge. If you do make that mistake of using "==" in Java, then surely your testing will catch it?

There are many different ways that you can make mistakes while coding that include things like what you are worried about as well as other subtle things (like using the wrong variable etc).

The point being that testing your code is supposed to help identify such mistakes by questioning the assumptions you have made about how your code behaves. If you make a gross error in Java by mixing up string comparisons, then that is the sort of thing that testing should be helping you find.

Peter M
  • 2,097