NDepend

Improve your .NET code quality with NDepend

What the Singleton Pattern Costs You

What the Singleton Pattern Costs You

Do you use the singleton pattern?  If not, I’m assuming that you either don’t know what it is or that you deliberately avoid it.  If you do use it, you’re probably sick of people judging you for it.  The pattern is something of a lightning rod in the world of object-oriented programming.

You can always use Stack Overflow as a litmus test for programming controversy.  Someone asked “what was so bad” about singletons, and voting, responding, and commenting went off the charts.  Most of those responses fell into the negative category.  Outside of Stack Overflow, people call singletons evil, pathological liars, and anti-patterns.  People really seem to hate this design pattern — at least some of them do, anyway.

NDepend takes a stance on the singleton pattern as well, both in its rules and on the blog.  Specifically, it encourages you to avoid it.

But I’m not going to take a stance today, exactly.  I understand the cathartic temptation to call something evil in the world of programming.  If some (anti) pattern, framework, or language approach has caused you monumental pain in the past, you come to view it as the tool of the devil.  I’ve experienced this and turned it into a blog post, myself.

Instead of going that route here, however, I’m going to speak instead about what it can cost you when you decide to use the singleton pattern — what it can cost the future you, that is.  I have a consulting practice assessing third-party codebases, so I’ve learned to view patterns and practices through a dispassionate lens.  Everything is just trade-offs.

Continue reading What the Singleton Pattern Costs You

The Role of Static Analysis in Testing

The Role of Static Analysis in Testing

“What do you do?”

In the United States, people ask this almost immediately upon meeting one another for the first time.  These days, I answer the question by saying that I do IT management consulting.  That always feels kind of weird rolling off the tongue, but it accurately describes how I’ve earned a living.

If you’re wondering what this means, basically I advise leadership in IT organizations.  I help managers, directors, and executives better understand how to manage and relate to the software developers in their groups.  So you might (but hopefully won’t) hear me say things like, “You should stop giving out pay raises on the basis of who commits the most lines of code.”

In this line of work, I get some interesting questions.  Often, these questions orient around how to do more with less.  “How can we keep the business happy when we’re understaffed?”  “What do we do to get away from this tech debt?”  “How should we prioritize our work?”  That sort of thing.

Sometimes, they get specific.  And weird.  “If we do this dependency injection thing, do we really need to deploy as often?”  Or “If we implement static analysis, do we still need to do QA?”

I’d like to focus on the latter question today — but not because it’s a particularly good or thought-provoking one.  People want to do more with less, which I get. But while that particular question is a bit of a non sequitur, it does raise an interesting discussion topic: what is the role of static analysis in testing?

Static Analysis in Testing: An Improbable (But Real) Relationship

If you examine it on the surface, you won’t notice much overlap between testing and static analysis.  Static analysis involves analyzing code without executing it, whereas QA involves executing the code without analyzing it (among other things).

A more generous interpretation, however, starts to show a relationship.  For instance, one could argue that both activities relate deeply to code quality.  Static analysis speaks to properties of the code and can give you early warnings about potential problems.  QA takes a black box approach to examining the code’s behavior, but it can confirm the problems about which you’ve received warnings.

But let’s dive even a bit deeper than that.  The fact that they have some purview overlap doesn’t speak to strategy.  I’d like to talk about how you can leverage static analysis as part of your testing strategy — directly using static analysis in testing.

Continue reading The Role of Static Analysis in Testing

Our experience with using third-party libraries

NDepend is a tool that helps .NET developers write beautiful code. The project was started in April 2004. It is now used by more than 6 000 companies worldwide.

In more than a decade, many decisions were made, each with important consequences on the code base evolution process, sometime good consequences, sometime less good. Relentlessly dog-fooding (i.e using NDepend to analyze and improve the NDepend code base) helped us a lot to obtain more maintainable code, less bugs, and to improve the tool usability and features.

