invert if : visual studio code helper
-
Writing a simple console app. I wrote this to insure there is at least one argument provided by user.
if (args.Length < 1){
Console.WriteLine("Need at least one arg.");
return;
}Interesting thing is that Visual Studio Code has these little helpers that pop up at various times which state [Show fixes]. This one says, "invert if"[^]. If you click, it changes the code to:
if (args.Length >= 1){
return;
}
Console.WriteLine("Need at least one arg.");
return;Do you find that clearer? I don't. In my case, the if statement occurs at the top and if it is not fulfilled then the app exits. In that case there is no need to think about other code. Plus, the code that executes normally will not be wrapped in any outer if statement, instead it will simply following the if statement in a normal reading flow. Inverted Case In the inverted if then when there is at least one argument then all of your base code is now wrapped in the if statement and you have to think backwards. It's weird. AI you have failed me. :|
-
Writing a simple console app. I wrote this to insure there is at least one argument provided by user.
if (args.Length < 1){
Console.WriteLine("Need at least one arg.");
return;
}Interesting thing is that Visual Studio Code has these little helpers that pop up at various times which state [Show fixes]. This one says, "invert if"[^]. If you click, it changes the code to:
if (args.Length >= 1){
return;
}
Console.WriteLine("Need at least one arg.");
return;Do you find that clearer? I don't. In my case, the if statement occurs at the top and if it is not fulfilled then the app exits. In that case there is no need to think about other code. Plus, the code that executes normally will not be wrapped in any outer if statement, instead it will simply following the if statement in a normal reading flow. Inverted Case In the inverted if then when there is at least one argument then all of your base code is now wrapped in the if statement and you have to think backwards. It's weird. AI you have failed me. :|
I use yoda conditionals all the time (due to cutting my teeth on C++ back before the compiler was smart enough to warn on accidental assignment). I stuck with it due to the fact that it's a habit I spent so long at that it would take me at least as long to unlearn. At least I'm consistent about it. So I can see it being at least a little bit helpful sometimes for a confusing condition, but that's me.
Real programmers use butterflies
-
Writing a simple console app. I wrote this to insure there is at least one argument provided by user.
if (args.Length < 1){
Console.WriteLine("Need at least one arg.");
return;
}Interesting thing is that Visual Studio Code has these little helpers that pop up at various times which state [Show fixes]. This one says, "invert if"[^]. If you click, it changes the code to:
if (args.Length >= 1){
return;
}
Console.WriteLine("Need at least one arg.");
return;Do you find that clearer? I don't. In my case, the if statement occurs at the top and if it is not fulfilled then the app exits. In that case there is no need to think about other code. Plus, the code that executes normally will not be wrapped in any outer if statement, instead it will simply following the if statement in a normal reading flow. Inverted Case In the inverted if then when there is at least one argument then all of your base code is now wrapped in the if statement and you have to think backwards. It's weird. AI you have failed me. :|
They are hints. (resharper C++ also do that) Sometimes they work, sometimes they don't. In that case, it is not useful
I'd rather be phishing!
-
I use yoda conditionals all the time (due to cutting my teeth on C++ back before the compiler was smart enough to warn on accidental assignment). I stuck with it due to the fact that it's a habit I spent so long at that it would take me at least as long to unlearn. At least I'm consistent about it. So I can see it being at least a little bit helpful sometimes for a confusing condition, but that's me.
Real programmers use butterflies
-
They are hints. (resharper C++ also do that) Sometimes they work, sometimes they don't. In that case, it is not useful
I'd rather be phishing!
Maximilien wrote:
They are hints.
I agree. Just suggestions. :thumbsup:
Maximilien wrote:
In that case, it is not useful
Thanks for the confirmation. That's what I thought, but was wondering if I missed something. :thumbsup: Also, it really is just a matter of opinion on this one since either would work.
-
Writing a simple console app. I wrote this to insure there is at least one argument provided by user.
if (args.Length < 1){
Console.WriteLine("Need at least one arg.");
return;
}Interesting thing is that Visual Studio Code has these little helpers that pop up at various times which state [Show fixes]. This one says, "invert if"[^]. If you click, it changes the code to:
if (args.Length >= 1){
return;
}
Console.WriteLine("Need at least one arg.");
return;Do you find that clearer? I don't. In my case, the if statement occurs at the top and if it is not fulfilled then the app exits. In that case there is no need to think about other code. Plus, the code that executes normally will not be wrapped in any outer if statement, instead it will simply following the if statement in a normal reading flow. Inverted Case In the inverted if then when there is at least one argument then all of your base code is now wrapped in the if statement and you have to think backwards. It's weird. AI you have failed me. :|
raddevus wrote:
AI you have failed me.
Problem found. :rolleyes: BTW... I am with you in this case.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
honey the codewitch wrote:
I use yoda conditionals all the time
Haven't heard that term before, but seems to apply, it does. :rolleyes:
This is not a true case of yoda conditionals or at least not in the sense I've heard the term. For me, yoda conditionals are written like:
if (1 >= args.Length)
{
Console.Write ("Not enough arguments");
return;
}The inversion refers to the order of terms in the if and the reason for it is that a construct like:
if (1 = args.Length)
(note the missing equal sign) will get you slapped with a big fat error message ('1' is not a l-value). The "normal" order might or might not produce a warning depending on compiler's whims. In your case it's just a case of compiler being annoying. Sometime I feel it's becoming almost like Clippy: "It seems you want to write an if statemenet. Do you need help with that?". Here is a random example taken straight out of some code:
assert (str);
while (*str > 0 && *str <= ' ')
str++;And it flags the while statement with an IntelliSense warning: "Dereferencing NULL pointer". Heck no! That's why I put the assert right before it.
Mircea
-
raddevus wrote:
AI you have failed me.
Problem found. :rolleyes: BTW... I am with you in this case.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Writing a simple console app. I wrote this to insure there is at least one argument provided by user.
if (args.Length < 1){
Console.WriteLine("Need at least one arg.");
return;
}Interesting thing is that Visual Studio Code has these little helpers that pop up at various times which state [Show fixes]. This one says, "invert if"[^]. If you click, it changes the code to:
if (args.Length >= 1){
return;
}
Console.WriteLine("Need at least one arg.");
return;Do you find that clearer? I don't. In my case, the if statement occurs at the top and if it is not fulfilled then the app exits. In that case there is no need to think about other code. Plus, the code that executes normally will not be wrapped in any outer if statement, instead it will simply following the if statement in a normal reading flow. Inverted Case In the inverted if then when there is at least one argument then all of your base code is now wrapped in the if statement and you have to think backwards. It's weird. AI you have failed me. :|
I'm curious if this error still pops up if you write more code below the if statement. I've never seen this before. My initial hunch is it might think you're doing the "if-good-else-bad" pattern since the only active code is in the if statement currently, and trying to move it around to the "early-exit/pre-condition" pattern which I personally do think is way cleaner. Or it may be attempting some pointless hyper-optimization? :doh:
-
I'm curious if this error still pops up if you write more code below the if statement. I've never seen this before. My initial hunch is it might think you're doing the "if-good-else-bad" pattern since the only active code is in the if statement currently, and trying to move it around to the "early-exit/pre-condition" pattern which I personally do think is way cleaner. Or it may be attempting some pointless hyper-optimization? :doh:
Jon McKee wrote:
I'm curious if this error still pops up if you write more code below the if statement.
That's a very good question. Here's the updated code that contains more code now. Note: this is simple code that is going in a book.
static void Main(string[] args)
{
if (args.Length < 1){
Console.WriteLine("Please provide 1 argument to indicate the command you want to run.\nUsage: getInfo ");
return;
}switch (args\[0\].ToLower()){ case "os":{ Console.WriteLine($"OS : {Environment.OSVersion}"); break; } case "pwd":{ Console.WriteLine($"The current directory is: {Environment.CurrentDirectory}"); break; } case "cl":{ Console.WriteLine($"Command line was: {Environment.CommandLine}"); break; } case "sysdir":{ Console.WriteLine($"System dir: {Environment.SystemDirectory}"); break; } case "mname":{ Console.WriteLine($"Machine name: {Environment.MachineName}"); break; } } }Here's a snapshot of the invert if[^] that still shows up in VSC as a hint. Here's the code you get if you invert now:
static void Main(string[] args)
{
if (args.Length >= 1)
{
switch (args[0].ToLower())
{
case "os":
{
Console.WriteLine($"OS : {Environment.OSVersion}");
break;
}
case "pwd":
{
Console.WriteLine($"The current directory is: {Environment.CurrentDirectory}");
break;
}
case "cl":
{
Console.WriteLine($"Command line was: {Environment.CommandLine}");
break;
} -
Jon McKee wrote:
I'm curious if this error still pops up if you write more code below the if statement.
That's a very good question. Here's the updated code that contains more code now. Note: this is simple code that is going in a book.
static void Main(string[] args)
{
if (args.Length < 1){
Console.WriteLine("Please provide 1 argument to indicate the command you want to run.\nUsage: getInfo ");
return;
}switch (args\[0\].ToLower()){ case "os":{ Console.WriteLine($"OS : {Environment.OSVersion}"); break; } case "pwd":{ Console.WriteLine($"The current directory is: {Environment.CurrentDirectory}"); break; } case "cl":{ Console.WriteLine($"Command line was: {Environment.CommandLine}"); break; } case "sysdir":{ Console.WriteLine($"System dir: {Environment.SystemDirectory}"); break; } case "mname":{ Console.WriteLine($"Machine name: {Environment.MachineName}"); break; } } }Here's a snapshot of the invert if[^] that still shows up in VSC as a hint. Here's the code you get if you invert now:
static void Main(string[] args)
{
if (args.Length >= 1)
{
switch (args[0].ToLower())
{
case "os":
{
Console.WriteLine($"OS : {Environment.OSVersion}");
break;
}
case "pwd":
{
Console.WriteLine($"The current directory is: {Environment.CurrentDirectory}");
break;
}
case "cl":
{
Console.WriteLine($"Command line was: {Environment.CommandLine}");
break;
}That's so bizarre. It seems like the purpose of this rule (from some short googling) is to reduce conditional nesting and/or cyclomatic complexity. But in this example it actually increases nesting by changing away from an early-exit guard clause and doesn't change the CC at all. It's like it's doing the exact opposite of what it should be doing :doh:
-
That's so bizarre. It seems like the purpose of this rule (from some short googling) is to reduce conditional nesting and/or cyclomatic complexity. But in this example it actually increases nesting by changing away from an early-exit guard clause and doesn't change the CC at all. It's like it's doing the exact opposite of what it should be doing :doh:
Jon McKee wrote:
seems like the purpose of this rule (from some short googling) is to reduce conditional nesting and/or cyclomatic complexity.
Thanks for researching that and confirming that you find it odd too. And for putting some data behind it. I really thought it was strange but hadn't defined why very well. Great info.:thumbsup:
-
This is not a true case of yoda conditionals or at least not in the sense I've heard the term. For me, yoda conditionals are written like:
if (1 >= args.Length)
{
Console.Write ("Not enough arguments");
return;
}The inversion refers to the order of terms in the if and the reason for it is that a construct like:
if (1 = args.Length)
(note the missing equal sign) will get you slapped with a big fat error message ('1' is not a l-value). The "normal" order might or might not produce a warning depending on compiler's whims. In your case it's just a case of compiler being annoying. Sometime I feel it's becoming almost like Clippy: "It seems you want to write an if statemenet. Do you need help with that?". Here is a random example taken straight out of some code:
assert (str);
while (*str > 0 && *str <= ' ')
str++;And it flags the while statement with an IntelliSense warning: "Dereferencing NULL pointer". Heck no! That's why I put the assert right before it.
Mircea
I use the "first the constant" rule (I didn't know it was called "yoda conditionals", nice name hehehe) in comparisons for equality. But for greater / lower than I don't use it for readability.I find it easier to read when it is "
var <= value" than "value >= var" in acheck_lower_limit()Same thing I try to make my conditions to be read as if (true) I mean, I don't like "if (!var)", I prefer to write "if (false == var)" this way is 100% clear on the first sight. Or naming the variables in a way that they meaning is "true". This is something that comes from working in industry PLCs. I have had sensors called "part_exist" where the "1" was meaning "empty" (security against cable breaks), to look an "if (part_exist_x == true) PutPartInPlace(x);" X| X| X| I always renamed such sensors to follow the rule "name means true" so that the same condition check as above would read "if (place_empty_x == true) PutPartInPlace(x);" Just personal taste...M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Writing a simple console app. I wrote this to insure there is at least one argument provided by user.
if (args.Length < 1){
Console.WriteLine("Need at least one arg.");
return;
}Interesting thing is that Visual Studio Code has these little helpers that pop up at various times which state [Show fixes]. This one says, "invert if"[^]. If you click, it changes the code to:
if (args.Length >= 1){
return;
}
Console.WriteLine("Need at least one arg.");
return;Do you find that clearer? I don't. In my case, the if statement occurs at the top and if it is not fulfilled then the app exits. In that case there is no need to think about other code. Plus, the code that executes normally will not be wrapped in any outer if statement, instead it will simply following the if statement in a normal reading flow. Inverted Case In the inverted if then when there is at least one argument then all of your base code is now wrapped in the if statement and you have to think backwards. It's weird. AI you have failed me. :|
That's a tool, not even a suggestion. And tools might be used when they are useful. So: when? E.g. you decided to add an
elseclause, and you prefer the order the other way round. E.g. you have both the normal and the else clause, and decide the other way round looks better. Then, the new code is just a mouse click away. A tool. To be used when appropriate. Not: Here's a hammer. Now you have to use it, even when there's no nail.Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
That's a tool, not even a suggestion. And tools might be used when they are useful. So: when? E.g. you decided to add an
elseclause, and you prefer the order the other way round. E.g. you have both the normal and the else clause, and decide the other way round looks better. Then, the new code is just a mouse click away. A tool. To be used when appropriate. Not: Here's a hammer. Now you have to use it, even when there's no nail.Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
Bernhard Hiller wrote:
Here's a hammer. Now you have to use it, even when there's no nail.
But if you only have a hammer... would not come the moment when all what you see is a nail? :rolleyes: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Jon McKee wrote:
I'm curious if this error still pops up if you write more code below the if statement.
That's a very good question. Here's the updated code that contains more code now. Note: this is simple code that is going in a book.
static void Main(string[] args)
{
if (args.Length < 1){
Console.WriteLine("Please provide 1 argument to indicate the command you want to run.\nUsage: getInfo ");
return;
}switch (args\[0\].ToLower()){ case "os":{ Console.WriteLine($"OS : {Environment.OSVersion}"); break; } case "pwd":{ Console.WriteLine($"The current directory is: {Environment.CurrentDirectory}"); break; } case "cl":{ Console.WriteLine($"Command line was: {Environment.CommandLine}"); break; } case "sysdir":{ Console.WriteLine($"System dir: {Environment.SystemDirectory}"); break; } case "mname":{ Console.WriteLine($"Machine name: {Environment.MachineName}"); break; } } }Here's a snapshot of the invert if[^] that still shows up in VSC as a hint. Here's the code you get if you invert now:
static void Main(string[] args)
{
if (args.Length >= 1)
{
switch (args[0].ToLower())
{
case "os":
{
Console.WriteLine($"OS : {Environment.OSVersion}");
break;
}
case "pwd":
{
Console.WriteLine($"The current directory is: {Environment.CurrentDirectory}");
break;
}
case "cl":
{
Console.WriteLine($"Command line was: {Environment.CommandLine}");
break;
}I don't like the
args.Length < 1test - it's either going to be greater than or equal to1, or equal to0. Just for fun, you could also introduce some C# 8 into the mix, and support multiple commands:static void Main(string[] args)
{
if (args.Length == 0)
{
Console.WriteLine("Please provide 1 argument to indicate the command you want to run.\nUsage: getInfo ");
return;
}foreach (string arg in args) { Console.WriteLine(arg.ToLowerInvariant() switch { "os" => $"OS : {Environment.OSVersion}", "pwd" => $"The current directory is: {Environment.CurrentDirectory}", "cl" => $"Command line was: {Environment.CommandLine}", "sysdir" => $"System dir: {Environment.SystemDirectory}", "mname" => $"Machine name: {Environment.MachineName}", \_ => $"Unknown command: '{arg}'", }); }}
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
That's a tool, not even a suggestion. And tools might be used when they are useful. So: when? E.g. you decided to add an
elseclause, and you prefer the order the other way round. E.g. you have both the normal and the else clause, and decide the other way round looks better. Then, the new code is just a mouse click away. A tool. To be used when appropriate. Not: Here's a hammer. Now you have to use it, even when there's no nail.Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
I agree. It's just that any time a tool attempts to have some "intelligence" about it then you begin to think it may have more context to the situation. But, this probably really is more like pop up code snippets and you take them or leave them. Also, because it has the initial pop up that states, "Show fixes (Ctrl+.)" it leads you to believe that something is wrong.
-
I don't like the
args.Length < 1test - it's either going to be greater than or equal to1, or equal to0. Just for fun, you could also introduce some C# 8 into the mix, and support multiple commands:static void Main(string[] args)
{
if (args.Length == 0)
{
Console.WriteLine("Please provide 1 argument to indicate the command you want to run.\nUsage: getInfo ");
return;
}foreach (string arg in args) { Console.WriteLine(arg.ToLowerInvariant() switch { "os" => $"OS : {Environment.OSVersion}", "pwd" => $"The current directory is: {Environment.CurrentDirectory}", "cl" => $"Command line was: {Environment.CommandLine}", "sysdir" => $"System dir: {Environment.SystemDirectory}", "mname" => $"Machine name: {Environment.MachineName}", \_ => $"Unknown command: '{arg}'", }); }}
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
I don't like the
args.Length < 1testYeah, admittedly this is just shorthand for "I only want to know if it is 0" otherwise keep on running. I talk about that in relation to the code however -- since this is really just part of a beginning code sample that is part of a larger context of explaining how to get arguments from command-line. I talk about this being a cheat that will simply ignore any arguments that are after the first one. This is all part of a book (Programming Linux With .NET Core) and part of the beginning stages of teaching an early beginner. The foreach code is a really good example of things that will come in later explanations and is much more elegant. Thanks
-
Writing a simple console app. I wrote this to insure there is at least one argument provided by user.
if (args.Length < 1){
Console.WriteLine("Need at least one arg.");
return;
}Interesting thing is that Visual Studio Code has these little helpers that pop up at various times which state [Show fixes]. This one says, "invert if"[^]. If you click, it changes the code to:
if (args.Length >= 1){
return;
}
Console.WriteLine("Need at least one arg.");
return;Do you find that clearer? I don't. In my case, the if statement occurs at the top and if it is not fulfilled then the app exits. In that case there is no need to think about other code. Plus, the code that executes normally will not be wrapped in any outer if statement, instead it will simply following the if statement in a normal reading flow. Inverted Case In the inverted if then when there is at least one argument then all of your base code is now wrapped in the if statement and you have to think backwards. It's weird. AI you have failed me. :|
-
Writing a simple console app. I wrote this to insure there is at least one argument provided by user.
if (args.Length < 1){
Console.WriteLine("Need at least one arg.");
return;
}Interesting thing is that Visual Studio Code has these little helpers that pop up at various times which state [Show fixes]. This one says, "invert if"[^]. If you click, it changes the code to:
if (args.Length >= 1){
return;
}
Console.WriteLine("Need at least one arg.");
return;Do you find that clearer? I don't. In my case, the if statement occurs at the top and if it is not fulfilled then the app exits. In that case there is no need to think about other code. Plus, the code that executes normally will not be wrapped in any outer if statement, instead it will simply following the if statement in a normal reading flow. Inverted Case In the inverted if then when there is at least one argument then all of your base code is now wrapped in the if statement and you have to think backwards. It's weird. AI you have failed me. :|
One possibility is that this is a performance suggestion. Because of pre-fetching, many CPUs perform better when the non-jump case is taken. If the tool is guessing that the non-jump case is actually the rare one, it might be making the suggestion on those grounds. My guess is not, but I wanted to mention it. I worked on a product where the tags and could be used to tag code paths to assist the compiler with optimization. We had customers who would raise hell if a release slowed down by more than 1%-2%, despite all their feature requests, so tagging frequently invoked functions this way alleviated some of the performance degradation.
Robust Services Core | Software Techniques for Lemmings | Articles
