选择非标准的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();
        }
    }
}

我认为这种写法更易于阅读，但如果我使用这种方式会不会在与他人合作时遇到问题？

- glanden

---

@BoltClock是一只独角兽。该规范（非规范性地）引用了Sun编码标准，这是一种事实上的标准。 - Tom Hawtin - tackline

@Tom Hawtin：我错过了，哎呀。 - BoltClock

这个问题难道不几乎和“vi vs. emacs”一样具有风险性吗？！ - Michael Banzon

@mbanzon：另一半世界的学究们一定在睡觉;}(附注：我用大括号代替笑脸，因为我略微超重。) - slashmais

第二种风格（不幸的是，这是微软的Visual Studio for C#强制实施的风格）的主要问题在于，它占据了更多屏幕“房地产”，而这是非常珍贵的资源。在屏幕上一次性显示尽可能多的程序，可以更容易地理解它。 - Hot Licks

Answer 1

1. 在团队中确定一个惯例（最好是标准惯例，以防以后需要与他人合作）
2. 配置你和所有其他人的IDE使用该格式并仅使用该格式。
3. 使重新格式化自动发生，最好在每个Ctrl-S时都发生。

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

对于Eclipse，可以通过配置格式化程序（我恰好喜欢默认值）并保存偏好设置，然后可以由所有其他人加载。此外，Java -> Editor -> Save操作允许在每次Ctrl-S时自动重新格式化，这也是可保存的首选项。

我发现以上内容还有一个启发式方法：

• 所有内容必须适合单行

这会触发大量自动重构，从而产生许多命名本地变量，这些变量通过它们的命名捕获意图，这反过来又很适合调试，因为您通常在变量中具有更多的值，当单步执行时，这些值会显示在调试器中，并且每行的NullPointerException机会较少。

---

编辑：我在我的博客上写了关于这个的文章。

---

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

- Thorbjørn Ravn Andersen

---

非常好的答案。不知道有关Eclipse“保存操作”的信息。非常有帮助。谢谢。 - glanden

实际上，我不建议在每次保存时自动格式化 - 格式化程序并不完美，可能会对人类可读的格式造成一些混乱。特别是注释。 - gertas

@gertas，如果发生这种情况，你的人员显然没有遵守官方标准。整个问题在于任何人都可以在不破坏原有结构的情况下重新格式化。 - Thorbjørn Ravn Andersen

我的观点是Eclipse中的格式化器的注释部分很糟糕。我没有检查它是否可以通过配置来改进，但总体上我不喜欢它。我使用选择性格式化（选择代码并进行格式化），当然我也遵守Sun/Oracle的标准。 - gertas

@gertas，对我来说太容易出错了。也许你应该看看Eclipse格式化程序，看看它是否可以按照你的喜好进行格式化。 - Thorbjørn Ravn Andersen

Answer 2

遵循惯例。你应该查看你所在项目之外的代码，程序员会离开，公司会被收购，工具通常会配置为标准等等。

- Tom Hawtin - tackline

---

从一种编码风格转换到另一种编码风格的努力只需要几个小时（这是我的个人经验）。 - Pablo Fernandez

我很幸运，因为我工作的每个地方都使用了与我一直使用的相同的通用风格。然而，每当我不得不阅读以另一种风格编写的代码时，这会导致额外的心理负担，我真的可以避免这种情况。 - Tom Hawtin - tackline

@Pablo - 如果你使用IntelliJ，就不会有这个问题。它可以在几秒钟内设置整个项目的编码标准。 - duffymo

Answer 3

无论你使用哪种风格，确保它与你团队的其他部分保持一致。

通常，这需要无休止的讨论，但我想这里列出的两种是比较常见的。

- Pablo Fernandez

---

请使用自动格式化。这将确保源代码库在以后不会将重新格式化视为更改。 - Thorbjørn Ravn Andersen

Answer 4

没关系。大多数公司都使用代码格式化工具。

