When raising log events in code it can be difficult to choose a severity level (such as Error, Warning, etc.) which will be appropriate for Production; moreover, the severity of an event type may need to be changed after the application has been deployed based on experience of running the application. Different environments (Development (Dev), User Acceptance Testing (UAT), Non-Functional Testing (NFT), Production, etc.) may also require different severity levels for testing purposes. We do not want to recompile an application just to change log severity levels; therefore, the severity level of all events should be configurable for each application or component, and be decoupled from event-raising code, allowing us to tune the severity without recompiling the code.
A simple way to achieve this power and flexibility is to define a set of known event IDs by using a sparse enumeration (enum in C#, Java, and C++), combined with event-ID-to-severity mappings contained in application configuration, allowing the event to be logged with the appropriate configured severity, and for the severity to be changed easily after deployment.
A few years ago, I was working on a project for a UK client who needed to replace or rewrite a legacy inventory management web application written in classic ASP. The problem: no documentation, and complicated, spaghetti source code with many apparently duplicate or redundant ASP files and ASMX web service endpoints.
Which ASP pages were actually in use? We had to find a way to limit our application migration efforts to only those pages which were used by the application. A colleague at the time introduced me to what must be one of the best-kept secrets in the Windows developer world: Microsoft Log Parser.