In continuing with the ‘Refactorings for simplifying of the .NET 4.0 parallel computing development‘ thread, let’s review the additional refactoring for executing statements asynchronously called in the same manner – Execute Statement Asynchronously. The refactoring is available in two versions:
CodeRush Pro includes three refactorings that work with macros, aliases and typedef declarations in C++. Here they are:
This is just a quick overview list to organize a bunch of refactorings that deal with loops and blocks. Click the refactoring name to learn more about it.
This refactoring embeds a single statement into curly braces.
This refactoring combines several neighboring or nested using statements that cover variables of the same type into a single using statement.
It is a rather trivial task to iterate over each item of the generic List using a foreach-loop as follows:
Locking is essential in programs with multi-threading. It restricts code from being executed by more than one thread at the same time. The lock statement gets the exclusive monitor for an object and ensures that no other thread can access the object until the lock is released.
The lock statement automatically generates exception safe code, and in fact it is a syntactic shortcut for a call to the methods Monitor.Enter(obj) and Monitor.Exit(obj) with a try/finally block. However, if the thread is aborted after the lock is acquired but before entering the try block, the lock will not be released. Also, bear in mind that the Monitor.Enter() waits to acquire the lock forever which may introduce a possible deadlock condition.
Let’s take a look at the two CodeRush refactorings allowing us to convert a for-loop into foreach-loop, and a foreach-loop into for-loop, and compare these two loops to see what the difference is between them and which one is preferred.
The for-loop is useful for iterating over elements and for sequential processing. It uses an iteration variable and is good when iterating over many items sequentially with a precise condition of the iteration termination. No collection of elements is required, but we can use the iteration variable to index a separate collection. In its basic form, the loop contains three sections:
This is just a quick list to organize a bunch of refactorings that change member signatures. Click the refactoring name to learn more about it.
The refactoring adds a new parameter to a method declaration and updates all calls accordingly. This refactoring is useful when you need to quickly add a new parameter to an existing method because it needs more information from its caller that wasn’t passed in before.
Sometimes you may find that various method parameters are ordered illogically, or when method parameters appear in a different order relative to one another, similar methods. In this case, if you prefer the parameters appear in a consistent and logical order, you must not only change the order in the method signature but also update all calls to the method. Take into account complex cases when you can move return values of a function into our parameters and vice versa. Refactoring such complex cases is a rather complex and time-consuming task, especially if there are too many calls.