我也更喜欢第二种风格。

- Gustavo Puma

---

你的意思是，“大多数公司都使用代码格式化程序”？这难道不会导致duffymo提到的版本控制中出现错误的更改吗？ - Kirk Woll

@glanden，是的，但我从未听说过这样的事情。而暗示“大多数公司”都这样做似乎有点言过其实。 - Kirk Woll

@Kirk Woll：我同意。 “大多数公司”似乎有些夸张。我在许多公司工作过，从未听说过有人使用代码格式化程序，因此我非常好奇听到更多关于它的信息，因为它对公司非常有用，对编码人员也很解放。 - glanden

@glanden：Java中常见的一个是JaCoBe（http://www.tiobe.com/index.php/content/products/jacobe/Jacobe.html）。其他语言也有类似的工具，通常使用“tidy”或“beautifier”这样的变体命名。但是请查看Kirk在Tony Ennis的评论回复中提到的一个注意事项，以避免滥用自动源代码格式化程序。 - Sdaz MacSkibbons

我从未在使用格式化程序自动格式化代码的公司工作过。如果有记得的话，这通常是在程序员层面上完成的。 - Tony Ennis

Answer 5

如果所有人都像你一样使用相同的大括号位置和缩进标准，那么你不会与其他人产生问题。

如果你是一个孤狼，你会有问题。

最大的问题将出现在你的版本控制系统中。 你不希望人们因为风格变化而出现许多差异，而不是实质性的代码修改。

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

附言 - 我支持你：我更喜欢将大括号放在下一行。Sun约定是第一个。对于书籍作者来说，这样做更好，因为没有太多的空白。

- duffymo

Answer 6

我不同意你的标题。第一个标准，第二个非标准的地方在哪里？

偏好随时间变化。我们不再在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";
}

- irreputable

---

单个屏幕上可以显示的代码量仍然很重要。您能看到的越多，就越不需要滚动。 - Thorbjørn Ravn Andersen

我有1600个像素垂直方向，太多了！ - irreputable

Answer 7

就像在代码格式化方面一样，如果你和偏好不同的人一起工作，那么就存在风险。

- Vivien Barousse

---

另一个应该坚持相同的原则。 - slashmais

Answer 8

我早就不再担心代码格式了。争论花括号的位置是多么浪费时间啊。当我需要修改代码时，我会使用IDE的代码格式化工具，使用默认设置重新格式化文件。然后我会进行我的工作并提交它。当其他人更改文件时，他们可以按照自己的喜好进行格式化。我一点也不在乎。

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

- Tony Ennis

---

你的版本控制系统一定被充斥着无意义的更改。听起来相当可怕。 - Kirk Woll

这从来没有成为困扰——我不记得曾经遇到过无关噪音的问题。此外，我的集成开发环境内置了一个 CVS diff 工具，有一个忽略空格选项。/耸肩而过 我并不在意代码管理器内部生成了什么。女士们先生们，还有更重要的事情要处理。这些都是细枝末节。 - Tony Ennis

有趣的部分出现在您需要定位冒犯性更改是何时进行的，并且您的集成开发环境从CVS获取的信息是误导性的。 - Thorbjørn Ravn Andersen

我只能说，过去20年中，我在比较代码方面从未遇到过问题。 - Tony Ennis

Answer 9

其实这完全是个选择问题。如果你觉得某种方法比另一种更易读，那就用它吧！

唯一的例外是当你在开发和贡献大型项目时。在这种情况下，你显然必须遵循整个源代码中维护的惯例。

我个人喜欢第一种方式，而大多数人也遵循这种惯例。

- Adam

Answer 10

一致性非常重要。

如果你喜欢第二种风格，就坚持使用它。（我也是。）

但是无论你最终选择使用哪种风格，在代码编写过程中不要更改它。

{编辑} 如果我没记错的话，Netbeans有一个选项可以显示你选择的代码风格。

- slashmais