[lldb-dev] logging in lldb

[Jim Ingham via lldb-dev]

> On Dec 6, 2016, at 10:20 AM, Pavel Labath <labath at google.com> wrote:
> 
>> I think having a convenience to add function name decorators is fine, but we need a way not to do it all the time.  We have logs that don't have function names because they log over several functions, and having the different names adds visual noise, would make the rest of the log impossible to line up nicely, and adds no important information.  You will write log statements infrequently, but you will have to read them much more frequently, so taking a little more effort to make them readable is well worth it.
> 
> What I am optimizing for is readability of the source code (the fact
> that it coincides with "the time to write the log statement" is a
> lucky coincidence). I often find that I am looking at a function which
> spans several screens, even though it doesn't actually do much,
> because half of the function is logging. Normally, I would try to
> split this function up into smaller ones, but I find that the amount
> of work done by the function is actually quite reasonable and
> undivisible, but due to logging it gets spread out enormously.
> 
> I would be fine with some way of inhibiting decorations. But, I want
> to hear what you think about this alternative: Just have file names
> and line numbers always aligned. For lines, we could reserve four
> characters, for filenames 35 (only 7 files currently are longer than
> 35 chars -- these would get truncated, or misaligned, as you see fit).
> 

Take a look at the step logs, for instance, which I have to read all the time.  In that case, when reading them you are trying to follow the logical flow of the stepping algorithm, and there is already a lot of noise there.  In that case, I don't need to know where the log lines come from, that is clear from the log content.  So I definitely not want to have to peer past useless file & line or function information.

And more generally, I do think prioritizing ease of reading (or scrolling past) log statements in code over ease of making them complete and easy to read them is the wrong tradeoff.  The number of hours of my life that have gone into peering at logs far outweighs the trouble of scrolling past "if(log)" blocks when reading code.  If both goals can be achieved, that's great.  And for simple "X was weird" kind of logs, having a nice compact form is great.  But for things like the unwind logs, packet, step or expression logs, you don't want anything getting in the way of laying out the output in the easiest to read form possible.

Jim