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
