String extensions using LINQ

Some days ago, I encountered this C# code which defines some more or less standard string operations:

using System;
 
namespace My.Extensions
{
    public static class StringExtensions
    {
        public static string Left(this string s, int count) {
            if(count > s.Length) {
                return s;
            }
 
            return s.Substring(0, count);
        }
 
        public static string Right(this string s, int count) {
            if(s.Length <= count) {
                return s;
            }
 
            return s.Substring(s.Length - count, count);
        }
 
        public static string Shorten(this string s, int count) {
            if(s.Length < count) {
                return String.Empty;
            }
 
            return s.Substring(0, s.Length - count);
        }
    }
}

Personally, I don’t like this kind of implementation. It looks too technical to me. The string manipulations, the condition checks – it’s completely from a technical point of view.

There is a way to implement that functionality in a descriptive way which makes it look more aesthetic. The key is to understand a string as a sequence of characters. Let’s try to rewrite the extension methods using LINQ:

using System.Linq;
 
namespace My.Extensions
{
    public static class StringExtensions
    {
        public static string Left(this string characters, int number) {
            return new string(characters.Take(number).ToArray());
        }
 
        public static string Right(this string characters, int number) {
            return new string(characters.Skip(characters.Length - number).ToArray());
        }
 
        public static string Shorten(this string characters, int number) {
            return new string(characters.Take(characters.Length - number).ToArray());
        }
    }
}

Better? In my eyes, yes! The code is shorter, it looks more precise. The core part of the methods is extremely descriptive. The methods meet their respective purpose by taking or skipping a certain number of characters of the input string – nice.

Unfortunately, there is one thing that is not so nice. There is some noise in the above implementation. We are forced by the .NET framework to switch from IEnumerable to string making a detour via an array of char. But by introducing another extension method, we make our short code example a little bit more readable again:

using System.Collections.Generic;
using System.Linq;
 
namespace My.Extensions
{
    public static class StringExtensions
    {
        public static string Left(this string characters, int number) {
            return characters.Take(number).AsString();
        }
 
        public static string Right(this string characters, int number) {
            return characters.Skip(characters.Length - number).AsString();
        }
 
        public static string Shorten(this string characters, int number) {
            return characters.Take(characters.Length - number).AsString();
        }
    }
 
    public static class EnumerableExtensions
    {
        public static string AsString(this IEnumerable characters) {
            return new string(characters.ToArray());
        }
    }
}

And exactly this is the driving force behind all the code changes we made here: readability! Code should be simple, readable, and self-explanatory.

So, what’s left? With respect to self-explanation, we maybe can find better names for the string extension methods. As the saying goes, I leave this as an exercise for you…

Just to mention, the original implementation as well as the one developed here satisfies this specification:

using Microsoft.VisualStudio.TestTools.UnitTesting;
 
namespace My.Extensions.Tests
{
    [TestClass]
    public class MyExtensionsSpecifications
    {
        private const string Abcdefghij = "abcdefghij";
 
        [TestMethod]
        public void The_first_5_characters_of_abcdefghij_are_abcde() {
            Assert.AreEqual("abcde", Abcdefghij.Left(5));
        }
 
        [TestMethod]
        public void The_first_50_characters_of_abcdefghij_are_abcdefghij() {
            Assert.AreEqual(Abcdefghij, Abcdefghij.Left(50));
        }
 
        [TestMethod]
        public void The_last_3_characters_of_abcdefghij_are_hij() {
            Assert.AreEqual("hij", Abcdefghij.Right(3));
        }
 
        [TestMethod]
        public void The_last_20_characters_of_abcdefghij_are_abcdefghij() {
            Assert.AreEqual(Abcdefghij, Abcdefghij.Right(20));
        }
 
        [TestMethod]
        public void abcdefghij_shortened_by_4_characters_is_abcdef() {
            Assert.AreEqual("abcdef", Abcdefghij.Shorten(4));
        }
 
