Time is way too precious to waste on poorly-designed tools.

I like to do a lot of things: hiking the beautiful mountains of this state, exploring new hobbies and sports, tinkering with inventions, reading law, science and history.. time is a precious resource. What I do not like to do is waste that time figuring out how to use a logger library. People don't ordinarily set out to log things, per se: they set out to do something substantive, and logging is just an aid toward achieving that end. Unfortunately, trying to use a logging library has been a task that started out with trying to navigate poor documentation and to get a poorly-designed API to work. I just don't have that time to waste. Perhaps you feel the same way.

Thus LogNut.

Sometimes, all we really need is to write a little text into a file while our program is running. Then look at it to figure out where our code is going wrong, or whatever. This should be simple, and fast.

So I have kept this simple.

One simplification is to allow its use with no configuration file. Zero. Just code it and go. Looking at the code in your program, should tell you everything you need to know about what's going on. I have provided for configuration files, for when that would be useful to you. Or to use the Windows Registry to persist your settings. But that's entirely optional.

It should have good, proper Intellisense (I'm talking about while using Microsoft Visual Studio) that tells you, clearly and in proper English, what you need to know about how to use it. It should have good comprehensive documentation. And examples of how to use it.

Compatibility

As there are already some very functional logging libraries out there (Log4Net, NLog, BitFactory) I hate having to re-invent and add yet another API and lingo for developers to have to learn. So, where it makes sense, I tried to keep some compatibility with the major libraries. For example, the "Log Levels" of NLog include Info, Warn, Error, Fatal, Debug, and Trace. Log4Net has the same, except for Trace. LogNut has these same levels as Log4Net (I thought Trace was a bit redundant).

The basic usage is fairly simple. It could be just a bit simpler, if one didn't need multi-threaded operation or automated unit-tests. But at least the API for basic usage is no more complex than the existing libraries. For example, in NLog you have this basic code snippet to instantiate a logger:

using NLog;

Logger logger = LogManager.GetLogger("MyLogger");

You use LogNut the same way:

using LogNut;

Logger logger = LogManager.GetLogger(); // or you can use ("MyLogger") as well.


As far as the configuration files are concerned -- I wanted to keep that as an option, but the format of the existing libraries seems a bit ponderous to me. XML is a wonderful, simple data-definition nomenclature, and C# has the wonderful feature of being able to persist a class with a simple call to a built-in serializer. Why not just keep it as simple? Thus you will see a description of an XML format that is different, in that it is really simple.

API Consistency

To design the best API possible requires a constant evolutionary process of adding new functionality while at the same time striving toward a simple, symmetric, consistent design. I did add features. And then found that some concepts were expressed differently - so I went back and refactored for consistency. That is the advantage of a new design that is not burdened with the need to maintain strict compatibility with legacy code - you can evolve it freely to be the best that it can be.

For example, all properties that return a boolean value, start with "Is", and those that turn something on or off have "Enabled", as in "IsFileOutputEnabled". Methods that do something, have an action-verb that expresses this clearly. All properties and methods related to file output, include "File" within its name. I have striven to make the names clearly state their purpose, at the expense of sometimes having longer names.

Last edited Oct 24, 2012 at 5:20 AM by JamesHurst, version 6

Comments

No comments yet.