1. 6
  1.  

  2. 2

    I see a few issues with a system like this, as opposed to LOG/DEBUG/INFO/WARN: [] too few levels (this is only a problem on bigger systems) [] it needs to be explained (one could probably figure most of it out given enough of the logs, but not based on limited chunks) [*] non-standard: doesn’t work with existing frameworks, isn’t immediately familiar, and won’t work with tools that expect logs formatted in another way

    Nonetheless, the succinctness and simplicity are appealing enough that I might start doing this for my own projects. This is an awesome system for its intended use.

    1. 2

      I guess I should have clarified – this is for software I “own”, i.e. mostly my own personal projects and internal tools.

      It may not be immediately familiar, but now I have an explanation online I can point people to ;)

      1. 2

        It is pretty clear that you only use it internally; I was just trying to hypothesize whether it would be feasible to use this scheme on a wider scale, and I think it would if you could gather a critical mass of code that follows it.