选择非标准 Java 代码缩进样式有风险吗？

Question

如果您选择非标准缩进样式，会有什么不同吗？

这是我最常看到的样式：

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

public class Test {
    static public void main(String args[]) throws Exception {
        FileInputStream fin = new FileInputStream("infile.txt");
        FileOutputStream fout = new FileOutputStream("outfile.txt");

        FileChannel inc = fin.getChannel();
        FileChannel outc = fout.getChannel();

        ByteBuffer bb = ByteBuffer.allocateDirect(1024);

        while (true) {
            int ret = inc.read(bb);
            if (ret == -1)
                break;

            bb.flip();
            outc.write(bb);
            bb.clear();
        }
    }
}

但我更喜欢这种样式，所有内容都从下一行开始：

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

public class Test
{
    static public void main(String args[]) throws Exception
    {
        FileInputStream fin = new FileInputStream("infile.txt");
        FileOutputStream fout = new FileOutputStream("outfile.txt");

        FileChannel inc = fin.getChannel();
        FileChannel outc = fout.getChannel();

        ByteBuffer bb = ByteBuffer.allocateDirect(1024);

        while (true)
        {
            int ret = inc.read(bb);
            if (ret == -1)
                break;

            bb.flip();
            outc.write(bb);
            bb.clear();
        }
    }
}

我发现这更容易阅读，但如果我使用这种样式，我会遇到与其他人合作的问题吗？

Answer 1

这更像是一个宗教问题，而不是一个编程问题。人们对代码格式化风格有强烈的看法。第一种格式遵循 Sun Microsystems 所提倡的风格，第二种格式遵循我所说的非猴子风格。如上所述，关于代码格式化风格的强烈意见比比皆是。

正如之前的一位或多位发帖者所述，公司使用代码格式化程序，因此您首选的格式样式可能无法通过签入源代码管理。

一致性很重要，但在一个由 6 名程序员组成的团队中，如果 5 个愚蠢的火箭产生了难以阅读的代码，那么与它们不一致并尝试产生不难阅读的代码可能是一个好主意。

Answer 2

一致性非常重要。

如果您喜欢第二种风格，请坚持下去。 （我愿意。）

但是无论您最终选择使用什么样式，都不要在代码中间更改它。

{编辑] Netbeans 可以选择以您选择的样式 IIRC 显示代码。

Answer 3

我不同意你的标题。第一个标准和第二个非标准如何？

偏好会随着时间而改变。我们不再在 80*25 文本终端上编程。我们正在编写不同类型的代码。节省一行的理由变得越来越有趣。

@RequestMapping(value="/hotels/{hotel}/bookings/{booking}",
                method=RequestMethod.GET)
public String getBooking(
        @PathVariable("hotel") long hotelId, 
        @PathVariable("booking") long bookingId, 
        Model model) {                                    // WOW! I SAVED A LINE!
    Hotel hotel = hotelService.getHotel(hotelId);
    Booking booking = hotel.getBooking(bookingId);
    model.addAttribute("booking", booking);
    return "booking";
}

Answer 4

答案是，这取决于代码的受众。如果您能看到代码，那么您就可以做您喜欢的事情。如果其他人可能会看到该代码，那么这取决于您与他们的社交和/或专业关系。如果其他人可能会修改代码，那么不尝试以某种标准方式进行编码将是不专业的。

Answer 5

采用 Sun 十多年前制定的标准样式将使新加入组织的人员更容易跟上进度，代码格式将按照他们在之前职业生涯中习惯的方式进行。

除此之外，任何（经过深思熟虑的）样式只要一致地应用就可以（我花了很长时间来找出样式不一致的代码，其中不同的人在修改现有的代码时也采用了不同的样式）方法）。

Answer 6

1. 决定团队中的单一约定（最好是标准约定，以防您以后想要与其他人合作）
2. 将您和其他人的 IDE 配置为仅使用该格式。
3. 使重新格式化自动发生，最好是在每次按下 Ctrl-S 时发生。

这将使所有源始终保持一致，并确保源存储库中的更改是实际更改，而不仅仅是稍后重新格式化。

对于 Eclipse，这可以通过配置格式化程序（我碰巧喜欢默认值）来完成，并保存首选项，然后其他人可以加载这些首选项。还有Java->编辑->保存操作允许在每次按下 Ctrl-S 时自动重新格式化，这也是一个可保存的首选项。

我发现上面的内容中，额外的启发式“

• 一切都必须适合单行”

提供了许多自动触发的重构，提供了许多命名的本地变量，然后通过命名捕获意图，这反过来又非常适合调试，就像您通常所做的那样单步执行时，调试器中显示的变量值更多，并且每行出现 NullPointerException 的机会往往更少。

---

编辑：我在我的博客上写道关于这个。

---

编辑 2014-08-19：看起来，如果 Eclipse 格式化程序设置保存到文件中，IntelliJ IDEA 可以使用该文件格式化源。

Answer 7

遵守惯例。您应该查看当前项目之外的代码、程序员流动、公司被收购、工具往往会根据标准进行配置等。

Answer 8

使用哪种风格并不重要，但确保它与团队的其他成员保持一致。

通常这会涉及无休止的讨论，但我想这里列出的两个是更常见的。

Answer 9

没关系。无论如何，大多数公司都会使用代码格式化程序。

我也更喜欢第二种风格。

Answer 10

如果其他人都使用与您相同的大括号放置和缩进标准，您就不会有问题。

如果你是一匹孤独的狼，你就会遇到问题。

最大的问题是你的版本控制系统。您不希望人们在样式之间“加油”，并且由于样式更改而不是实质性的代码修改而出现许多差异。

在罗马，入乡随俗。在你的团队中达成共识并坚持下去。

PS - 我同意你的观点：我更喜欢在下一行加上大括号。太阳大会是第一个。这对书籍作者来说更好，因为空白更少。

Answer 11

与以往一样，当涉及到代码格式时，如果您与更喜欢另一种格式的人一起工作，那是有风险的。

Answer 12

我很久以前就不再担心代码格式了。争论花括号的位置真是浪费氧气。当我必须修改代码时，我使用 IDE 的代码格式化程序使用默认值重新格式化文件。然后我做我的工作并承诺它。当其他人更改文件时，他们可以根据自己的喜好对其进行格式化。我一点也不在乎。

我宁愿程序员花时间讨论算法、数据结构和测试策略。

Answer 13

这确实是一个选择的问题。如果您发现一种方法比其他方法更容易阅读，那就继续吧！

唯一的例外是当您正在从事大型项目并为其做出贡献时。在这种情况下，您显然必须遵循在源代码的其余部分中维护的约定。

我个人是第一种方式的粉丝，大多数人都遵循这个惯例。