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
