DaedTech

Stories about Software

By

Enforcing Immutability in Multi-Threaded Projects with NDepend

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look around at some of the features you get by downloading NDepend.

Early in the days of object oriented programming, we really got a lot of mileage out of the language and paradigm features.  For instance, if your memory extends back far enough (or your application is legacy enough), you’ll see really, really deep inheritance hierarchies.  Since inheritance was a language feature, it stood to reason that we should get our money’s worth, and boy did we ever.  We look back on that as an anti-pattern now with our 20/20 hindsight.

The same was true of application state.  The classic notion of object oriented programming was one in which objects of state and of behaviors.  For perhaps the most iconic early conception of this notion, consider the active record design pattern.  This pattern addressed the so-called impedance mismatch by presenting us with an in-memory, object-based representation of a database table.  The object’s state was the table and the behaviors were records that you could perform on it, such as saving or deleting or what have you.

While active record, particularly in some communities, has not been as roundly rejected as deep inheritance hierarchies, it no longer enjoys the favor that it did more than a decade ago.  And a big part of the reason that it, and other state-based patterns don’t, is that the object-oriented community has come to favor immutability, meaning that any data stored in an object is read-only for the lifetime of that object.

vendingmachine

Immutable objects are, first and foremost, easier to reason about.  Take, for instance, the humble object collaborator.

This may or may not work, depending on what people come along and do with TheService.  What happens if they null it out?  To make life easier, we move away from mutable state implementations in favor of approaches like this.

Now there’s no reason to worry about the service being valid.  At the time of object construction, we enforce any preconditions, and then we don’t need to worry that _service.GetMeABeer() is going to generate a null reference exception or wind up calling a different implementation than the last time it was invoked.  ServiceConsumer is now immutable with respect to Service.

Read More

By

Improve Your Code Review Game with NDepend

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  If you like posts about static analysis, have a look around while you’re there.

Code review is a subject with which I’m quite familiar.  I’m familiar first as a participant, both reviewing and being reviewed, but it goes deeper than that.  As an IT management consultant, I’ve advised on instituting and refining such processes and I actually write for SmartBear, whose products include Collaborator, a code review tool.  In spite of this, however, I’ve never written much about the intersection between NDepend and code review.  But I’d like to do so today.

I suppose it’s the nature of my own work that has made this topic less than foremost on my mind.  Over the last couple of years, I’ve done a lot of lone wolf, consultative code assessments for clients.  In essence, I take a codebase and its version history and use NDepend and other tools to perform extensive analysis.  I also quietly apply some of the same practices to my own code that I use for example purposes.  But neither of these is collaborative because it’s been a while since I logged a lot of time in a collaborative delivery team environment.

DevOpportunityCost

But my situation being somewhat out of sync with industry norms does not, in any way, alter industry norms.  And the norm is that software development is generally a highly collaborative affair, and that most code review is happening in highly collaborative environments.  And NDepend is not just a way for lone wolves or pedants to do deep dives on code.  It really shines in the group setting.

NDepend Can Automate the Easy Stuff out of Code Review

When discussing code review, I’m often tempted to leave “automate what you can” for the end, since it’s a powerful point.  But, on the other hand, I also think it’s perhaps the first thing that you should go and do right out of the gate, so I’ll mention it here.  After all, automating the easily-automated frees humans up to focus on things that require human intervention.

It’s pretty likely that you have some kind of automation in process for enforcing coding standards.  And, if you don’t, get some in place.  You should not be wasting time at code review with, “you didn’t put an underscore in front of that field.”  That’s the sort of thing that a machine can easily figure out, and that many, many plugins will figure out for you.

The advantages here are many, but two quick ones bear mentioning here.  First is the time-savings that I’ve discussed, and second is the tightening of the feedback loop.  If a developer writes a line of code, forgetting that underscore, the code review may not happen for a week or more.  If there’s a tool in place creating warnings, preventing a commit, or generating a failed build, the feedback loop is much tighter between undesirable code and undesirable outcome.  This makes improvement more rapid, and it makes the source of the feedback an impartial machine instead of a (perceived) judgmental coworker.

Read More

By

How to Analyze a Complex Solution

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  If you enjoy posts about code quality and static analysis, add the NDepend blog to your feed.

I’ve made no secret that I spend a lot of time these days analyzing code bases as a consultant, and I’ve also made no secret that I use NDepend (and its Java counterpart, JArchitect) to do this analysis.  As a result, I get a lot of questions about analyzing codebases and about the tooling.  Today, I’ll address a question I’ve heard.

Can NDepend analyze a complex solution (i.e. more than 100 projects)?  If so, how do you do this, and how does it work?

Singularity

Can NDepend Handle It?

For the first question — in a word, yes.  You certainly can do this with NDepend.  As a matter of fact, NDepend will handle the crippling overhead of this many projects better than just about any tool out there.  It will be, so to speak, the least of your problems.

