Hi, Attila, Marton, I feel really grateful to have your arguments for the 120 characters limit, I enjoyed reading them, as finally the discussion is not just about who supports which limit from the two.
As I stated, I will not go against the majority, and the reason for that is exactly what you have stated, I have tooling that can help me and the option to keep myself short still. (Though I really question the abilities of soft wrap vs intentional wrapping under 80 characters by a human who can think as an other human (like me), and wrap where it makes sense for humans.) On the other hand, I would like to understand an other aspect of the limit debate... Our argument so far was about the differences between 80 or 120 character limit, your arguments as I understand are about why 120 characters as a limit is better than 80, and are coming from the problems you have with the 80 characters limit. So I really would like to understand why you think we should go up to just 120? Problems with 120 will arise similarly as with 80. What would you say for someone who suggests to get rid of this limitation on line length completely? The problem I have is that I see all your arguments as an argument for limitless life as well, soft wrap can be used to wrap if needed, arrangement/font size/monitor size can be changed, limiting at 120 is asymmetric compared to limitless, "you force to use the same approach for everybody", with limitless names can be as long as necessary to explain behaviour, you don't need to wrap a line that can not be shorter than 81 characters (god how much I hate the semicolon at the end of the line that does not fit...). And of course if one thinks it is better, one can wrap at 80 characters or 120 characters still. 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? 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. I see typography and related studies completely differently as it seem. What I think is that the essential thing we do with code is the same that we do with books/papers/websites, we read what other people wrote, we read it in the same medium (monitors) as the websites, so even if I do not find a related study at the moment, I believe there are more commonalities in reading code compared to reading a website. Pifta Shashikant Banerjee <sbaner...@cloudera.com.invalid> ezt írta (időpont: 2020. máj. 21., Cs, 11:15): > I would prefer to increase the line length limit to 120 as i find it more > convenient to work with. > I agree with Attila here. > > Thanks > Shashi > > > On Thu, May 21, 2020 at 2:05 PM Elek, Marton <e...@apache.org> wrote: > > > > > > > Thank you for details description Pifta, I like when we can talk about > > well defined arguments not just about feelings. > > > > > > I don't have very strong opinion about the line length (I learned to use > > 80 as before) but I have opinion about your arguments. > > > > They are mostly identical to Attila's comment, but let me share it. > > > > As far as I understood you had 3 arguments: > > > > > > 1. Even on wider monitor you use a setup where only 80 character can > > be available > > 2. Shorter lines can help to write better / cleaner code > > 3. Studies about reading / typography > > > > > > My view is somewhat different in each points: > > > > (1). > > > > The problem is with using 80, you force to use the same approach for > > everybody. While you can turn on soft-wrap at any time, others couldn't > > enable anything to see the code in longer lines. > > > > I liked this word from Attila: this is "asymmetric" > > > > I tested soft wrap in Intellij and it worked very well (please don't > > forget to enable the "Use the original line's indent for wrapped > > fragments" option). > > > > But what can we offer the people who prefer 120? > > > > (2). > > > > Here, I agree with Attila, again. Why I am very glad that you found a > > way which helps you to create better code, for me it's harder to follow > > the "naming" related 'Clean Code' suggestions. Especially it's very hard > > choose meaningful name which fits in the lines and doesn't make each > > expression 3-4 lines long. > > > > You mentioned the xxx.get()...get()....get() pattern, and I totally > > agree with you to avoid it. (I think it's almost the same as > > https://en.wikipedia.org/wiki/Law_of_Demeter) > > > > But I think it's more effective to force it with the right tools > > (spotbugs/checkstyle) instead of forcing it with line length. > > > > > > (3). Typography > > > > I don't think that the mentioned studies are related. They are related > > to text. As far as I know the unit of the text reading is not the > > characters but the words (or smaller part of the words). One limit which > > can work for web pages and books (I am plus one to keep the 80 on my > > Kindle) may not be true for code, where the words are longer expressions > > and we can have the same amount of information with more characters. (At > > least in Java. I agree that we should keep 80 for the potential Scala > > classses. And limit the usable symbols per lines ;-) ) > > > > > > Summary: > > > > * The problems you mentioned can be solved in different way > > (soft-wrap, codestyle checs) but the problems of the group who prefer > > 120 can not be solved in any other way. > > > > * If 80 is a personal taste and we have no strong technical arguments > > against it, I think we should enable to increase it, and we can view the > > code as before with our personal settings. > > > > > > > I also suggest a small experiment: > > > 1. Go to your IDE > > > 2. Select a big class like OzoneManager > > > 3. Change the line length to 120 > > > 4. Reformat code > > > 5. Start to read code > > > > > > Who thinks it is better that way? > > > > Me. I did it. It looks awesome[1]. At the beginning I wrote that I have > > no strong opinion. Now I have one ;-) > > > > Marton > > > > > > [1] If it's wrapped for you, please adjust "Use the original line's > > indent for wrapped fragments" in the settings. > > > > > > > > > > > > On 5/19/20 4:14 PM, István Fajth wrote: > > > Hi everyone! > > > > > > TLDR: > > > I strongly disagree to increase the limit, you can read my reasons > below, > > > some are personal opinions formed based on a lot of (I think) clever > > > people's thought I read/heard over time. I do not want to block the > > > community to go down this way, and willing to accept the decision if > that > > > is to go with 120 chars per line, but I wanted to explain why I > disagree, > > > and also I would like to see what you think about these arguments. > > > > > > > > > > > > I have the following personal reasons: > > > - in my laptop, I can have two files in IDEA splitted horizontally > with a > > > line length of 80, with 120 I loose this property of our source code > > > - in my big monitor, I can fit 4 different files in IDEA splitted > > > horizontally, or I can have my browser open beside my IDEA on the same > > > screen, with line length of 80, with 120 I loose this property or at > > least > > > I might need horizontal scrolling in the browser > > > - also if the lines are 120 characters long, for me it is harder to get > > to > > > the next line correctly and easily while reading if there are lines of > > code > > > after each other going up to the 120 limit > > > - usual argument for a longer line is long type definitions, long > method > > > names, long parameter lists, or long accesses that spans lines with > > > sthg.get.get.get.set.... like calls, same is stream.map.filter.collect > > that > > > might fit into 120 characters, but this drastically limits readability, > > and > > > is already a smell, which points to increased and probably unnecessary > > > complexity in the code. > > > - sometimes I also find it hard to fit in to the 80 character limit, > and > > I > > > really don't like to wrap lines, so the limit makes me do a couple of > > > things to prevent wrapping... for example: > > > - check if I can extract something from the line > > > - check if I can name something better to still express what it > > means, > > > but in a shorter form > > > - check if I can simplify the code that I use, to have a shorted > > access > > > to the functionality > > > - check if there is a simpler way of doing the same > > > - check if I am too deeply nested, and whether I should extract > the > > > block I am in so it fits > > > - if after all the above measures, the line still does not fit, I look > > into > > > ways of wrapping that helps the understanding of what I am trying to > > > express in the code, and try to separate things visually, usually > during > > > this process I still find ways of simplification > > > - with the 120 character limit, I think this process (as it initiates > > > lazily when I reach the limit), will trigger later, leaving the longer > > > lines with more complex to understand things, eventually degrading > > > readability, in exchange to allow less thinking when we work on to fit > > into > > > the 80 characters. > > > - when I read code, and I see 3-4 lines long expressions, I always > > realise > > > that not everyone feels the urge to fit into the 80 characters, and I > > don't > > > blame anyone not doing so, but still if at least a couple of us feels > the > > > same then I strongly believe it does worth it to limit ourselves to > that > > 80 > > > characters, as I believe this if just by a small portion, but pushes > for > > a > > > bit more thinking with that probably a bit more values/quality in the > > > code... > > > > > > > > > There is a scientific reason as well: > > > - typography studies shows that the ideal line length for reading is > > around > > > 45-75 characters long, the longer the line the slower the reading, with > > > increasing the line length, we make it more uncomfortable reading the > > > longer lines, and with that we reduce the likelihood of the reader > > reading > > > through the whole line. As during most of our work, we read code, and > > less > > > time we write code, the readability is a property of the code that we > > must > > > take into account when we make these decisions... > > > On this see for example: > > > https://baymard.com/blog/line-length-readability > > > > > > https://www.smashingmagazine.com/2014/09/balancing-line-length-font-size-responsive-web-design/ > > > > > > I also suggest a small experiment: > > > 1. Go to your IDE > > > 2. Select a big class like OzoneManager > > > 3. Change the line length to 120 > > > 4. Reformat code > > > 5. Start to read code > > > > > > Who thinks it is better that way? (Feel free to ignore broken automatic > > > wrapping and concentrate on parts where there are not too much wrapping > > > after the change...) > > > I don't. > > > > > > Pifta > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org > > For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org > > > > > -- Pifta
