Adding custom object-string transformers to a global static list field in my logging library. Is there a better way?

Question

I'm writing a central logging library. In it is an AutoLogAttribute method attribute that automatically logs entry/exit of methods and their parameters (automatically serialized) like this:

[AutoLog]
public void GenerateInvoice(string customerId)
{
    ...
}

// Outputs
// af8291: Entering GenerateInvoice with parameters: { customerId: 'GZilla' }
// af8291: Exited GenerateInvoice. Ellapsed time: 480.12 ms

My problem arises when parameters are POJOs that serialize to huge strings.

By default, I want to just ignore any non-primitives and allow users to specify how they'd like serialization to happen.

Importantly, since most objects are POJOs in my case, I can't start requiring extending an interface like ILoggable. Extending ToString() is also undesirable because ideally an object should be reconstruct-able from it.

I was thinking of allowing users to add custom object-string transformers to a global static list field in AutoLogAttribute (e.g. in some initializer code of their app). I know this is a very bad practice. My question is, is there a better way of solving my problem?

public class AutoLogAttribute
{
    // something like this
    public static Dictionary<Type,Func<object,string>> ParameterTransformers { get; private set; }
    ...
}


public class Program
{
    public static void Main(string[] args)
    {
        AutoLogAttribute.ParameterTransformers[Customer.Type] = (c) => c.Id;
        AutoLogAttribute.ParameterTransformers[Order.Type] = (o) => o.OrderNumber;
        ...
    }

    [AutoLog]
    public void ProcessOrder(Customer customer, Order order)
    {
        ...
    }
}

Answer 1

If you want something to affect the application globally, then you will effectively have to use global/static variables in some form.

Bad practices are not dogmas you should religiously adhere to (see also cargo cult programming). You should understand the reason why they are bad, and consider whether those reasons apply in your situation or how could you mitigate them.

One of the reasons why global state is bad is that it can be modified from any place in a program, making it hard to understand what's happening. I don't think that's a big problem here, since the global state is likely going to be set once and then never modified.

There are other reasons why global state is bad (makes unit testing harder, has issues with multi-threaded programs), you should understand those and weigh whether they are relevant in your case and if they are, how to deal with them.