Bruno Peeters Technical Blog

By default, Windows uses a maximum length for paths that is 260 characters. This includes the drive letter – for example “C:\” – and the terminating null character. So this leaves you up to 256 characters for a path. This limitiation is defined due to the restrictions of the Windows API.

You can however use longer path names, that are up to 32767 characters. Within C#, there are serveral ways to achieve this:

• By adding \\?\ in front of a path;
• Using Windows 10 version 1067 or higher, updating the systems registry and your application manifest.

One of the features I definitely miss within Visual Studio is the ability to close all tabs except a few you want to keep working on. If you are working within two files at the same time, but you have a lot of other files open (read a lot of other open tabs), you have to close the others one by one. You do have an option to speed up this process, which is available within the context menu of the tabs. It is called “Closing All But This”, but it closes also the other tabs you probably want to still be opened. So this means you still have to open again the ones you want to be open. Isn’t there another way to do this within Visual Studio?

When it comes to commit your work to a software versioning system like git, and putting a message to the commit, it feels like for most developers this is something that needs to be done but they don’t want to spend much time on it. You see cryptic messages within the commit message, which doesn’t add any real value to it. When looking at the goal of a commit (message), what is needed to achieve this goal? In the end, when having a proper clean commit with an accompanied commit message, it will eventually help you speed up your development process.

In my previous blog post, I wrote about guarding your code style. Here I showed a number of areas where to look for when defining your teams common code style. Also a number of tools where briefly mentioned that could guard these styles. One of these tools is EditorConfig.

When you read a certain magazine or newspaper, you don’t have the feeling that the articles are written by a number of persons each having their own personalities and characteristics. When reading the first article, you can’t decide when looking at another article by looking at the use of words if it is written by the same person or not. The same strategy we see back at clean written code: it will show consistency throughout the solution. If applied well, you can’t tell that some class is written by one developer and another class by another developer.

What is actually the benefit of having all code written down like it is written by the same person? Note that we spent more time reading back code than we spend time at writing the code. If this is the case, you want fellow programmers to quickly grasp the main important things you want to achieve by the code you’ve written. One thing that helps with this is having the same coding style all over the same code base.

NuGet packages eases the reuse of components. A NuGet package can contain different kinds of resources, like libraries, or header files. These resources are packed in a NuGet package. You can use a package in your solution and refer to one of the resources in the package.

During development, it can be convenient to just create your NuGet package locally and test it locally. Therefore you don’t need to set up your own hosting environment, like for example Artifactory, you just can host your packages on a local disk. Although the scenario where you publish your package to an external host is rather described everywhere, the latter one is a scenario that is interesting as a workaround not having to publish your package you are developing directly to an external source.

We will look at how to define the content of your NuGet package, create it, store it locally and eventually consume it.

Within my previous employer, I worked at a startup company, where we created our own hardware, the software that addressed that hardware and a cloud environment. Before that, I once also worked at a startup, where the product contained a video conference application. Taking those experiences into account, I want to look back what I’ve worked during working within a startup.

Agile encourages building software with the end user in mind. It will then help to have a clear and common understanding of this end user within the team. Therefore you can use a so-called persona. Personas represent fictitious people, based on the teams knowledge of the end user. Within this persona you will together write all the details that are of interesting when defining the user stories within your project.

Besides writing unit tests, it is also important to be able to maintain them. To improve the maintainability of a unit test, it is important that you can easily see what it is trying to test and how it does this to accomplish this task. To improve the readibility of your unit test, you can use the most widely accepted pattern within unit testing: Arrange, Act and Assert (AAA) pattern.

Since I see writing code as a craftmanship, I’m also very keen on writing high quality code. In the beginning it might take more time to write your code with a high quality, but in the end this will pay back. For sure the bigger a project becomes, more time it will take to add or change functionality or fix bugs in poorly written code.

When it comes to high quality code, of the aspects that come to mind is that it’s clean code. Clean code helps your team to write and maintain in an efficient way your code base. What properties must programming code have to become clean? Robert C. Martin (a.k.a. Uncle Bob), describes in his book “Clean Code – A Handbook of Agile Software Craftsmanship” a number of aspects clean code could have. In this blog, I want to discuss the key takeaways I found within this book.