NDepend

Improve your .NET code quality with NDepend

Month: February 2018

How to Measure Lines of Code Let's Count the Ways

How to Measure Lines of Code? Let’s Count the Ways

There are a few ways to count lines of code, and they each have their advantages and disadvantages.

Much of the differences come down to defining what a “line” is. Is a line a literal line in the source file, a logical statement in the language we’re using, or an executable instruction?

Let’s take a look at three metrics:

  • Source lines of code—the number of lines of code in a method, skipping comments and blank lines
  • Logical lines of code—the number of statements, ignoring formatting  and often counting a line as more than one statement
  • IL instructions—the number of instructions that the code compiles to

Is one better than the other? It depends on what you’re trying to measure.

Continue reading How to Measure Lines of Code? Let’s Count the Ways

Your Guide to Winning Arguments About Code

Your Guide to Winning Arguments About Code

The whole “tabs versus spaces” thing occupies sort of an iconic position in the programmer world.  It represents the impossibility of winning arguments that are unwinnable by their very nature.  These are so-called religious wars — our techie version of The Butter Battle Book but without the Cold War overtones.

But this and arguments like it rarely actually play out in team rooms and offices.  At least, that’s always been my experience.  I’ve only ever witnessed live “tabs versus spaces” arguments happen ironically.

Actual Arguments in the Programmer World

So here’s how it really goes down.

You take a job with a company, excited about the new office, the shorter commute, and the bump in pay.  You’re riding high.  But then the onboarding starts with the codebase.

Greg, the most senior member of the group, walks you through the codebase with a slightly smug affect of obvious pride.  The codebase has everything you could ever want, according to Greg.  To your mounting horror, this includes

  • Inheritance hierarchies that are inscrutable, dark, and deep (with miles to go before you sleep).
  • A generous portion of global state.
  • Liberal use of reflection, often for no discernible reason.
  • And, of course, an extensive, homegrown “framework.”

Greg finishes with a flourish: “So, anytime you need to add a new feature, you just open GodClass.cs, scroll down to line 12,423, add another method, and get started!”

You’re new, and you’re not entirely sure that this isn’t an elaborate prank, so you swallow and say, “Oh…great!” while already planning the lengthy suggestions document that you’re going to put together.  And so the stage is set for what will become a never-ending string of arguments of variable politeness about the codebase.

Swap my hypothetical specifics for yours, but the formula is the same.  Someone is asking you to exist in a codebase that you have philosophical reservations about, which will force you to write code you don’t like.

Winning Arguments: How Does One Define This?

I’ve now set the stage, but what does it actually mean to “win” an argument?  This is pretty hard to define in a lot of contexts, such as people arguing on Facebook about politics or fighting at dinner.  Is it the one who got the last word in?  The one who was louder?  The one who didn’t simply give up?

Luckily, in your quest to de-Greg your new company’s codebase, “winning” is easier to define (if admittedly something of a loaded term).  You win if, by mutual consent, however grudging, the thing you think should happen winds up immortalized in the team’s source control.  And the mutual consent part matters.  Just slamming something into source control and being forced to revert later by an angry Greg doesn’t count.

You win when your argument carries the day and results in concrete action.  So let’s look at some techniques for making that more likely.

Continue reading Your Guide to Winning Arguments About Code

Functional Programming Makes Your Code Not OO...And Thats It

Functional Programming Makes Your Code Not OO…And That’s It

Over the course of the fall and winter, I’ve been gaining momentum with code research posts.  Today, I bring that momentum to bear on the subject of functional programming.  Or at least, on functional style of programming in C# codebases.

But before I do that, let me provide a little background in case you haven’t caught the previous posts in the series.  It started with me doing automated static analysis on 100 codebases to see how singletons impact those codebases.  Next up, I used that data to look at how unit tests affect codebases.  That post generated a lot of buzz, so I enlisted a partner to help with statistical analysis and then boosted the codebase sample size up to 500.

At the end of that last post, I suggested some future topics of study.  Well, now I’ve picked one: functional programming.

What Is Functional Programming?

The idea with this post is mostly to report on findings, but I’d be remiss if I didn’t provide at least some background so that anyone reading has some context.  So first, let’s cover the topic of functional programming briefly.

Functional programming is one of the major programming paradigms.  Specifically, its calling card is that it disallows side effects.  In other words, it models the rules of math, in which the result of the function (or method) is purely a deterministic function of its inputs.

So, in pseudo-code, it looks like this:

This is a functional method.  But if you do something like this

or like this

then you’re out of the functional realm because you’re adding side effects.  These two modified versions of Add() each concern themselves with the world beyond processing the inputs to add.  (As an aside, you could “fix” this by passing the global variable or the _databasePlopper dependency to the method as a parameter.)

Now, take note of something because this matters to the rest of the post.  While C# (or any other object-oriented language) is not a functional language, per se, you can write functional methods in C#.

Continue reading Functional Programming Makes Your Code Not OO…And That’s It