For instance, an instance of a class implementing IDisposable may be created in one location, and then disposed in a different location. ![]() Keep code reviews for interesting stuff.Īnother aspect is that human reviewers are not necessarily good at spotting problems found by Code analysis. There is nothing worse than spending a code review pinpointing style problems or problematic patterns which could have been found automatically. Both Code analysis and StyleCop are excellent at finding things automatically before a code review. The presence of code reviews is not a reason to avoid Code analysis. SA1310: Field names must not contain underscore), those two tools are complementary and often used side by side. StyleCop don't lead to discoveries: there is nothing interesting in knowing that fields start with a lowercase letter or that local calls should be prefixed with this.Įven if some rules are enforced by both Code analysis and StyleCop (such as CA1707: Identifiers should not contain underscores vs. For example, CA2105: Array fields should not be read only may lead somebody to a discovery that even if an array is marked as read-only, it doesn't make it immutable, since nothing forbids to change the elements within the array. The second (and most important) difference is that Code analysis searches for patters which may indicate a bug, while StyleCop is simply enforcing style rules-a simple convention used by your team.Ĭode analysis is also particularly useful for beginners who don't know the language very well, since it can often lead to "Aha!" moments. The first difference is that Code analysis works with the compiled assembly, while StyleCop works with the source itself. Note that code analysis is not the same thing as StyleCop. Introducing it in an existent project may be too painful. For instance, globalization warnings can be turned off if your project is not intended to be localized.Īs with StyleCop, it is essential to decide whether the project will target zero warnings from Code analysis from the beginning of the project. The checks and warnings can be fine-grained in project properties to suit your needs. While running Code analysis during pre-commit is not a good idea (unlike StyleCop), it can still run on build and fail it if warnings are found.įor non-business-critical code, Code analysis may be run manually from Visual Studio or command line. Since static analysis can take some time for medium or large projects, it is often a good idea to move it from developer's machines to the TFS build server. Within Visual Studio, Code analysis can be configured to run at compile-time if project settings also specify that warnings should be treated as errors, violations of Code analysis rules won't stay unnoticed. Which projects qualify?Īlthough it is subject to false positives, as any static analysis tools, it is usually beneficial to target zero warnings for business-critical code without using suppressions. NET Framework classes which implement it). For instance, in the previous example, it may be quite boring for a developer to check if any class he uses implements IDisposable (or to remember all. Using (var connection = new SqlConnection(.))Īs any static analysis tools, Code analysis is intended to find patterns which are cumbersome (or simply boring) to find manually. This is the correct implementation of the previous piece of code: private void DoSomething() For example, if an instance of a class which implements IDisposable is not disposed properly, Code analysis will emit a warning: private void DoSomething() ![]() Code analysis (previously FxCop) is a static analysis tool which searches for common patterns which may indicate that something is wrong in the source code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |