Finding Code Issues with Roslyn

Just published my first MSDN code sample in the new gallery. It's on writing a CodeIssueProvider to extend Visual Studio for new types of code issues, and optionally provide an automated refactoring for it. The sample I used this older post which is incompatible with the latest Roslyn CTP.

The Fallacy of ReUse

I've read The Fallacy of ReUse and while it presents very good arguments against reusing things. Clearly there is a path to reusable code, otherwise why would we have frameworks or .net? Why would we have so many code snippet web sites and webapps? Microsoft wrote a book on this type of reusable code and I'm in the process of reading it. Design patterns are some of the best examples of reusable code that shines or perhaps has been through it's lifecycle and was retired for a better pattern. I'd hardly call a 3-5 yr life cycle something that wasn't reusable.

I think, like most concepts in programming, there is a time and a place for code reuse, designing for reuse, and refactoring/reworking code for the purpose of reuse.

Most businesses, concepts, inventions and products don't happen magically, they are born of failure after failure. Look at how many times Thomas Edison failed to invent various things.

If your position/team/manager leaves you no time for experimentation on tools, concepts, add-ins, macros, frameworks architectures that might improve your overall work speed or team productivity, then reuse attempts/ideas/experimentation is probably not appropriate. However, I don't imagine there's a team out there that couldn't benefit from allocating time for trying alternate ways of doing things, reviewing each others' ways of doing things, or brainstorming for reusable solutions to common problems.

I also don't imagine it's something everyone can do or excel at. Most people give up on most challenges in life, that's what leaves room to strive for excellence and get there (or enjoy the time spent chasing that elusive goal).

There's code that's valuable merely because it's called in 2 places in a class. Isn't this the heart of refactoring and Don't Repeat Yourself? Code reuse to me is shooting for DRY on a slightly higher level than simple class method refactoring, although I work hard at that as well.

It's to see how far out can this reusable code scale?
Many methods in a class can make use of this code? Nice. Many classes in a project can make use of this class? Cool. Many projects in a solution can make use of this code? Sweet. Some of my reusable code is useful in projects outside of my company? Awesome.

Or perhaps I'm just passing along code I found on the web that I believe to be useful. I enjoy that too. I enjoy being someone that might have a corner or edge-case solution that other developers seek me out for.

I enjoy pretty much anything I can do to lure developers into talking code with me and I think this is a valuable niche. So maybe I'm too biased. Either way I enjoy the pursuit, your mileage may vary.

Just how frequently is 'refactor frequently'?

I was asked what I meant by refactor frequently on the guidelines and could not locate a good answer to that... to me the question was wrong. When should not you refactor is more along the lines of my thinking. Not that I think there's a great answer to that either, but then I did skip over the google results that implicated when to stop refactoring or when not to refactor while searching for these quotes.

I tend to refactor with support from the DRY principle of as soon as you notice something is redundant or repeated. I refactor either on the first noticed redundancy or the 2nd when I'm primarily coding, when I'm reviewing, I try to refactor any redundancy I find. I also refactor based on the other Code Smells. I will also refactor when I notice violations of SOLID,  Domain Driven Design (DDD for short), and now I've started to think about Command-Query Seperation (CQS).

When I see code that looks ugly but fits these I'll shoot for refactoring towards a Fluent Interface  with Method Chaining

I think I already do command query separation but I haven't been looking for it in particular.

And here's the email I sent out to the team, it appears that what I just wrote here probably should been included at the top... oh well. A little context, the email was generated in response to a meeting on the coding standards I put forth.

... asked me for guidelines in our meeting about how frequent is ‘refactor frequently’? I had difficultly answering the question and I think everyone here was aware of that. I hope to address this question with some support from the blogosphere/industry.

·         Before any redesign

o   Helps you get familiar or re-familiarize yourself with the existing code

o   Helps solidify the existing design for the addition of new features.

·         Before any new project that builds on top of the old one

·         Before adding new features to a stable build

·         Semi-continuous refactoring

o   Code a little, test a little, refactor a little.

·         Make it your goal to leave the code in better shape at the end of the day than at the beginning

Ideas from Elliotte Rusty Harold – from The Cafes – When to Refactor author of the book Refactoring HTML

Refactoring throughout the entire project life cycle saves time and increases quality.

Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Keep your code clean and concise so it is easier to understand, modify, and extend. Make sure everything is expressed once and only once. In the end it takes less time to produce a system that is well groomed.

From - Refactor Mercilessly

When?

The sooner the better as is easier, faster and less risky to refactor over a recently refactored code rather than waiting to refactor for the code to be almost completed.

From Alberto Gutierrez’s blog Making good software – Refactoring: The 5 main questions: Why? When? What? How? Who?

What is refactoring and why?

XP Practices: Refactoring

Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, duplicate code, and many other varieties of confusion and clutter. (Check out this list of such "design smells.")

Rot is what makes code difficult to maintain or extend. Every time we change code without refactoring it, rot worsens and spreads. Code rot frustrates us, costs us time, and unduly shortens the lifespan of useful systems.

Refactoring code ruthlessly prevents rot, by keeping code easy to maintain and extend. This extensibility is the reason to refactor and the measure of its success. This is what enables XP teams to embrace arbitrary and drastic change. Note that the XP practice of Test-driven Development (TDD) is essential to refactoring. The exhaustive tests produced by TDD are what make it safe and orderly to make changes of any kind. This is why Adaption always teaches TDD and refactoring together.

Code Hygiene

What does "refactor ruthlessly" mean? It means striving as a matter of routine to keep the code's design simple and crystal clear. It means knowing the design principles and patterns that are vital to keeping code extensible, and knowing when to "refactor toward" them. It means refactoring both production code and test code frequently during the day, eliminating all forms of the "code smells" that are precursors to true rot.

Mainly it means never going home at the end of the day with "code debts" that need paying tomorrow (smelly sections that need cleaning up). This level of code hygiene may at first seem like a lot of extra work, but it pays you such dividends so soon and so regularly that you soon become addicted to it -- rather like TDD.

From adaption