kirk.pepperdine at gmail.com
Wed Apr 11 14:38:11 UTC 2018
Mind if I bike shed on this one since everyone else it?
A tab is white space of undefined length. Traditionally, tabs are the responsibility of the device (move forward software) to implement. This is why you *set* tabs. As such… it seems very reasonable that people don’t expect nor shouldn’t expect tabs to behave the same on all different devices. Meaning, if you want consistent behavior, a tab is not the signal you want to be sending. If we want the indent in our code to be the same all over then the correct signal is a space. That (for fixed width fonts) offers a uniformly sized white space. Note there is no tab/anti-tab rhetoric in here. Tabs are useful, so are spaces. You just need to know what they are so that you can know when it is appropriate to use one of the other.
> On Apr 10, 2018, at 11:18 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> On Tue, Apr 10, 2018 at 1:50 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 3. If the input contains *any* tab characters at all (except any that are
>>> part of the trailing whitespace), then this method cannot know that it
>>> isn't jumbling the end result, and maybe it should just throw.
>> I think there's a middle ground, where it strips any common whitespace
>> prefix. So if every line starts with tab-tab-space-space, it can safely
>> strip this.
> My point is that this is *not* safe, if by "safe" we mean "you will see the
> same relative indentation you saw in the source". *Any* tab has the
> potential to suddenly be worth a different number of spaces, once some
> prefix of any kind has been removed.
> I would *like* to not worry about this, but we have to accept that the
> programmers who will be hurt most will be the most novice.
> 5. If we do end up in a world where we have to call this for almost every
>>> one of our tens of thousands of multi-line RSLs... is it strange that I
>>> feel like I would prefer it was static? It seems like it would look a lot
>>> more normal that way visually. Ugh...
>> I think this is likely to vary subjectively a lot. Some people like that
>> the instance method is mostly out of the way; others like the up-front
>> shouting of the static method.
> Is it just potayto, potahto, or does one of the snippets above appear a lot
> more consistent with how Java code has always looked?
> On top of *that*, I have no idea what "right markers" are good for, nor
>>> what customizing the marker choice is good for (other than creating more
>>> needless variation between different pieces of code).
>> String asciiArtFTW =
>> ` BOO `
>> `````````.trimMarkers("`", "`");
> Ha, well, I did say "good" for :-)
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
More information about the core-libs-dev