const string relativeUrl = "/a/b/c"; is caught by rule S1075 Refactor your code not to use hardcoded absolute paths or URIs. the string is a relative URI not an absolute one.
Create a const variable as follows
const string relativeUrl = "/a/b/c";
It should not break any rules.
It fails rule S1075 Refactor your code not to use hardcoded absolute paths or URIs
Give the constant a name that doesn't include the strings URL or Path
Same issue... Following this to check the fix.
Thanks
I get this issue too even with a constant without URL or Path in its name.
@coder2000 do you ever pass that constant to a variable or method parameter that has URL or Path in it?
No. It is an xml namespace.
On Sun, Jan 27, 2019, 2:51 PM Martin Brown, notifications@github.com
wrote:
@coder2000 https://github.com/coder2000 do you ever pass that constant
to a variable or method parameter that has URL or Path in it?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SonarSource/sonar-dotnet/issues/1865#issuecomment-457953119,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABtKHKV4M6kYPulsUZ6Q7poHdmYHH9Vks5vHhFUgaJpZM4WwhB0
.
I got this issue too.
To remove this, I changed my relative url from "a/b/c" to "a\b\c".
Hi @martingbrown and thanks for the report.
By design, we are raising an issue when we'll notice a "/a/b/c" URI, because it looks like an OS (unix) absolute URI. The rationale is written in the rule description. In any case, we're going to think about a way to reduce the number of FPs in this case.
I agree with @jeanfuck that if "a/b/c" should not raise (it's clearly a relative URI), but I could not reproduce this FP. In my test case
string relativeUrl = "scripts/relative.js"; // Ok, no issue
string relativeUrl2 = "/scripts/relative.js"; // Noncompliant
We decided to ignore unix-like paths for this rule, as it indeed generates FPs (as there's no easy way to understand if it's an absolute OS path or a relative path). Maybe with a parameter allow unix which would be false by default.
I have a question for the community. I did a few tweaks and wanted to know the behavior.
public static final String path = "/resource/abc"; // Refactor your code to get this URI from a customizable parameter.
However, if you use -
public static final String PATH_DELIMITER = "/";
public static final String ABC_BASEPATH = PATH_DELIMITER.concat("resources/abc"); //works fine.
I understand that the variable is assigned to the next String at run time but when I used this -
public static final String ABC_BASEPATH = "/" + "resources/abc"; //works fine.
I understand + or concat feature. But, this is also wrong as we have still not used any customizable parameter and it is still like hardcoded value. Shouldn't this throw an error too?
Can Sonar load the constants in its memory and apply some basic compilation methods to check if it is still the same? I think if we have not done what Sonar is asking us to do (Refactor the code to get this URI from a customizable parameter) it is still wrong to use any other tweak.
What are your views?
Hi @rohitraj436. If you want some input from the community, it might be better to open a thread in the community forum and reference this ticket from there.
Most helpful comment
I have a question for the community. I did a few tweaks and wanted to know the behavior.
public static final String path = "/resource/abc"; // Refactor your code to get this URI from a customizable parameter.
However, if you use -
public static final String PATH_DELIMITER = "/";
public static final String ABC_BASEPATH = PATH_DELIMITER.concat("resources/abc"); //works fine.
I understand that the variable is assigned to the next String at run time but when I used this -
public static final String ABC_BASEPATH = "/" + "resources/abc"; //works fine.
I understand + or concat feature. But, this is also wrong as we have still not used any customizable parameter and it is still like hardcoded value. Shouldn't this throw an error too?
Can Sonar load the constants in its memory and apply some basic compilation methods to check if it is still the same? I think if we have not done what Sonar is asking us to do (Refactor the code to get this URI from a customizable parameter) it is still wrong to use any other tweak.
What are your views?