fapifta commented on pull request #921: URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-644671160
We are currently the part of the Hadoop project, which has the 80 characters as the limit, we I think should change the rule - if we change it - after we become TLP as that is in the making. Also this seems to be a good time to write our guidelines (yes, I loved to read the Flink guidelines Marton posted on the mailing list), that talks about coding style, wrapping, line length, possible exceptions and all the things that we think is important regarding code. First it should not be large, but evolve over time as we have discussions and learning points on the go, but it would be useful to contain all the prior learning points we already have on the project. Even though I don't want to block the community from the change, I still think we should keep 80-ish as a limit. I wrote about consistency, I wrote about typography, and I wrote about a couple other things in the mail-thread. Also I questioned why not go unlimited then based on the first arguments about inclusiveness and naming problems cited by 120 limit supporters. Now I just would like to add some colour from a few guys seem way smarter then me... Kevlin Henney is dealing with this topic in a talk "Seven ineffective habits of many programmers" in several conferences. In this talk: https://vimeo.com/97329157 At 14:38 he starts talking about spacing punctuation and indentation, and also gives some reason for 80 characters. After this section there comes the naming, and code structuring piece, and before this section he talks about the problems of verbosity and jokes around comments :) It is on one hand really convincing for me, also gives some interesting points we can use in the conversation about coding guidelines. If you have time to view the whole, the latter part talks about encapsulation, get/set and the problems with the wide use of'em, and tests at the end. Dan North at 20:42 in this video talks about "code that fits into one's head", and mentions why contextual consistency matters, and even though he talks about the way larger picture, it is true for source code as well, also he talks about teams have to be opinionated about how they do things, and how they organize things, and that makes me think that, we need general acceptable guidelines on many visual/architectural/algorithmical things that we might not agree on now, but we would like to have consistency on. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
