Question

Does someone know any way to organize the logging statements more conveniently?

I guess there is no such way, but, well, here is a small example:

        // Take the longest path in the graph and convert it into the
        // image series, note that we project every element from the
        // sequence into the image path so that 'new Series(...)' constructor
        // could be used.
        var paths = EnumerateSimpleAndLoopedPaths().ToList();

        logger.Log(Something1);

        if (paths.Any())
        {
            // Take the longest possible path.
            var selectedPath = paths.OrderBy(x => x.Count()).Last();

            logger.Log(Something2);

            var imagesForSelectedPath = selectedPath.SelectMany(...

Obviously those logger.Log or Log or whatever statements are just like rubbish for the main code part, maybe there is a smart way to take them somewhere?

I know there are some nice packages, like PostSharp, which allows logging to be done before and after – but what if functions have to log some intermediate result of their work?

Or is this just a decomposition problem and I should make everything more decomposed so that I could mark all those loggable entries as [Loggable]?

Any suggestions would be appreciated. What do you do with logging in your code?

Answer 1

How about divided the inner logic of method to additional private methods to do the intermediate work,

or, if you don’t want to end up with too many methods on class that can only be used in one place, …

define an inner class to do the work (which automatically can access private members of parent class, if you pass reference to parent to inner class’s constructor).
The inner class can have many private methods that can be accessed only by methods on the inner class. So define one public/internal method on inner class, to be called by method on outer class.

With both approaches, you can decorate new methods with attributes for AOP (e.g. PostSharp).