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 >