When it comes to working on and maintaining a large code base for several years, some of the most important decisions made are related to relying (or not) on some third-party libraries. Choosing whether or not to rely on a library is a double-edged sword decision that can, over time, bring a lot of value or cause a lot of friction. Ultimately users won’t make a difference between your bugs and third-party libraries bugs, their problems become your problems. Consider this:

  • Sometimes the team just needs a fraction of a library and it may be more cost-effective, and more maintainable with time, to develop your own.
  • Sometimes the licensing of a free or commercial library will prevent you from achieving your goals.
  • Sometimes the library looks bright and shiny but becomes an obsolete project a few months later and precious resources will have to be spent maintaining others code, or migrating toward a trendy new library.
  • Sometimes the library code and/or authors are so fascinating that you’ll be proud to contribute and be part of it.

Of course we all hope for the last case, and we had the chance to experience this a few times for real. Here are some libraries we’ve had great success with:

Mono.Cecil (OSS)

Mono.Cecil is an open source project developed by Jean-Baptiste Evain that can read and write data nested in .NET assemblies, including compiled IL code. NDepend has relied on Cecil for almost a decade to read IL code and other data. Both the library and the support provided are outstanding. The performance of the library is near optimal and all bugs reported were fixed in a matter of days or even hours. For our usage, the library is actually close to bug free. If only all libraries had this level of excellence…

DevExpress WinForm (Commercial)

NDepend has also relied on DevExpress WinForm for almost a decade to improve the UI look and feel. NDepend is a Visual Studio extension and DevExpress WinForm makes smooth visual integration with Visual Studio. Concretely, thanks to this library we achieved the exact same Visual Studio theming and skinning, docking controls a la Visual Studio, menus, bars and special controls like BreadCrumb to explore directories. We have never been disappointed with DevExpress WinForm. The bugs we reported were fixed quickly, it supports high DPI ratio and it is rock solid in production.

Microsoft Automatic Graph Layout MSAGL (OSS)

NDepend has relied on MSAGL for several years to draw all sorts of graphs of dependencies between code elements including Call Graphs, Class Inheritance Graphs, Coupling Graphs, Path and Cycle Graphs…  This library used to be commercial but nowadays OSS.  Here also the bugs we reported were fixed quickly, it supports high DPI ratio and it is perfectly stable in production.

NRefactory (OSS)

NDepend used to have a C# Code Query LINQ editor in 2012, a few years before Roslyn became RTM. We wanted to offer users a great editing experience with code completion and documentation tooltips on mouse-hovering. At that time NRefactory was the best choice and it proved with the years to be stable in production. Nowadays Roslyn would certainly be a better choice, but since our initial investment NRefactory still does the job well, we didn’t feel the need (yet) to move to Roslyn.

 

Here are a few things we prefer to keep in-house:

Licensing

While there are libraries for licensing, these are vital, sensitive topics that require a lot of flexibility with time, and we preferred to avoid delegating it. This came at the cost of plenty of development/support and significant levels of acquired expertise. Even taking into account that these efforts could have been spent on product features, we still don’t regret our choice.

The licensing layer is a cornerstone in our relation with our users community and it cannot suffer from any compromise. As a side remark, several times I observed that the cost of developing a solid licensing layer postponed promising projects to become commercial for a while.

Persistence

As most of application, NDepend persists and restores a lot of data, especially the large amount of data in analysis results. We could have used relational or object databases, but for a UI tool embedded in VS, the worst thing would be to slow down the UI and make the user wait. We decided only optimal performance is acceptable for our users, and optimal performance in persistence means using custom streams of bytes. The consequence of this decision is less flexibility: each time our data schema evolves, we need to put in extra effort to keep ascendant compatibility.

I underline that most of the time it is not a good idea to develop a custom persistence layer because of the amount of work and expertise required. But taken account our particular needs and goals, I think we took the right decision.

Production Logs

I explained here about our production logs system. We consider it an essential component to making NDepend a super-stable product. Here also, we could have used a third-party library. We capitalize on our own logging system because, year after year, we customized it with a plethora of production information, which was required to help fix our very own problems. We kept the system lightweight and flexible, and it still helps us improve the overall stability and correctness of our products.

Dependency Matrix and Treemap UI Components

These UI components were developed years ago and are still up to date. Both then and now, I believe there is no good third-party alternative that meets all our requirements in terms of layout and performance. A few times, we received propositions to buy those components, but we are not a component provider and don’t have plans for that.

 