        [TestMethod]
        public void abcdefghij_shortened_by_12_characters_is_an_empty_string() {
            Assert.AreEqual(string.Empty, Abcdefghij.Shorten(12));
        }
    }
}

When a debugger is needed

Something became clear to me when I attended a Code Review last week. The code we reviewed was written by a co-worker who is quite new in the business, i.e. who passed his academic studies not long ago and has never worked as a software developer before – so let’s call him a newbie. And of course, there was this unbelievable implementation of a class method: All concerns were present in that single method, and you may imagine the length of that method.

So I asked, why all these things are in one single method. His answer was that it is difficult when the debugger jumps from method to method and from class to class. So, it would be better to have it all in one method. Having the logic spread over the whole solution appeared too difficult to him. He needed the debugger to understand what was going on.

Now, what do I have learned from that?

A debugger is needed when the code rules us, when we don’t understand the code just by reading it. It should be vice versa: We should rule the code! Then, no debugger is needed to understand the code.

So, let’s rule the code! I am quite sure you know what you have to do to obtain that.

(Just a short note: A debugger may be used during talks or Code Reviews when you want to show some internal states or just to demonstrate something. Or as the last resort when hunting a bug. In my eyes, these are scenarios where a debugger is useful.)

Guia: A new tool for automated UI testing

I have started to play around with UI Automation in order to write automated UI tests. There is a lot to do for a setup of such tests. So I am wondering if there is already a framework for this purpose. After asking the internet a bit I found Guia on Codeplex. It seems to be the right tool for us. The key features from my point of view are:

  • It works with WPF and WinForms.
  • No compiled application is needed, windows and user controls can be tested stand-alone.
  • NUnit is supported.

The project is on a very, very early stage. So I keep an eye on it for it really seems to be a useful thing for us.

Update (29 July 2011):
Sadly, the project does not make any progress at all. We have meanwhile implemented our own framework which of course fits our needs perfectly.

Gandalf the White (in CCD terms)

By reaching the final white CCD degree I put on my white wristband today. So, from now on I have to obey all the principles and practices that the previous CCD degrees comprise. That is quite challenging in my eyes, for I have to keep an eye on many aspects of the whole development process. But it is worth it! It is obvious that my code has become cleaner since I read Uncle Bob’s Clean Code which was the source for the CCD idea.

Regarding the title of this post, it really feels like being on the developer’s next evolution level. Many things have become clearer to me. As I wrote before, most of the clean code ideas are not new, but they are brought together and verbalised in a quite concise way now.

One of the main points of the CCD approach is the perpetual focusing on a subset of the CCD principles and practices, i.e. on the different CCD degrees. That means, although having reached the final degree and thus keeping in mind all principles and practices, one works on the “coloured” degrees with their specific focus again and again. This is because repetition is a good teacher. Additionally, the principles and practices are not fixed, they are changed or modified from time to time. For example, the degrees comprised rules at the beginning; these have merged into the principles and practices completely.

Definitely, I will follow this track!

The CCD blues

Today, I started to work on the blue CCD degree. It is the 5th and last sectional one.

Thus, I currently focus on these principles and practices:

  • Principles
    • Architecture and Implementation do not overlap
    • Implementation reflects Architecture
    • YAGNI (you ain’t gonna need it)
  • Practices
    • Continuous Integration (Setup & Deployment)
    • Iterative Development
    • Component-oriented Development
    • Test First

Here, we find a perspective slightly apart from the mere coding. Principles and practices both point out in their own way the relation of design/architecture on the one hand and realisation/implementation (in terms of program code) on the other. Design/architecture may be regarded as being one abstraction level higher than realisation/implementation.

The principles make you keep an eye on the distinction between architecture and realisation. In my point of view, at least the component-oriented development practice can be seen as a result of the implementation reflects architecture principle.

