Reputation: 957 Master
- Active Posts:
- 958 (0.82 per day)
- 30-September 10
- Profile Views:
- Last Active:
- 25 minutes ago
- Viewing Forum: Corner Cubicle
- OS Preference:
- Favorite Browser:
- Favorite Processor:
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
- Expert In:
19 Nov 2013 - 17:29
15 Nov 2013 - 07:01
14 Nov 2013 - 15:37
12 Nov 2013 - 18:09
04 Oct 2013 - 11:44
03 Oct 2013 - 17:38
02 Oct 2013 - 11:06
23 Sep 2013 - 06:46
08 Sep 2013 - 04:50
31 Aug 2013 - 11:30
Posts I've Made
Posted 4 Dec 2013Good list, Adam.
Here are some more tips that I often use. Some are more like best practices and common mistakes (in my opinion) than types of refactoring, to be honest, but many are still relevant I think.
* Before doing any significant refactoring, ensure the code in question has a good set of unit tests that can be used to verify its behavior. This not only helps to detect any regressions that creep in as a result of the refactoring, but writing a good set of unit tests requires you to thoroughly understand the code, which will allow you to make better decisions whilst refactoring. Further, for code that doesn't currently have any unit tests, writing the unit tests for the code will usually make any areas that could benefit from refactoring painfully obvious.
* Always try to leave any code you work on in a better state than what it was in when you started working on it. Even if you only make a tiny improvement like narrowing the scope of a local variable, small changes will start to add up quickly, and the overall quality of the system will start to improve.
* If you see a comment explaining a piece of code, think about whether it would be possible to extract the commented code into a well named method that equivalently explains the meaning of the code, and then delete the comment. Assuming the meaning of the code remains clearly explained, self documenting code is almost always preferable over commented code.
* Delete any commented out code. Invest in some good source control software, and rely on that instead of cluttering the code with huge chunks of commented out code.
* Look with suspicion upon any class that queries the state of another object, and then conditionally performs processing based on that state. Should that processing be moved into the class that has the property, and the property then removed? Remember, object oriented principles tell us to place the behavior as close to the data it uses as possible.
* Where applicable (particularly where null is used to represent an undefined value (nullable value types excluded)), consider replacing null checks (which, again, clutter the code, are easy to miss out) with a Null Object.
* Remove excessive exception handling code. Exception handling code clutters and complicates the code, and can end up masking serious problems or leaving the program in an unknown state. Note that by excessive, I mean there is either an unnecessarily rigorous use (or, indeed, misuse) of try-catch statements, or the catch blocks catch an exception type that is too general for it to be able to guarantee that it can handle the exception successfully (the classic case being catching Exception without re-throwing it. I personally find I don't use all that many try-catch statements (relatively speaking) in my code.
* Add code to throw an exception when invalid input is received, particularly through public members. I generally find ArgumentNullException, InvalidOperationException and similar are probably amongst the most common types of exceptions I throw from within my code.
Combine this with my previous point, and you might say "but that'll crash your application". To that I say, absolutely. And that's exactly what I would want to happen. If I get one of those types of exception, it means I've seriously screwed up, so I want to know about it as soon as possible. If you don't want it to crash your program, test your application properly, and ensure you don't pass any member a value that it cannot handle. Failing fast in such situations is usually preferable.
An important, and probably often unrecognized corollary to this theory is that excessive use of automatic properties is a sign that you haven't understood the concepts of encapsulation and protecting a class' invariants.
* Use guard clauses to get the least common case(es) out of the way at the start of a method (thus making the normal flow through the method clearer), as described by code_m. I'm always using this technique.
Posted 29 Oct 2013Just to give yet another alternative... Since a string is simply a sequence of characters (specifically, the String class implements IEnumerable(Of Char)), you can use the First() or FirstOrDefault() extension methods, provided you are targeting .NET Framework 3.5 or above.
Dim CaseLeftChar As Char = CaseLeft.FirstOrDefault()
Posted 3 Oct 2013A better way would be to make use of the various methods of the String class that take a StringComparison value as an argument, of which allows you to specify how the comparison is performed.
Dim s1 As String = "sentence" Dim s2 As String = "Sentence" Dim s3 As String = "This is a sentence." Dim areEqual As Boolean = String.Equals(s1, s2, StringComparison.OrdinalIgnoreCase) Dim contains As Boolean = s3.IndexOf(s2, StringComparison.OrdinalIgnoreCase) >= 0
Those methods avoid the unnecessary extra string allocations caused by calling ToUpper() or ToLower(), and are almost certainly faster. Plus, the StringComparison.OrdinalIgnoreCase argument helps avoid any culture sensitive issues surrounding string comparisons by making the comparison non-linguistic. I find that StringComparison.OrdinalIgnoreCase is most often a good choice, but see here and here for more information on what StringComparison value you should use in your program.
Posted 3 Oct 2013CodingSup3rnatur@l-360 a slight correction:
.Select(Function(chkBox) DirectCast(chkBox.Tag, TextBox).Text) ' should be .Select(Function(chkBox) DirectCast(Panel1.Controls(chkBox.Tag), TextBox).Text)
That won't compile with Option Strict On, and it'll fail at runtime with Option Strict Off, because there is no overload of the Control.ControlCollection class' indexer that can accept an argument of type Object
Posted 2 Oct 2013As has been mentioned, relying on control names in such a way is less than ideal, and is quite fragile.
You could instead use the Control.Tag property to associate the relevant text box with the correct check box. Something like:
However, because the check boxes and text boxes are obviously related, you would be better off enforcing that relationship explicitly by creating a user control for the check box-text box pair, as andrewsw hinted at earlier. That could look something like:
You could then perhaps take the final step of encapsulating a group of check box-text box pair controls in another user control, move all the code into that control, and expose a SelectedTexts property (or similar) that the form could use. At that point, you have a fully reusable control that handles itself nicely.
- Member Title:
- D.I.C Addict
- 21 years old
- June 11, 1992
- United Kingdom
Music - Led Zeppelin, Guns N' Roses, AC/DC
Software Development and Design
Watching Supernatural, The Big Bang Theory, The Walking Dead, Red Dwarf, QI, The Simpsons
Online gaming (Xbox 360).
- Full Name:
- Years Programming:
- Programming Languages:
- C#, a bit of Actionscript 3.0 ,SQL,Progress4GL, VB.NET. Learning Java, and Assembly/C/C++ when I can.
- Click here to e-mail me