如此……您正在考虑为团队添加或更改Java样式指南吗？ 您是否坚持使用久经考验的Sun指南？ 还是已经二十岁了，这太过时了吗？ Google风格怎么样？ 但是那些两个空格的缩进！ 也许AOSP？ 推特？ 您可以接受IntelliJ随附的默认设置吗？
啊！ 太多问题！
Let's take a step back
您有选择。 而且，在2019年，没有一个广泛可用的选项能够真正解决lambda和流之类的Java 8+功能。 您可能必须选择一个基础并从那里发展。 以下是一些选项：
Ťhe Original Sun Java Style Guide
一种ndroid Open Source Project (AOSP) Style Guide
Food for thought
在进行选择和决定之前，我认为您应该遵循三个步骤。
1. Define your goal
当然，我们所有人都希望使用一致的代码。 在这种情况下，任何选项都可以。 但是，获得样式指南的实际目标是什么？ 要在团队之外共享代码？ 也许在公司之外？ 也许您有多个目标？
在我目前的团队中，我们将目标定义为60％的一致性（因此，只要有样式指南，大多数情况下我们就不在乎），30％的一致性，以便我们与紧密合作的其他几个团队保持一致， 并允许我们的开发人员及其开发人员跨团队跨界流畅地工作，而10％的人使用哪种工具来支持遵循代码风格。
您可能还有其他考虑。
2. Consider the environment
通过这个，我的意思是考虑您查看代码的位置。 我猜您正在执行代码审查。 怎么样？ 在Gitlab中？ 那是一个用于查看代码的相当不错的环境，您可能不太在乎选择哪种样式。
Do you want to be able to view it in a tool like FishEye? Does code ever make it into your Jira cards? What about on mobile? Do you ever look at code there? Does anyone ever open your code in a plain text editor?
考虑这些事情并考虑长线可能会做什么，或者类似地使用大量垂直空间可能会做什么，这可能是明智的。
3. Consider tooling
Finally, how will you support code style in your project? If you use a build tool like Maven, there are some plug-ins like the fmt-maven-plugin to autoformat code when builds are ran (fmt-maven-plugin uses Google style).
这可能感觉有些极端。 您可能会很乐意让您的IDE支持这一点，在这种情况下，您将希望保留用于导入到Eclipse或IntelliJ的代码样式设置的XML文件。
这完全取决于您。
Thoughts on lambdas and streams
话虽如此，您可能还想解决如何使用Java 8+特性（例如lambda和stream）的问题。 我问Stuart Marks Oracle正在使用什么。 标记是技术人员咨询成员适用于Oracle和Java布道者。
@BrianGoetz @stuartmarks Is "Sun Java Style" what the team is using for code style on the latest features or is it something else? Do you have any advice toward styling functional code?17:54 PM - 17 Jul 2019
0
1
马克斯（也许不足为奇）有很多想法！
Stuart Marks@stuartmarks
@ScottAShipp @BrianGoetz Yeah pretty much but as you know it’s way out of date. There has been some effort to update it but not completed yet. By “functional code” I guess you mean lambdas and streams? Here are a few things off the top of my head (of course, my opinion only, etc.) 1/20:11 PM - 17 Jul 2019
Stuart Marks@stuartmarks@ScottAShipp @BrianGoetz • prefer method references to lambdas
• prefer expression lambdas to statement lambdas
• omit lambda parentheses & types for lambda formals where possible
• use short but evocative names for lambda formals
• prefer predefined functional interfaces (mostly j.u.function.*) 2/20:15 PM - 17 Jul 2019
Stuart Marks@stuartmarks@ScottAShipp @BrianGoetz • write stream pipelines with one op per line, with dots lined up at the start of 2nd+ lines
• break up pipelines at logical boundaries by storing intermediate collections in local vars
• indenting multi-line stmt lambdas in stream pipelines is an unsolved problem; avoid. 3/20:19 PM - 17 Jul 2019
Stuart Marks@stuartmarks@ScottAShipp @BrianGoetz • avoid side effects in stream pipeline ops
• use parallel streams only when you know you have a perf problem that can be remedied by using multiple cores
• if you pass a stream as a method arg, ensure it’s unconsumed, and assume the callee consumes it
4/20:23 PM - 17 Jul 2019
Stuart Marks@stuartmarks@ScottAShipp @BrianGoetz • only return unconsumed streams
• use a stream as a team-with-resources variable only when it clearly contains a resource that needs explicit closing
That’s what I got. 5/x20:26 PM - 17 Jul 2019
所以你有它。 大量关于现代Java的好建议！
只是，无论您做什么，都不要在标签上争论空格而陷入困境！
2040
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