How should you use it in this situation?  You should use it to help yourself get out of the situation.  You should use it as an aid to consolidating and partitioning into different solutions.

The Trouble with Scale

If you download a trial of NDepend and use it on your complex solution, you’ll be treated to an impressive number of project rules out of the box.  One of those rules that you might not notice at first is “avoid partitioning the code base through many small library assemblies.”  You can see the rule and explanation here.

We advise having less, and bigger, .NET assemblies and using the concept of namespaces to define logical components.

You can probably now understand why I gave the flippant-seeming answer above.  In a sense, it’d be like asking, “how do I use NDepend on an assembly where I constantly swallow exceptions with empty catch blocks.”  The answer would be, “you can use it to help you stop doing that.”

Read More

By

Put a Little NDepend in your Visual Studio

Editorial Note: I originally wrote this post for the NDepend blog.  Check out the original here, at their site.  If you like posts on the topics of static analysis and software architecture, check out the rest of the posts while you’re over there.

The software development world is filled with what I think of as “Coke-Pepsi” debates. This is how my brain categorizes debates over preference that are almost entirely subjective. There is no right or wrong answer to “is Coke or Pepsi better?” The answer is, “whichever one you like better.”

Examples abound in the software world. Should you use a heavyweight IDE or a lightweight text editor? Which OOP language is ‘the best?’ And, speaking of OOP, should you use an OOP language at all, or should you use a functional one? Pascal casing or camel? The list goes on, but these sorts of things generally boil down to the comfort and preferences of the person or team.

It would be tempting to paint NDepend Standalone versus NDepend’s Visual Studio plugin with this brush. And, while I think you could make a pretty legitimate case that this too, is simply a matter of preference, I’d like to do a thought exercise today in which I lobby in favor of the integration approach. In my opinion, there are enough advantages that I might be able to sneak this one out of the Coke-vs-Pepsi realm.

pepsi-v-coke1

What’s The Difference?

First of all, I should probably explain a bit more about the difference. NDepend standalone runs like any standard, windows desktop application. In order to use it, you’d launch it and use it to query your code base, run reports, visualize your architecture, etc. If you wanted to modify your code and use NDepend simultaneously, you would have two open Windows that you would alt-tab between.

As a plugin, NDepend runs as if it were a part of Visual Studio itself. Visual Studio has a plugin-supportive architecture that allows third party tool authors to write plugins that behave this way. To users of the plugins, the integration is totally seamless. So for all intents and purposes, NDepend’s Visual Studio plugin makes NDepend a first class part of Visual Studio. Thus everything you do with NDepend and your code all happens in the same place: Visual Studio.

Why Is This Better?

I’d imagine the first thing that occurs to you is the lack of needing to alternate between two windows. And I submit that this is, in fact, an advantage, though this advantage only scratches the surface. Logistically, there is less friction in use when you don’t need to constantly context switch between two windows. And, even if you prefer to separate the concerns out into multiple windows (say, if you have multiple monitors), you can still do this inside of Visual Studio.

Read More

By

The Power of CQLinq for Developers

Editorial Note: I originally wrote this post for the NDepend blog. Check out the original here, at their site.  While you’re there, have a look around at some of the other posts and subscribe to the RSS feed if you’d like a weekly post about static analysis.  

I can still remember my reaction to Linq when I was first exposed to it.  And I mean my very first reaction.  You’d think, as a connoisseur of the programming profession, it would have been, “wow, groundbreaking!”  But, really, it was, “wait, what?  Why?!”  I couldn’t fathom why we’d want to merge SQL queries with application languages.

Up until that point, a little after .NET 3.5 shipped, I’d done most of my programming in PHP, C++ and Java (and, if I’m being totally honest, a good bit of VB6 and VBA that I could never seem to escape).  I was new to C#, and, at that time, it didn’t seem much different than Java.  And, in all of these languages, there was a nice, established pattern.  Application languages were where you wrote loops and business logic and such, and parameterized SQL strings were where you defined how you’d query the database.  I’d just gotten to the point where ORMs were second nature.  And now, here was something weird.

But, I would quickly realize, here was something powerful.

Nascar

The object oriented languages that I mentioned (and whatever PHP is) are imperative languages.  This means that you’re giving the compiler/interpreter a step by step series of instructions on how to do something.  “For an integer i, start at zero, increment by one, continue if less than 10, and for each integer…”   SQL, on the other hand, is a declarative language.  You describe what you want, and let something else (e.g. the RDBMS server) sort out the details.  “I want all of the customer records where the customer’s city is ‘Chicago’ and the customer is less than 40 years old — you figure out how to do that and just give me the results.”

And now, all of a sudden, an object oriented language could be declarative.  I didn’t have to write loop boilerplate anymore!

Read More