In this post I unveiled a few core choices we made over the years. We hope this information will be useful for other teams.

How Has Static Code Analysis Changed Through the Years?

Years ago, I found myself staring at about 10 lines of source code.  This code had me stymied, and I could feel the onset of a headache as I read and re-read it.  What did this brain-bending code do, you might wonder?  It sorted elements in an array.

Now you probably assume that I was learning to code at the time.  Interestingly, no.  I had worked gainfully as a software developer for years and was also completing a master’s degree in computer science.  In fact, the pursuit of this degree had brought me to this moment of frustration, rubbing my temples and staring tiredly at a simple bubble sort in C.

Neither inexperience nor the difficulty of the code had brought me to that point.  Rather, I struggled to formally prove the correctness of this tiny program, in the mathematical sense.  I had enrolled in a class called “Formal Methods of Software Development” that taught the math underpinning our lives as programmers.

This innocuous, simple bubble sort had seven execution paths.  Here was number five, from a piece of homework I kept in my digital files.

Code analysis ranges from the academic to the pragmatic.

Hopefully I now seem less like an incompetent programmer and more like a student grappling with some weighty concepts.  But why should a simple bubble sort prove so difficult?  Well, the short answer is that actually proving things about programs with any complexity is really, surprisingly hard.  The longer answer lies in the history of static code analysis, so let’s take a look at that.

Continue reading How Has Static Code Analysis Changed Through the Years?

Code Coverage Should Not Be a Management Concern

Code Coverage Should Not Be a Management Concern

You could easily find yourself mired in programmer debates over code coverage.  Here’s one, for instance.  It raged on for hundreds of votes, dozens of comments, many answers, and eight years before someone put it out to pasture as “opinion-based” and closed it.

Discussion participants debated a “reasonable” percentage of code coverage.  I imagine you can arrive at the right answer by taking the mean of all of the responses. (I’m just kidding.)

Some of the folks in that thread, however, declined to give a simple percentage.  Instead, they gave the obligatory consultant’s response of “it depends” or, in the case of the accepted answer, a parable.  I found it refreshing that not everybody picked some number between 50 and 100 and blurted it out.

But I found it interesting that certain questions went unasked.  What is the goal of this code coverage?  What problem does it solve?  And as for the reasonability of the number, reasonable to whom?

What is Code Coverage? (Briefly)

Before going any further, I’ll quickly explain the concept of code coverage for those not familiar, without belaboring the point.  Code coverage measures the percentage of code that your automated unit test suite executes when it runs.

So let’s say that you had a tiny codebase consisting of two methods with one line of code each.  If your unit test suite executed one method but not the other, you would have 50% code coverage.  In the real world, this becomes significantly more complicated.  In order to achieve total coverage, for instance, you must traverse all paths through control flow statements, such as if conditions, switch statements, and loops.

When people debate how much code coverage to have, they aren’t debating how “correct” the code should be.  Nor do they debate anything about the tests themselves, such as quantity or quality.  They’re simply asking how many lines of code per one hundred your test suite should cause to execute.

You can get tools that calculate this for you.  And you can also get tools that factor it into an overall code quality dashboard.

Continue reading Code Coverage Should Not Be a Management Concern

Is Your Team Wrong About Your Codebase? Prove It. Visually.

I don’t think I’ll shock anyone by pointing out that you can find plenty of disagreements among software developers.  Are singletons evil?  Is TDD a good idea (or dead)?  What’s the best IDE?  You can see this dynamic writ large across the internet.

But you can also see it writ small among teammates in software groups.  You’ve seen this before.  Individuals or small camps form around certain competing ideas, like how best to lay out the unit test suite or whether or not to use a certain design pattern. In healthy groups, these disagreements take the form of friendly banter or good-natured ribbing.  In less healthy groups, they create an us vs. them kind of dynamic and actual resentment.

