I know that I expressed support for remaining in the 80 chars space. Let me write down the arguments.
1. Accessibility There are lot of people with different kinds of eyesight capabilities. Some people due to the physical limitations are forced to deal with font and point sizes which are larger. I strongly feel that moving from 80 to 120 characters forces many of those people to fundamentally re-adjust. While 80 chars might waste a little bit of space on your monitor, for someone who is struggling with a disability it clearly a difference between being able to read, understand, and contribute to Ozone. The US government recommends that we maintain " Don’t make lines too long or too short: 45-75 characters per line is acceptable and approximately 66 characters per line is comfortable" [1] So if anything we should be debating if we should really go down to 66 chars per line rather than 120 chars. This is not based on my preference or yours but based on studies with people who struggle with vision issues and use computers. Unless you can demonstrate a convincing win, I would like to be considerate to others. 2. The Question of Information Density It seems to me that lots of you folks are arguing that there is not enough information density on your screen. While I applaud your ability to process lots of information, the traditional wisdom says that human beings are comfortable processing smaller, clearly defined chunks of information. Please see this classic paper that studied that question[2]. If you agree with the conclusions of that paper, you will see that we can process approximately 7 chunks of information. Unless we can make a clear measure on this there is no way for us to predict which is better, 80 chars or 120 chars or 240 chars. The general wisdom among people who have studied this is 3/4 chunks of the information "sweet spot". If you should be trivial for you to find a series of papers that study the miller's question. if you are deeply interested in this. 3. The question of consistency So let us say we change this number, existing files will have both? That is 80 char limited lines and them once in a while 120? Why do you think it improves the layout or the structure of code? I know this is a personal opinion, but I like a simple rule and the consistency it provides via the 80 chars. What I am really trying to say is, I am not able to see any upside to moving to 120 characters, only downsides. I strongly disagree with that move, and I would love to listen to a deeper reason for such a move; right now, I see more downsides than advantages. 1. https://accessibility.digital.gov/visual-design/typography/ 2. http://psychclassics.yorku.ca/Miller/ Thanks Anu On Thu, May 21, 2020 at 6:35 AM István Fajth <fapi...@gmail.com> wrote: > 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 >
