Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StringLiteralsConcatenationCheck justification is partly self-contradictory and mostly not valid #941

Open
golszewski86 opened this issue Nov 21, 2018 · 2 comments

Comments

@golszewski86
Copy link

golszewski86 commented Nov 21, 2018

StringLiteralsConcatenationCheck gives two reasons why it is prohibited to use String concatenation using + operator:

You should avoid string concatenation at all cost. Why? There are two reasons: readability of the code and translateability. First of all it's difficult to understand how the text will look after concatenation, especially if the text is long and there are more than a few + operators. Second, you won't be able to translate your text to other languages later, if you don't have solid string literals.

There are two alternatives to concatenation: StringBuilder and String#format(String,Object[]).

The first argument is that it's difficult to understand how the text will look after concatenation. Really? What's difficult to understand in the following piece of code:

throw new IllegalArgumentException("Type not supported: " + type);

StringBuilder or String.format are the suggested alternatives so we can write instead:

throw new IllegalArgumentException(new StringBuilder("Type not supported: ").append(type).toString());
throw new IllegalArgumentException(String.format("Type not supported: %s", type));

Is it easier to understand how the text will look after concatenation? Definitely not.

The second argument is that I won't be able to translate my application to another language. This may or may not be true, depending on i18n solution/framework. But StringBuilder and String.format suggested as alternatives will give exactly the same effect so it's self-contradictory to present them as alternatives to the + operator.
Also not every application needs translation, and even in internationalized application not every part/module uses translation. There's no reason to impose i18n constraints on all application just because some of them may use i18n.

Given that, StringLiteralsConcatenationCheck has no valid justification and should be removed or possible to disable on project level, unless valid justification is given.

@0crat
Copy link
Collaborator

0crat commented Nov 21, 2018

@krzyk/z please, pay attention to this issue

@0crat
Copy link
Collaborator

0crat commented Nov 21, 2018

@golszewski86/z this project will fix the problem faster if you donate a few dollars to it; just click here and pay via Stripe, it's very fast, convenient and appreciated; thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants