Yes, I have lots of form elements to make settings for. Thus it's a ton of time to scroll thru it all. Thus I've put in place { }'s in order to be able to condense those blocks so I can focus on what I'm working on without wearing out my mouse scroll wheel.
Use comments to visually break up sections, not needlessly nested code blocks. If you need to force a foldable section around a block of code, use regions. The GUI inline function which I built for my AVCS SENS profile is nearly 5000 lines long, including somewhere around 15 form pages (classes), and I use comments to help visually break up these items, and folding to be able to scroll through these various pages easily, expanding just the section I am working on by clicking the little "+" symbol next to that folded section. If you're interested, you can check out this extremely long inline function on my pastebin - it was a challenge to myself to make a complex WinForm in a single inline, and while I wouldn't do it like this again, I met and achieved that challenge & have a working GUI that would be a pain in the neck to edit or refactor so much that I'd likely redesign it as a plugin if I ever had to return to it.
https://pastebin.com/8a1NFRDpJust because we can do something doesn't necessarily mean it is a good way to do it.It may not be possible for you yet, but as you learn you should begin to be aware of nesting and begin to attempt keeping it to 3 or less. This means entering new method, and you add an "if" statement, the contents of it will be the first nested level - adding yet another if-statement inside that would mean its contents would be at the second nested level, and so on to the third. At this point, you will have an end of this method which may look like this:
}
}
}
}
...any more than this, and the task of visually reviewing code and attempting to expand or even troubleshoot various blocks of code and various methods can become quite cumbersome and unwieldy. Avoid excessive nesting with guard clauses and early returns, use private helper methods, and generally limit the structures of any single method to avoid going much farther than 3 levels of nesting in a method.
For example (this is a nonsensical code bit just to demo the concept above, using TABs only to better illustrate it):
private void MyMethod(bool? myBool)
{
if (myBool != null)
{
VA.SetBoolean("MyBoolVar", myBool);
if (VA.GetText("SomeVar") != null)
{
int index = 0;
string[] someVars = VA.GetText("SomeVar").Split(',');
foreach (string vars in someVars)
{
if (!String.IsNullOrEmpty(vars))
{
index++;
VA.SetText("ExampleVar" + index.ToString(), vars);
if (index >= 23)
{
break;
}
}
}
}
}
}
By using guard clauses and early returns, and a slightly different structure, we can make it much easier to read and follow, eliminating deeply nested code for greater maintainability in development, testing, and troubleshooting:
private void MyMethod(bool? myBool)
{
if (myBool == null)
{
return;
}
VA.SetBoolean("MyBoolVar", myBool);
if (VA.GetText("SomeVar") == null)
{
return;
}
int index = 0;
string[] someVars = VA.GetText("SomeVar").Split(',');
foreach (string vars in someVars)
{
if (String.IsNullOrEmpty(vars))
{
continue;
}
index++;
VA.SetText("ExampleVar" + index.ToString(), vars);
if (index >= 23)
{
break;
}
}
}
Notice how much easier it is to read and potentially modify the second example versus the first. Try to be aware of these things as you study, learn, and practice, and you'll save yourself a lot of eye-strain and headaches when reviewing and developing your code. When you run into barriers, remember to ask yourself, "Do I really need to do this?" -OR- "Do I really need to do this in THIS way?" -OR- "Can I do this in a more straightforward and simple manner?"
In summary, nested is to be avoided where possible to make code easier to read, maintain, modify, test, and/or troubleshoot.Best wishes and keep up the hard work - it's totally worth it!!
Topic: Return Filepath & Filename to Calling Form's Textbox (Read 4245 times)
VoiceAttack User Forums