DaedTech

Stories about Software

By

Is Your Code Hard to Understand?

Editorial Note: I originally wrote this post for the Infragistics blog.

I’ve heard a bit of conventional wisdom in the software industry.  It holds that people will read a given line of code an order of magnitude more times than they’ll modify it.  Whether that wisdom results from a rigorous study or not, I do not know. But it certainly squares with my experience.  And it also seems to square with the experience of just about everyone else.

Accepting this wisdom as axiomatic, code readability becomes an important business concern.  If you optimize for ease of writing at the cost of ease of reading, your business will lose money.  Better to spend some extra time in writing your code to ensure that future readers have an easy go of it.  And easy for them means that they understand the code.

You know of obvious ways to promote reader understanding in code.  Don’t give variables cryptic names or names that cannot be pronounced.  Don’t write gigantic methods and classes.  Limit method parameters and local declarations.  Read through the code out loud to see if it seems clear.  These guidelines will bring you a long way toward readability.

But other, subtle concerns can also chip away at your code’s readability.  I’ll list some of these here, today.  These are generally C# specific, but some are more broadly applicable than that.  What all of them have in common is that they constitute sources of confusion for readers that may not seem immediately obvious.

Read More

By

Keep Your Codebase Fit with Trend Metrics

Editorial Note: Thanks to everyone who voted for a Developer Hegemony Cover.  I’ll tabulate the official results soon, but it looks like the dark cover is the clear favorite!

Second 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, take a look at the new version of NDepend.

A while back, I wrote a post about the importance of trends when discussing code metrics.  Metrics have impact when teams are first exposed to them, but that tends to fade with time.  Context and trend monitoring create and sustain a sense of urgency.

To understand what I mean, imagine a person aware that he has put on some weight over the years.  One day, he steps on a scale, and realizes that he’s much heavier than previously thought.  That induces a moment of shock and, no doubt, grand plans for gyms, diets, and lifestyle adjustments.  But, as time passes, his attitude may shift to one in which the new, heavier weight defines his self-conception.  The weight metric loses its impact.

To avoid this, he needs to continue measuring himself.  He may see himself gaining further weight, poking a hole in the illusion that he has evened out.  Or, conversely, he may see that small adjustments have helped him lose weight, and be encouraged to continue with those adjustments.  In either case, his ongoing conception of progress, more than the actual weight metric, drives and motivates behaviors.

The same holds true with codebases and keeping them clean.  All too often, I see organizations run some sort of static analysis or linting tool on their codebase, and conclude “it’s bad.”  They resolve only to do a better job in a year or two, when the rewrite will start.  However good or bad any given figure might be, the trend-line, and not the figure itself, holds the most significance.

Trend Metrics with NDepend

In that last post, I touched only on the topic, but not the specifics.  Here, I’d like to speak to how NDepend helps you with metrics.  I suspect that a lot of people know NDepend for its memorable visualization aids and its code rules and queries.  I don’t see as much discussion about the valuable trend tools, perhaps because they were release comparably recently.  In either case, I want to talk today about those tools.

Read More

By

Some Visual Studio Tips and Tricks

Editorial Note: I originally wrote this post for the SmartBear blog.  

Last month, I wrote a post about integrated development environments (IDEs).  As mentioned in that post, developers commonly debate the relative merits of lightweight text editors against heavyweight IDEs.  But I suspect just about everyone can agree that if you do plan to use an IDE, you should maximize its utility.  In other words, as long as you’re incurring the overhead, you should reap the benefits.

I work a great deal in the .NET space, which means that I spend a good bit of time using Visual Studio, an extremely heavyweight IDE.  In the interests of full disclosure, I will admit to loving to work with Visual Studio.  But that love has grown out of years of exploring it, tinkering with it, and learning to maximize my efficiency with it.  If not for all that, it would seem only a glorified text editor that takes a lot longer than Notepad++ or Sublime to start.

Today, I’d like to offer some suggestions for getting more mileage out of Visual Studio.  By no means is this an exhaustive list; that would require books and books, rather than a single blog post.  Visual Studio has tons of capability.  Rather, today, I’ll offer some tips and tricks you might not have seen previously.

Read More

By

Managing Code Analysis Statistics with the NDepend API

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  Also, NDepend just released a new version that addresses tech debt extensively — check it out while you’re there!