I’ve experienced both flavors of this dynamic in my career.  Having to make concessions about how you do things is never fun, but group work requires it.  And so you live with the give-and-take of this in healthy groups.  But in an unhealthy group, frustration mounts with no benefit of positive collaboration to mitigate it.  This holds doubly true when one of the two sides has the decision-making authority or perhaps just writes a lot of the code and claims a form of squatter’s rights.

Status Quo Preservation

Division into camps can, of course, take many forms.  But I think the one you see most commonly happens when you have a group of developers or architects who have laid the ground rules for the codebase and then a disparate group of relative newcomers that want to change the status quo.

I once coined a term for a certain archetype in the world of software development: the expert beginner.  Expert beginners wind up in decision-making positions by default and then refuse to be swayed in the face of mounting evidence, third party opinions, or, well, really anything.  They dig in and convince themselves that they’re right about all matters relating to the codebase, and they express no interest in hearing dissenting opinions.  This commonly creates the toxic, adversarial dynamic here, and it leaves the rest of the group feeling helpless and frustrated.

Of course, this cuts the other way as well.  Sometimes the longest tenured decision makers of the group earned their position for good reason and acquit themselves well in defense of their positions.  Perhaps you shouldn’t adopt every passing fad and trend that comes along.  And these folks might find it tiresome to relitigate past architectural decisions ad nauseum every time a new developer hires on.  It probably doesn’t help when newbies throw around pejorative terms like “legacy code” and “the old way,” either.

Continue reading Is Your Team Wrong About Your Codebase? Prove It. Visually.

Code Quality Metrics: Separating the Signal from the Noise

Code Quality Metrics: Separating the Signal from the Noise

Say you’re working in some software development shop and you find yourself concerned with code quality metrics.  Reverse engineering your team’s path to this point isn’t terribly hard because, in all likelihood, one of two things happened.

First, it could be that the team underwhelmed someone, in some business sense — too many defects, serially missed deadlines, that sort of thing.  In response to that, leadership introduced a code quality initiative.  And you can’t improve on it if you can’t measure it.  For that reason, you found yourself googling “cyclomatic complexity” to see why the code you just wrote suddenly throws a warning.

The second option is internal motivation.  The team introduced the metrics of its own accord.  In this capacity, they serve as rumble strips on the side of your metaphorical road.  Doze off at the wheel a little, get a jolt, and correct course.

In either case, an odd sort of gulf emerges between the developers and the business.  And I think of this gulf as inherently noisy.

Code Quality Metrics for Developers

I spend a lot of time consulting with software shops.  And shops hiring consultants like me generally have code quality improvement initiatives underway.  As you can imagine, I see an awful lot of code metrics.

Here are some code quality metrics that I see tracked most commonly.  I don’t mean for this list to be an exhaustive one of all that I see.

  • Lines of code.  (This is an interesting one because, in aggregate, it’s often used to track progress.  But normalized over smaller granularities, like types and methods, people correlate it negatively with code quality — “that method is too big.”)
  • Cyclomatic complexity: the number of execution paths that exist through a given unit of code.  Less is more.
  • Unit test coverage: the percentage of paths through your code executed by your unit test suite.  More is more.
  • Static analysis tool/lint tool violations count: run a tool that provides automated code checks and then count the number of issues.

As software developers, we can easily understand these concepts and internalize them.  But to explain to the business why these matter requires either a good bit of effort or a “just trust us.”  After all, the business won’t understand these concepts as more than vague generalities.  There’s more testing coverage, or something…that sounds good, right?

These metrics can then have noise in them, meaning that how important they are for business outcomes becomes unclear.

Continue reading Code Quality Metrics: Separating the Signal from the Noise

C# Version History: Exploring the Language History from Past to Present

C# Version History: Examining the Language Past and Present

I still remember my first look at C# in the early 2000s.  Microsoft had released the first major version of the language.  I recall thinking that it was Java, except that Microsoft made it, called it something else, and put it into Visual Studio.  And I wasn’t alone in this sentiment.  In an old interview, Java inventor James Gosling called it an imitation.  “It’s sort of Java with reliability, productivity, and security deleted,” he said.  Ouch.

A lot changes in 15 years or so.  I doubt anyone would offer a similar assessment today.  In that time, Java has released four major language versions, while C# has released six.  The languages have charted divergent courses, and C# has seen a great deal of innovation.  Today, I’d like to take a look back on the history of C# and highlight some of those key points.

