If you have code that is never reached because it’s after a return statement, studio will put a red underline under all the code after the return statement. It would be better to dim the code after the return statement instead
I will sometimes put return statements in the middle of a function to be able to test something, the code after the return statement is not invalid it is just never reached. It should be dimmed not underlined red
VSCode
Roblox Studio
I’m kind of 50-50 on this, on one hand sometimes I put a return at the top of a function when debugging, and the outline is just annoying, but on the other I don’t want to be debugging for so long only to realize that it was because of a return in some random piece of code that just didn’t catch my eye.
I think that’s why he suggests dimming the rest of it - it would still clearly show where the last running line of code is so there’s a clear visual indicator that a return is blocking half of the function.
Another alternative would be to just mark the lines of code after the return in blue as not doing anything. I’ve found this rather annoying when I’m debugging as well and it would be nice to have some sort of system that doesn’t force an error, but attempts to point out what may be a logic flaw.
For me personally it doesn’t look that obvious, but what can I say. I have never made the mistake I described, it was just the hypothetical situation that came into my head, so I could just be thinking too deep into this.
I agree the example image he gave doesn’t look the clearest, but then they can just make it more transparent or do the blue underline thing until it’s the right amount of obvious.
I don’t see a problem with the statement. The code is unreachable, essentially making it useless code - not to mention your default return argument should be an argument your code expects to handle.
Just because VSCode’s system does not flag it during inspection does not make the point any less valid - in high level coding breakpoints exist to allow for the inspection of code whilst running at different parts of the process. I wouldn’t say your methodology of how you like to test things should mean this feature is defined as unneeded.
The point the inspection is making is that the code is unreachable, meaning frankly it is a waste of time for the compiler. Whilst for you it might be the case you are testing something in order cases people might not have realised important code is not going to be run.
As an example, put yourself in the shoes of an amateur VSCoder who isn’t use to a return statement: your later code under ‘Handle’ will never be run - if this code was extremely important the feature could act as a flag saying “maybe you should look at this”. With Lua being a friendly scripting language, these semantics only exist to improve user experience and improving code in general.
I’m not saying don’t flag it - ideally a solution would be as obvious as it currently is. I’m just saying don’t break the entire program because it’s there. It should clearly mark that the code won’t run, but it shouldn’t error the entire script because that code isn’t being run.
Similarly ‘waste of time for the compiler’ includes things like comments, which one nanosecond for the compiler doesn’t matter. The current solution is to comment out the lines of code which is equally a waste of time for the compiler. I personally don’t care about how long it takes the compiler to do things either way because it’s not executing that code and it’s typically 5 lines out of thousands.
Lastly, while breakpoints allow inspecting code, it doesn’t let me test how scripts run under different inputs. If I’m running a function as a blackbox and just have it temporarily return true to see what another function does when it gets a true value, I can’t just throw in a breakpoint to do that.
The line is orange, which doesn’t signify an error to begin with? Frankly it exists to tell you theirs a fault with your logic which it doesn’t agree with. In some cases this fault can be fatal, but the compiler can still compile.
A red line signifies a compilation error, an orange line signifies an error that can occur during runtime.
Comments are also removed during compilation, which is why you should make comments in --ThisFormat as then they get removed.
None of your cases are what we’re talking about.
This is about having code after a return value, but before the end statement. This will automatically error.
*Edit - just looked back at the top post, and I’ve been talking about his first image. The first image will result in an error. His second image is fine and shouldn’t be fixed because it’s just a warning.
I am just talking about changing the style of the warning from a red underline to dimmed text. The underline makes the code look like it has an error when I am just wanting to ignore the code after the return statement for testing reasons.
When they are side by side you can tell the difference, but the orange line alone looks like an error line
Agree on this, marking it as an error is incorrect in most cases and assumes a mistake which is noisy and annoying as a programmer. Dimming the text or even just making it all grey would be better.
I second this post; It’s very hard to tell the difference between the colors of the error line, and a warning line.
I’m almost unable to see the difference between the two lines, and by default, I don’t know which one would count as an error, because the two of them look extremely identical.
Some more visual warning in the IDE for this issue would be nice. Specifically for the return statement, because that also can be a little confusing too (and doesn’t make much sense highlighting every line impacted by the return).
Dimming the text is much better. That’s just my two cents.
I think by reviewing the comments of this thread I believe a simple solution would be:
This would reduce confusion and help with the colour disparity because I can, in a sense, see your point.
On my monitor the colours are quite obviously distinct, but then my monitor also uses HDR to boost colours.
The point is to make the editor look less cluttered, adding a new icon along with the underline defeats the purpose. There is no need for a symbol, dimming the text and removing the underline is a better solution
Well the underline is to symbolise which part is the problem, if you have multiple lines of code on a single line, then obviously its covered - less of a common use case, but still a use case.
This is a valid lint warning, and you should never have to write code like this. Greying out unreached lines is unintuitive and could be impairing for newbies to understand, while the current behavior is descriptive about the problem.
If you really want to remove this, just add the --!nolint UnreachableCode header to the top of your file.
But why? There’s no reason to write code that will never be used. This just seems more of a bad practice.
Somebody may want this just to quickly test what happens if some code doesn’t run. So put they quickly put a return there. The code below would count as a syntax error due to the return. It takes all of 3 seconds to comment out the code though, so that’s why roblox probably won’t add this. It requires changing Lua syntax or the type checker and some bytecode handling for the scripts.
That requires scrolling multiple hundred lines of code and if that code is in a function, simply scrolling to the end of the script will not suffice, this is not a good solution.
Then use this:
if true then return end
print("Hello world!") -- No syntax error
Takes all of 2 seconds, this time.