I have inherited a few programs from a previous developer who was a little sloppy with naming variables, methods and classes with different capitalization and sometimes underscores.
Is there a program or a way in visual studio to validate the naming of each variable, method, property, constant, class.... I would be fine with the standard C# conventions.
You could look at Microsoft StyleCop and FXCop
I use ReSharper 4.5 for that, which has this advantage, that it allows you to see non-comforming code as you write it.
You also can use NDepend and CQL to check your conventions in a very granular and flexible way. It's great as part of your build script.
Both tools cost money, both are worth it.
Have a look at StyleCop / CodeStyleEnforcer
They'll highlight the bogies but you'll hvae to fix them yourself
http://code.msdn.microsoft.com/sourceanalysis
http://joel.fjorden.se/static.php?page=CodeStyleEnforcer
What you're looking for is StyleCop.
It reads source code to ensure that certain rules are obeyed.
FxCop is used to read the compiled code and generally is not used for this sort of stylistic checking.
FXCop has that and much more.
FXCop and StyleCop can be used to check for conformance to best practices and standards.
FxCop will do the job (or more up-to-date Code Analysis).
This sounds like a job for:
StyleCop
From the website:
StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project
As the others have said: FxCop and StyleCop. ReSharper 4.5 also has configurable naming conventions. The beauty of this is that it'll highlight misnamed items and give you a popup with a suggested name. I'm not 100% sure, but I think this can also be run during ReSharper's 'Code Cleanup' functionality (if it's not, it'd be great if it could be!)
Of course, once you edit and and correct the names, they'll only be correct at that very point time in time. To ensure they're correct now and forever more, integrate FxCop/StyleCop into your Continuous Integration environment. This'll catch the naughty anti-social developers who flaunt the rules and regulations (what community service you give them is up to you, but it often involves being the doughnut and/or coffee purchaser 'till someone else screws up!)
Related
Similar questions: Styleguide for C# and StyleCop: a complete document
Ok, so I'm looking into some sort of style control at my workplace for the applications we develop in C#. I was initially just planning on producing a style guide (by collecting a number of existing style guides and picking the suitable parts from), however it seems like StyleCop might be a good addition or alternative to a style guide.
So, my question(s) are:
What are the potential problems with a style guide and/or StyleCop
that I am likely to run into?
If I use StyleCop how similar do I want the style guide to be? Do I want to attempt to prevent/limit any variation between the 2 methods? I ask because
if StyleCop doesn't enforce it then it could potentially be ignored (or is that not really too much of an issue?).
If I'm using StyleCop, is it even worth the time and effort of creating a style guide?
Are there any alternatives to StyleCop that a worthwhile looking into? (e.g. An alternative that has very good
usability/customization and "could" be considered sufficient on it's
own).
EDIT: Just a little bit of background, my workplace has a "software department" that is only really just forming now. There is 3 full time c# developers, 3 developers who may touch/use/alter the c# code, a number of BA's and no official testers.
After having been on a team that used/maintained/enforced a style guide and then on a team that used StyleCop, my advice is to use StyleCop exclusively. This is for several reasons:
It is compile-time enforceable. This is a huge advantage when it comes to something as persnickety as style. With a style manual there's always gray area, but there isn't any with a compiler error. This reduces style arguments from "This is wrong"/"No it isn't" to "Which should we prefer", which is (usually) a more civil argument.
If you create your own style, someone (or all of you) will need to be the human "style cop", which is a pretty miserable job. Developers (in my experience) tend to not like people making "style adjustments" to their committed code, and dislike even more when told to make their code conform to the style. This is also time consuming as it's another thing to review during code reviews (you are doing those, right?).
StyleCop comes with a pretty decent set of default rules, and using just these rules will let you match most other C# codebases out there. When I was using our own in-house style manual, all open-source code looked foreign because we used comment headers, capitalized parameters, some Hungarian notation, etc. But when I moved to StyleCop-enforced style with the default rule set, everything looked familiar!
Creating your style means you're going to spend a lot of time re-inventing the wheel, and then maintaining that wheel when edge cases and arguments appear. That's a non-zero amount of work and can chew up a lot of time; from my experience developers will always debate code style.
It has a decent editor to configure your rule set if you don't like some of the defaults or need to add abbreviations that StyleCop should ignore.
You can write your own rules or use those that others have published. For instance, some on our team hate trailing whitespace, so I include these rules to enforce that.
As far as alternatives, I don't know of any that are as seamless as StyleCop is. I should note that I've only ever used it in conjunction with Resharper/Visual Studio, so if you have a different environment then your mileage may vary.
FYI, the new StyleCop Analyzers NuGet Package is a major improvement on things. You can now hand-pick your StyleCop rules (or just use the default selections) by editing the project's rule set (Properties -> Code Analysis).
I just discovered they've even included three "alternative" rules for teams that follow the dark side... :-)
SX1101 - Do not prefix local calls with 'this.'
SX1309 - Field names must begin with underscore
SX1309S - Static field names must begin with underscore
The best thing you can do in your workplace is teach the value of:
Recognize existing style patterns in a body of code.
Follow the existing style patterns which you make changes to that body of code.
Regardless of the project you are working on, this practice leads to the overall lowest rate of submissions getting returned for style issues. It also requires the least amount of explanation in your style guide.
With that out of the way, you can focus on topics which are less easily inferred from looking at a single file, such as naming conventions used across the code base, threading models in effect, and the interaction between modules at a high level.
we have a code base (VB.NET and C#) and a new coding standard. Do you have suggestions of tools that can move through a project and rename parameters/fields/properties/metothods etc according to the new coding standard.
It might for example need to change parameters into camel-case etc. One would imagine that parameters and local fields/variables are more easily renamed due to their local scope.
I have looked at ReSharper but haven't found that it performs this task.
Sounds like a job for ReSharper with the StyleCop plugin. Here's an example:
Parameters name camelCasing :
fields renaming :
Solution Cleanup :
Several options come into mind:
Resharper
JustCode
Depending on the version of your Visual Studio you have StyleCop built into it and you can enforce checkin rules in TFS that the code itself must comply with the guidelines before something can be checked in.
Something else: why did you change your coding standards all of a sudden and apparently go through all of your existing/production code to change it. I can imagine you want to enforce the new guidelines in new applications that need to be built or just started out.
I'm trying to make a custom FxCop rule that will test for calls to the indexer getter of Request.QueryString without a previous call (in the same method) to a certain validation method from our project's Utilities module.
The documentation I've found is not in-depth enough to get me where I need to go. Is there some doc that I'm missing? Or is it time for trial and error?
What I've seen:
http://www.binarycoder.net/fxcop/
http://blog.tatham.oddie.com.au/2010/01/06/custom-code-analysis-rules-in-vs2010-and-how-to-make-them-run-in-fxcop-and-vs2008-too/
http://blogs.msdn.com/b/codeanalysis/
http://msdn.microsoft.com/en-us/magazine/cc163930.aspx
As well as all SO posts tagged FxCop with the word custom.
Any ideas?
There is no official SDK for FxCop rules. The most complete single resource is http://www.binarycoder.net/fxcop/. Pretty much all the available resources are geared toward helping one get started with the "wrapper" mechanics of creating rules. None of them really cover the finicky details of how to create specific rule logic. For that sort of thing, your best bet is to grab a decompiler like Reflector so that you can see how the Microsoft-supplied rules are built. Another helpful technique is to run your embryonic rules under the debugger so that you can see the objects and properties that are available at runtime. If you get stuck with some particular part of a rule implementation, you can always ask about it either here or on the FxCop forum maintained by Microsoft.
I've been tasked to write our department's C# Programming Standard (including guidelines). What sort of standards/guidelines should I include? I've already taken bits from various standards around the net (and pieces from Code Complete), but I'd like hear from developers in the field.
I've already got:
Naming Conventions - General/Variables/Classes/Methods/Interfaces/Controls
General Programming Practices - Documentation (comments etc), [WIP]
OO Programming Practices - Encapsulation, [WIP]
What else would be useful? What shouldn't I include?
Have you already suggested that everyone reads the "Design Guidelines for Class Library Developers"? That covers the bulk of it. Other than that, I'd want to hammer home:
You should very rarely be creating your own structs. Don't think of them as lightweight classes.
Structs should never be mutable.
Fields should always be private, apart from readonly fields where the type of the field is immutable
Only attempt lock-free programming if you're sure that a simpler solution will be too slow - and have evidence!
Readability is king
Be aware of cultural issues - in particular, read Microsoft's String Handling Recommendations
I'll add more as I think of them...
Information on how to handle namespaces, assembly/project/solution naming conventions, nameing conventions of files.. grouping of items (for example of your have both Item and Item do they go in the same file?)
File name guidelines
Namespace naming / organising guidelines
Design & architectural guidelines such as using interfaces to create louse coupeling and to make unittesting eaiser (for such as dependency injection and mocking)
Advice on when things should be refactored (long methods and so on)
Naming and casing for parameters
Guidelines on unit testing (if you use it) and on mocking
Grouping of items (for example of your have both a generic and non-generic implementation of a class do they go in the same file or seperate files following a naming convention?)
How to handle 3rd party dependencies
Promoting the use of tools like FxCop, StyleCop and other metrics
Just a couple of things from the top of my head
Guides on maximum method length, maximum class size and maximum loc in a source file are usefull.
Furthermore you can set some guidelines on indentation and code layout and stuff but I found it easier just to do this with settings in Visual Studio and then have your developers import the same settings file for this. This way people don't have to think about this and visual studio does the work for them.
Best practices can be checked automatically too by FXCop and tools like that. So it's usefull to distribute guidelines about that by just making FXCop files available that check all the rules you care about. Dont introduce big FXCop checks in a large existing code-base though try to ramp up the checks over a period of time so people dont get hit with 1000's of FXCop errors
In short:
Try to keep the guidelines short, only include things that are really important. Make them easy to read (you can write naming conventions as an example-class for example where you highlight all the rules with some extra boxes with text) And use tools to automate checks where you can so developers get easy and early feedback.
My group has a source analysis tool that enforces certain styles that we have to comply with. I can't change it, and some of the rules are just a pain. One example is that all properties have to come before methods, and all constructors must come before properties. It seems silly to me that I have to take time to do something to the program when to the compiler it is the same. I would like some thing that is a plugin to VS that will let me do things like this automatically. Also, it would be nice to have it automatically put using's inside the namespace block.
You have different possibilities, depending on what exactly you want to do:
Resharper: There is a auto-format function which formats the source code of a single file or all files in the project / solution depending on your selected rules. So you set the settings for braces, naming, whitespaces, operators, lamdas, ... For more information see here. Resharper also supports settings a source- code file for all solutions or a shared settings file which is the same for all persons in the team.
FxCop: I havn't ever used this at work, but it's also a great tool an you can also select the rules which you want to enforce.
Unless they bake it into VS2010, Resharper has the auto formatting capabilities you're probably looking for. CodeSmith probably has it too, I just haven't used it...
There are some formatting options built into VS.
Goto Tools-->Options-->Text Editor-->C#-->Formatting.
They don't include every scenario, but might get you close.
Resharper - what a fantastic tool. I don't think I could manage without it. It must be the ultimate productivity tool for Visual Studio. Re-factoring, code analysis, code formatting, code completion - it has the lot.