Today we came across a very simple rounding problem: round a number up to the nearest 0.05.
A quick search came up with quite a few hints, but no concrete answer. So we rolled our own. Here’s the code.
using System;
namespace Util
{
public class MathHelper
{
public static double RoundNumberUp(double number, double roundingFactor)
{
double rounded = RoundNumber(number, roundingFactor);
if ((number - rounded) > 0)
{
rounded = rounded + roundingFactor;
}
return rounded;
}
public static double RoundNumber(double number, double roundingFactor)
{
double rounded = Math.Round(number * (1 / roundingFactor)) / (1 / roundingFactor);
return rounded;
}
}
}
And here are the tests, which show how to use the class.
using NUnit.Framework;
using Util;
namespace Util.Tests
{
[TestFixture]
public class MathHelperTests
{
[Test]
public void Should_round_a_number_up_to_the_nearest_0_05()
{
double result = MathHelper.RoundNumberUp(6.66, 0.05);
Assert.AreEqual(6.7, result, 0.001);
result = MathHelper.RoundNumberUp(6.7, 0.05);
Assert.AreEqual(6.7, result, 0.001);
result = MathHelper.RoundNumberUp(6, 0.05);
Assert.AreEqual(6, result, 0.001);
result = MathHelper.RoundNumberUp(6.13, 0.05);
Assert.AreEqual(6.15, result, 0.001);
result = MathHelper.RoundNumberUp(6.18, 0.05);
Assert.AreEqual(6.2, result, 0.001);
}
}
}
Hope this comes in handy! Bye for now.
Earlier this month me and a few guys at work decided to delve head first into test driven development. We had always done things the old fashioned way and decided it was time to catch up with more robust development techniques.
We knew it would be painful at the beginning, but the rewards of TDD are too good to ignore. And painful it was… At first development was extremely slow! Thinking about what to test was difficult. Thinking about how to test was also hard! But we persevered, moving slowly from one test to the next, and testing each new class and method as we invented them.
I think it was about one week in, that this experiment started to bear real fruit. We started to notice that, in the process of developing the tests, we were designing our program from the outside in. This reminded me of something Jean-Paul Boodhoo has repeated over and over in various screencasts: In writing the tests for our programs we are actually driving out the design of our programs!
The most obvious benefit of the TDD approach is adherance to the YAGNI agile principle. It is often very tempting to write some code which solves a problem that you have anticipated. The problem with this is that you may well NOT need this code! TDD overcomes this anticipation by dictating that you write only the code needed to satisfy your tests. At the start this can feel restrictive, but as you move on this becomes liberating.
The second obvious benefit of TDD is that you tend to write functional, loosely coupled code. By starting from class names, then filling in the gaps with the methods you need, I have found that I am creating more useful classes with less bloat. When you specify a method you are forced to think carefully what parameters you should be passing to it and what object, if any, it should return.
The approach of designing classes from the outside is totally different than designing them from the inside. I’d say you get a birds eye view over your software when using TDD. This is far better than forever being bogged down by tiny details…
All in all I’d say I’m now a huge fan of TDD!! I’m still taking baby steps, but the more I use agile development techniques the more I see the huge benefits!
Recommendations:
Agile Principles, Patterns, and Practices in C# by Robert C. Martin.
dnrTV! – Check out the episodes with JP Boodhoo and Venkat Subramaniam!
DotNetRocks! – A twice weekly .NET podcast.
I recently had the need to store strings in a database in a compressed format. I wanted to store some potentially long strings in a SQL server image type column. After some time searching the internet for solutions I came across a neat .NET namespace called System.IO.Compression which looked like it could be the answer to my problem…
Here is the helper class I wrote to perform compression and decompression:
using System.Collections.Generic;
using System.IO;
using System.IO.Compression;
using System.Text;
namespace Utility
{
public static class CompressionHelper
{
public static byte[] CompressText(string text)
{
byte[] buffer = Encoding.UTF8.GetBytes(text);
MemoryStream compressedStream = new MemoryStream();
DeflateStream compressedZipStream = new DeflateStream(compressedStream, CompressionMode.Compress, true);
compressedZipStream.Write(buffer, 0, buffer.Length);
compressedZipStream.Close();
compressedStream.Position = 0;
byte[] compressed = new byte[compressedStream.Length];
compressedStream.Read(compressed, 0, (int)compressedStream.Length);
return compressed;
}
public static string DecompressText(byte[] compressed)
{
MemoryStream compressedStream = new MemoryStream(compressed);
DeflateStream zipStream = new DeflateStream(compressedStream, CompressionMode.Decompress);
List<byte> bytes = new List<byte>();
int offset = 0;
while (true)
{
byte[] temp = new byte[offset + 100];
int bytesRead = zipStream.Read(temp, offset, 100);
if (bytesRead == 0)
{
break;
}
for (int i = offset; i < offset + bytesRead; i++)
{
bytes.Add(temp[i]);
}
offset += bytesRead;
}
return Encoding.UTF8.GetString(bytes.ToArray());
}
}
}
Of course you could argue that this class is too specialised right now. It served my purpose well, but you could take and return byte arrays or streams as parameters to make it more general and re-use friendly.
Please let me know if you find any bugs…
Enjoy!