What did the language look like in its earliest incarnations?  And how has it evolved in the years since?

Continue reading C# Version History: Examining the Language Past and Present

What is static analysis?

What is Static Analysis? An Explanation for Everyone

Static analysis, as a concept, seems to earn itself a certain reputation.  The general population may regard programming as a technocratic, geeky pursuit.  But inside the world of programmers, static analysis has that equivalent rap.  It’s a geeky subject even among geeks.

I suspect this arises from the academic flavor to static analysis. You hear terms like “halting problem,” “satisfiability,” and “correctness proofs,” and you find yourself transported back to some 400-level discrete course from your undergrad.  And that’s assuming you did a CS undergrad.  If not, your eyes might glaze over.  Oh, and googling “static analysis” only to see things like this probably doesn’t help:

A static analysis screenshot that scares anyone looking at it

I have two CS degrees, concentrated heavily on the math side of things, and I specialize in static analysis. And that featured image makes my eyes glaze over.  So let’s hit the reset button here.  Let’s make the subject at least approachable and maybe, just maybe, even interesting.

Defining Static Analysis Dead Simply

Whether you’re a grizzled programming veteran, fresh out of a bootcamp, or can’t program a lick, you can understand the concept.  I’ll use an analogy first, to ease into things.

When you write software, you write instructions in a format that you and other programmers understand.  A program called the compiler (in many cases) then translates these into terms that computers understand and eventually into automation output.  So think of programming as writing a grocery list for a personal shopper.  You write down what you want, in easily understood terms.  The personal shopper then maps this list to his knowledge of the grocery store’s layout and eventually produces output in the form of food that he brings you.

What, then, is static analysis in this world?  Well, it’s analyzing the written grocery list itself and using it to speak to what the grocery shopping and groceries will be like.  For instance, you might say, “Wow, 140 watermelons, huh?  We’re going to need to rent a truck, so that’s going to cost you extra.”

When it comes to writing code, people usually reason about it by running it and seeing what happens.  In our world, that means the shopper simply takes the list, goes on the shopping trip, and sees how things go.  “Wow, this is a lot of watermelon,” he says as he fills the 15th cart full of the things.  Only then does he start to understand the ramifications of this.

Static analysis capitalizes on the fact that you can understand things about the upcoming grocery run without actually executing it.

Continue reading What is Static Analysis? An Explanation for Everyone

Should You Aim for 100 Percent Test Coverage?

Test coverage serves as one of the great lightning rods in the world of software development.  First, people ask whether it makes for a good metric at all.  Then they ask, if you want to use it as a metric, should you go for 100 percent coverage?  If not, what percentage should you go for? Maybe 42 percent, since that’s the meaning of life?

I don’t mean to trivialize an important discussion.  But sometimes it strikes me that this one could use some trivializing.  People dig in and draw battle lines over it, and counterproductive arguments often ensue.  It’s strange how fixated people get on this.

I’ll provide my take on the matter here, after a while.  But first, I’d like to offer a somewhat more philosophical look at the issue (hopefully without delving into overly abstract navel-gazing along the lines of “What even is a test, anyway, in the greater scheme of life?”)

What Does “Test Coverage” Measure?

First of all, let’s be very clear about what this metric measures.  Many in the debate — particularly those on the “less is more” side of it — quickly point out that test coverage does not measure the quality of the tests.  “You can have 100 percent coverage with completely worthless tests,” they’ll point out.  And they’ll be completely right.

To someone casually consuming this metric, the percentage can easily mislead.  After all, 100 percent coverage sounds an awful lot like 100 percent certainty.  If you hired me to do some work on your car and I told you that I’d done my work “with 100 percent coverage,” what would you assume?  I’m guessing you’d assume that I was 100 percent certain nothing would go wrong and that I invited you to be equally certain.  Critics of the total coverage school of thought point to this misunderstanding as a reason not to pursue that level of test coverage.  But personally, I just think it’s a reason to clarify definitions.

Continue reading Should You Aim for 100 Percent Test Coverage?