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
