In case you folks did not see this. Linus Torvalds thinks 80 column limit
is bull-shit. I don't agree, and I would like to stick with the UX
researchers who say blind or near-blind people have an advantage at 66
chars per line. I don't think he is an expert, he also says get faster
machines -- the fact he is running Threadripper with 64 cores and compiles
kernel under 10 seconds perhaps gives him a different perspective.

But as usual, He writes with great conviction and it is lovely to read,
even when I personally do not agree in this instance.

https://lkml.org/lkml/2020/5/29/1038

Thanks
Anu


On Fri, May 29, 2020 at 5:42 AM István Fajth <fapi...@gmail.com> wrote:

> Hi Marton,
>
> thank you for your comments, though it does not really what I have
> expected, as I still don't know why 120, but at least I have someone else
> who support the limitless idea.
> Yesterday we had a short discussion about this topic with Siddharth Wagle
> and a few others, and he had some interesting arguments against limitless,
> let me share my understanding of the major argument and hopefully he will
> chime in to correct me if I got it wrong.
>
> The major problem with the limitless approach is that it brings style
> related discussions to the code reviews, with that increases the
> responsibility of the reviewers, and brings up discussions about wrapping a
> line or not, this can lead to longer reviews and endless debates about
> wrapping. He mentioned that Ambari had limitless style once, but after this
> happened a few times and after having very long lines in the codebase it
> went back to the 120 rule.
> After I envisioned a word without a clear rule on this, I got hesitant a
> bit, not because of the style debates, those can be even useful in my
> opinion, but because of the inconsistency of the code. I would hate to work
> on a codebase which has countless different styles depending on who wrote
> the code and how strongly opinionated the reviewer was on style.
>
> This brings me back to Anu's argument about consistency. It is comfortable
> for me if either the line length is limitless with a good culture to hold
> the lines under a reasonable size and consistent with the existing code or
> 120 or 80, but I fear mixed.
>
> Consistent style certainly helps understanding, and if we start to write
> new code with limit set to 120, we loose the consistency, and we will end
> up with a mixed style code. Still it is hard for me to switch between parts
> that were mainly tailored by different people, as the coding style, and the
> common thinking is different behind the code, and that sometimes make my
> mind fart when I need to switch between code organisational logics, if we
> add line length differences to the mix, it might be even harder sometimes.
> This is why I would stick to consistency, and as the project started with
> 80 characters I would stick to that.
>
> On naming, yes, I agree with you too short names does not help, and yes,
> they are worse then too verbose names, this makes naming really a hard
> thing, I don't know if there is a good solution, but I have a thought I
> would like to share and see if this brings any new possibilities to the
> table in this debate. Even I am sceptical a bit how it would work, and does
> not bring too much overhead, but on the other hand this seems to be a good
> approach to have more freedom, but still in a consistent way as I see.
>
> The idea comes from the fact that some of you whom I have talked with about
> this change expressed that 80 is usually fine, and there are those lines
> where a few character slips, or where it would be great to have a longer
> name, but that brings in a strange wrapping, not to mention the verbosity
> of the language especially around variable and method declarations (looking
> at you generic, and modifiers).
> What if we kickstart writing a list of things that we value, in a
> developers code of conduct like document, and expect all developers to
> either start a debate if something is not right in this document, or write
> code according to the code of conduct.
> I think about other things here not just the length of the lines, like what
> is we see as an integration test, when to write integration tests, where to
> use minicluster and where to use mocks, where is the point where we prefer
> a builder instead of many constructor parameters, when it is appropriate to
> refactor a code, what we think about backward compatibility, but even such
> low level things like preferring for loops over stream api or the opposite,
> or in which case which one is preferred... I think many of us can continue
> the list.
> In a document like this I can imagine to have a guideline that says: "In
> general we commit to stick with 80 characters, but we allow exceptions to
> happen in some cases like declarations (variable, method, class, for loop),
> imports, and in every other extreme case where easing the rule by a few
> characters helps to avoid wrapping. Still to have a consistent look, and
> give developers the chance to form a screen layout where they don't need to
> scroll we hard limit the lines to 120."
> With this guideline in mind, and accepted as our code of conduct, it would
> be easy to argue in a review where a line is too long, like 110 characters,
> but it does not fit to any of the exceptions we allow, and with this
> approach most of the problematic points of both sides may be addressed...
> or is this something which will/can not work?
>
> Pifta
>
> Elek, Marton <e...@apache.org> ezt írta (időpont: 2020. máj. 29., P,
> 11:47):
>
> >
> >
> > 1. "Why not umlimited?"
> >
> > > This might sound provoking, that is really not my intent, I genuinely
> > > curious and would like to understand why limit ourselves at 120 if the
> > > limit is the problem. Or isn't the limit the problem?
> >
> > I really liked this argument. Yes, this is true. If soft-wrap is
> > powerful enough, we shouldn't use line breaks. I am totally convinced
> > and support unlimited lines from now.
> >
> > Actually I will try to use it in one of my utilities to test if it
> > really works. You made me curious.
> >
> > But 120 is closer to the unlimited, so it's reasonable to support it.
> >
> >
> > > Last but not least two more things to make myself a bit more clear on
> the
> > > naming and typography arguments:
> > > I think naming things properly and limit line length is not
> contradictory
> > > at all, it might seems so, but I tend to think that in all cases the
> > basis
> > > of the problem is verbose naming if there is a problem with line
> length.
> > It
> > > might come from places over which we do not have control, but still...
> > > Verbose naming is one of the big questions/concerns for me and I am
> still
> > > learning not to do that. Still usually I feel I need to tone down
> myself
> > on
> > > this during reviews, and accept that we think about this differently. I
> > > holding back myself now as well, as I can provide a lot of examples for
> > > verbose naming, but I don't want to go off topic too much.
> >
> > Yes, I understand this, and partially agree. I think Spring was famous
> > about these, using class names like
> > SimpleBeanFactoryAwareAspectInstanceFactory and
> > AbstractSingletonProxyFactoryBean (google for more).
> >
> > But I also have different colors:
> >
> >   1. I think the too short name is worse than the too verbose name
> >
> >   2. It's hard to define which line length helps better to find the
> > balance between too verbose and too short. It also depends from the
> > exact code location (condition? method call?). I found 80 too short to
> > choose verbose name a few times (but be honest, 80% of the time it was
> > fine.)
> >
> >
> > Thanks to share these arguments,
> > Marton
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org
> > For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org
> >
> >
>
> --
> Pifta
>

Reply via email to