If you’re familiar with NDepend, you’re probably familiar with the Visual Studio plugin, the out of the box metrics, the excellent visualization tools, and the iconic Zone of Uselessness/Zone of Pain chart.  These feel familiar to NDepend users and have likely found their way into the normal application development process. NDepend has other features as well, however, some of which I do not necessarily hear discussed as frequently.  The NDepend API has membership in that “lesser known NDepend features club.”  Yes, that’s right — if you didn’t know this, NDepend has an API that you can use.

You may be familiar, as a user, with the NDepend power tools.  These include some pretty powerful capabilities, such as duplicate code detection, so it stands to reason that you may have played with them or even that you might routinely use them.  But what you may not realize is the power tools’ source code accompanies the installation of NDepend, and it furnishes a great series of examples on how to use the NDepend API.

NDepend’s API is contained in the DLLs that support the executable and plugin, so you needn’t do anything special to obtain it.  The NDepend website also treats the API as a first class citizen, providing detailed, excellent documentation.   With your NDepend installation, you can get up and running quickly with the API.

Probably the easiest way to introduce yourself is to open the source code for the power tools project and to add a power tool, or generally to modify that assembly.  If you want to create your own assembly to use the power tools, you can do that as well, though it is a bit more involved.  The purpose of this post is not to do a walk-through of setting up with the power tools, since that can be found here.  I will mention two things, however, that are worth bearing in mind as you get started.

  1. If you want to use the API outside of the installed project directory, there is additional setup overhead.  Because it leverages proprietary parts of NDepend under the covers, setup is more involved than just adding a DLL by reference.
  2. Because of point (1), if you want to create your own assembly outside of the NDepend project structure, be sure to follow the setup instructions exactly.

A Use Case

I’ve spoken so far in generalities about the API.  If you haven’t already used it, you might be wondering what kinds of applications it has, besides simply being interesting to play with.  Fair enough.

One interesting use case that I’ve experienced personally is getting information out of NDepend in a customized format.  For example, let’s say I’m analyzing a client’s codebase and want to cite statistical information about types and methods in the code.  Out of the box, what I do is open Visual Studio and then open NDepend’s query/rules editor.  This gives me the ability to create ad-hoc CQLinq queries that will have the information I need.

But from there, I have to transcribe the results into a format that I want, such as a spreadsheet.  That’s fine for small projects or sample sizes, but it becomes unwieldy if I want to plot statistics in large codebases.  To address this, I have enlisted the NDepend API.

Read More

By

Logging the Lights in Your Home

Editorial Note: I originally wrote this post for the LogEntries blog.  You can find the original here, at their site.  While you’re there, check out the log aggregation service they offer and see if you could use some help storing and querying your log files.

It’s all the rage these days under the general heading of “Internet of Things” (IoT), but I have been a home automation enthusiast for more than 10 years now.  In the interceding time, I’ve done experiments and written about the subject.  I even published a Pluralsight course, in which I turned a Raspberry Pi into a RESTful server that lets you turn lights in your house on and off using basic X10 technology.  You can certainly say I have a lot of experience, both with newer techs and comparably archaic ones.

Because I’ve been in the game so long, you might think that I’m a strict constructionist, if you will, wanting to build everything myself from raw parts.  But I’m not.  Even though I enjoy assembling these systems from their components, I am a fan of the strides made by various vendors over the years, and I’m thrilled to see different players enter the space and expand home automation mind share in the general public.  In fact, I’m excited as a technologist that I can leverage already-assembled techs and services to achieve my home automation goals.

Introducing Wink

Against this backdrop, my mom recently gave me a Wink hub and companion lights for my birthday.  Wink is a service that does what I once quixotically sought to do in my spare time on weekends: it unifies disparate smart devices to allow centralized control over them.  The hub is synced with the Wink service in general, allowing control from anywhere, and the hub communicates over house Wifi with the satellite devices.  I can now turn on a couple of lights from anywhere in the world, with the workflow occurring as follows.

  1. I pop out my phone while vacationing somewhere sunny, open the Wink app, and tell it to turn on my master bedroom light.
  2. The Wink app phones home to the wink servers, communicating this request.
  3. The Wink servers pass the message on to my connected Wink hub at home.
  4. The Wink hub relays the message over Wifi to the light, which turns on.

It’s really pretty slick.  It also causes me a wry smile of amusement, since I just got a birthday gift that does out of the box something I worked for months to make happen.  But then I trade that smile for a genuine one when I think about how much more I can do in this landscape.

Read More