Besides architecture, other aspects of the software development process are involved here. Iterative development and test first address specification: Tests can be regarded as some sort of specification; iterative development results from continuous specification refinement. Finally, continuous integrations reminds you to install an automated setup and deployment mechanism here.

Just to mention it: The YAGNI principle is quite important, so it is repeated within the blue degree.

In summary, this CCD degree focuses on the embedding of the coding part in other aspects of the software development process such as specification, deployment, and architecture.

Green is my current CCD degree

I have reached the upper half of the ladder. (I do not count the CCD black degree.)

Green is the 4th CCD degree and emphasises:

  • Principles
    • Open Closed Principle
    • Tell, don’t ask
    • Law of Demeter
  • Practices
    • Continuous Integration (Build & Test)
    • Static Code Analysis (Metrics)
    • Inversion of Control Container
    • Share experiences

The principles focus proper class design and lead to loose coupling. The same is true when making use of a container. Continuous integration and metrics increase productivity, for they check your software quality automatically. Once more, there are no rules at this degree.

I think I can rush through this degree, because I use these principles and practices (almost) every day. There is one exception: I have to get more interested in the code metrics, for I have really lost sight of that.

Sharing experiences – that is what a blog is for, isn’t it?

Now it’s CCD yellow degree

I started to wear my yellow CCD wristband today. So my focus is on the principles and practices of the 3rd CCD degree currently.

The yellow degree emphasises:

  • Principles
    • Interface Segregation Principle
    • Dependency Inversion Principle
    • Dependency Injection (without Locator or Container)
    • Liskov Substitution Principle
  • Practices
    • Automated Unit Tests
    • Mockups
    • Code Coverage Analysis
    • Partiticipation in technical conferences and meetings

Here is my attempt of a very short subsumption as I did in my post on the previous degree: The principles of the yellow degree support proper design and architecture, they enhance testability in the same way. This is required for the practices (except the participation in conferences), for these concentrate on (automated) code testing. (There are no rules here.)

Stefan Lieser told me, that together with Ralf Westphal he tried to build thematic bundles for each CCD degree. As I can see so far, they did a good job.

Once more, I am aware of almost all the elements focussed at my current degree. In general, most of the principles, rules, and practices presented on CCD are well-known. The purpose of a CCD degree is to concentrate on the elements of that degree and to try not to violate them. By this, they hopefully will become second nature to you.

Nice tool: NHibernate Profiler

A few weeks ago, we started to use a new tool by Ayende: The NHibernate Profiler (currently beta). It is a real-time debugger to debug and improve the usage of NHibernate in our modules.

The NHibernate Profiler provides a lot of valuable (technical and statistical) data on the current activity:

  • SQL statements per session with additional information: Details, stack trace, and alerts. Alerts are some warnings which Ayende explains on his website.
  • A session usage report: Number of entities loaded, entities loaded, duration, etc.
  • A session analysis, e.g. View by Method which displays all SQL statements generated by a particular method of a module.
  • Statistics not only on the sessions, but also on the session factory.

We have used it several times to see, what our modules using NHibernate internally do. In particular, the alert information have been extremely valuable for us.

Obviously, there are still some minor bugs in the beta version of the tool. For example, we get a Use of implicit transactions is discouraged alert although we only have explicit transactions.

Usage

In order to debug an application, the client for monitoring the activity has to be started. This client provides all the information explained above.

The best way to make your application communicate with the client is to use log4net, for the application (and the solution/project) does not need to be changed in any way in this case (provided that you already use log4net in your application). Just add an appender in the log4net.config file and make the required loggers use that appender.

Example:

<appender name="NHibernate.Profiler" type="HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfilerAppender, HibernatingRhinos.NHibernate.Profiler.Appender" >
  <sink value="tcp://localhost:22897/NHibernateAppenderLoggingSink" />
</appender>
 
