On 6 December 2016 at 18:30, Jim Ingham <jing...@apple.com> wrote: > >> On Dec 6, 2016, at 10:20 AM, Pavel Labath <lab...@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 >
I probably haven't read as many logs as you have, but I've done my share. FWIW, I actually believe adding more structure to the logs makes them more understandable. If you have the file name (nicely formatted in a table), then it's easy to ignore it by just scrolling the editor window sideways. And it means you can even grep by it, and remove the unrelated lines completely. I find the log sources which do multi-line log lines moderately annoying (data formatters come to mind mosly, they tend to add empty lines to group things visually), as they assume that they are the ones you care about. If you do it's great, but if you don't, they just break up the flow of the log file for no reason. That said, I like Greg's idea of making the file information a log enable flag, although I am afraid some of the current messages would be somewhat useless without it. pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