<logger name="NHibernate.Transaction.AdoTransaction">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.Loader.Loader">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.SQL">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.Impl.SessionImpl">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.Persister.Entity.AbstractEntityPersister">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>

As this example shows, the profiler appender class has to be referenced and a TCP sink for the communication with the client has to be declared. The defined loggers redirect the required information to the profiler. Finally, the DLL containing the profiler appender class has to be stored in the application directory. That’s all. When running the application, the NHibernate activities are monitored by the client.

You can (and due to the licence, you probably must) ship your application without the profiler appender class DLL. There is no need to modify the log4net.config file, though. The profiler appender does not have to be removed. log4net just complains (within its log file), that the particular appender could not be instantiated (because it was not found). If you do not want that message in the log file, you have to ship your application with a log4net.config which does not contain the profiler appender.

Another way to use the profiler is to reference the HibernatingRhinos.NHibernate.Profiler.Appender.dll and make the following call within the application startup:

HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfiler.Initialize();

But as this means a change of the application code and requires a reference within the project, I do prefer the first kind of usage. Additionally, the application cannot be shipped when modified in this way. (Remember, you may not ship the profiler appender class DLL with your application.)

Now working on CCD orange degree

I have mentioned the Clean Code Developer (CCD) and its idea earlier. After having worked on the red (1st) degree so far, I am currently focusing on the principles, rules, and practices of the orange (2nd) degree.

The orange degree emphasises:

  • Principles
    • One level of abstraction
    • Single Responsibility Principle
    • Separation of concerns
  • Rules
    • Source code conventions
  • Practices
    • Issue tracking
    • Automated integration tests
    • Read, read, read
    • Reviews

A two sentences subsumption: The principles and rules of the orange degree support readability and understanding of source code. The practices are related more or less to the soft skills of a software developer.

The first degree was comparably easy, because I was already aware of most of its elements. Nevertheless, it took me almost two months not to violate the 21 day rule, which says, that you may not violate any of the aspects of your current degree for that time span before you go on to the next degree.

Just one remark: CCD defines professionalism for a software developer. The application of what is said there leads straight to better (i.e. higher quality) software. It was not expressed that explicitly in my first post on CCD. But it seems important to me.

Clean Code as fundament for professional software development

As a software developer, don’t we seek for more professionalism? But the question is rather: What does professionalism mean in this context?

The Clean Code Developer (German website) can be an answer for the latter question. That site was initiated by Stefan Lieser and Ralf Westphal. For them, there are two aspects which define a professional software developer. Such a professional

  • reflects, if he is satisfied with what he does and has done, and therefore
  • has an internal value system.

Ralf and Stefan want to define what the attitude of a professional programmer towards his work should be and how he should work. This definition is expected not to be complete, i.e. they expect changes of it due to new insights. But it should be mentioned that one of the very basic concepts is reflexion.

Ralf and Stefan took their ideas from the book Clean Code by Robert C. Martin, which I already had in my shelf before I got notice of the Clean Code Developer site. The content of this (very good) book is not really new. Rather, it is a compilation of known principles, rules, and practices for the field of software development. And so the purpose of the Clean Code Developer site is to gather these concepts and thus to be a guideline for developers who want to be professional.

A Clean Code Developer (CCD) runs through different degrees. Each degree sets the focus on a subset of the principles, rules, and practices. The degrees are represented by colours, starting with black and ending with white. If you have the feeling, that you really regard all the aspects of a certain degree, you can go on to the next one. (There is no exam to pass. You are responsible for yourself.) Currently, I am working on the red degree, which of course is the real entry point for a prospective Clean Code Developer. I am convinced by what Ralf and Stefan are trying to establish as well as I was by Robert’s book.

Keep your code clean!


Worth to be read:

Clean Code CoverMartin, Robert C.: Clean Code. A Handbook of Agile Software Craftsmanship.
Prentice Hall, 2009.
ISBN-13: 978-0-13-235088-4
ISBN-10: 0-13-235088-2