【问题标题】:Line width formatting standard [closed]线宽格式标准[关闭]
【发布时间】:2010-09-21 12:28:40
【问题描述】:

您是否遵循在源代码中包装长行的标准?你觉得读起来最舒服的行长是多少?

有时我发现有人在宽屏显示器上编程并喜欢使用其全宽来显示源代码。我更喜欢较短的行数,大约 80-100 个字符,但我很难用越来越受欢迎的宽屏设备来说服同事。

编辑:

类似问题:

【问题讨论】:

  • stackoverflow.com/questions/110928非常相似的问题
  • 谢谢,安德鲁。快速搜索 SO 以及在您输入问题时出现的建议问题,结果一无所获。

标签: coding-style formatting


【解决方案1】:

不要损害关于一行中确切字符数的教条规则的可读性。水平滚动是不可取的,但 81 个字符的行比缩进混淆的换行版本更容易阅读。

80 个字符可能不适合具有大缩进和/或冗长变量名称的编程风格。将逻辑复杂度降低到每行的最大值,而不是字符数。

【讨论】:

  • 如果超过 80 个字符,您将遇到另一个更大的问题 --- 您过于冗长。线宽限制迫使您为变量考虑更好的名称并重构掉不必要的范围。
【解决方案2】:

我使用大约 72-75 列来确保我可以在字母格式的页面上打印代码而不会有太多麻烦。我也使用空格而不是制表符,并且注意布局​​。

为了注意我何时超出了右边距,我经常输入一个我可以看到的文本行 用作尺子。我设置了 IDE 显示窗口,使标尺刚好适合水平宽度,然后我确保我不会超出它。

我在 .txt 文档以及 .c、.java、.cpp、批处理文件等中执行此操作。这使得在电子邮件中发送 sn-ps、在博客上发帖、放入 cmets 等变得更容易. 标尺通常位于标识文件和文本格式的顶行下方:

/* example.txt 0.00                  UTF-8                   dh:2008-11-09
*---|----1----|----2----|----3----|----4----|----5----|----6----|----7----*
*/

当然,使用特定类型文件的注释约定。

【讨论】:

    【解决方案3】:

    我们使用 80 个字符的编码标准。 80 字符限制的最初原因与今天无关,但应该选择一些数字......

    除了显而易见的(代码组织和可读性)之外,我通常发现长行是不良样式的结果,遵循这样的规则可以提高代码质量并减少错误。只需比较以下示例:

    status = do_something(); 
    if (status == error)
    {
        do_error_handling();
        return;
    } 
    /* do you regular flow */
    status = do_more();
    if (status == error)
    {
        do_error_handling();
        return; 
    }
    /* do more of you regular flow  and keep you line 80 chars*/
    

    改为:

    status = do_something(); 
    if (status == succes)
    {
         /* do you regular flow */
         status = do_more();
         if (status == success)
         {
                /* do you regular flow */
                /*  nest again and get line behind visible screen */
         }
         else
         {
             /* do error handling */ 
         }
    
    }
    else
    {
         /* do error handling */ 
    }
    

    第二个例子的可读性要低得多,难以维护,可能会导致一些问题......

    编辑

    将代码中的goto替换为do_error_handling(),以避免不相关的讨论。

    正如我之前所说的 80 个字符与今天无关,它只是一个数字 100 也很好。

    对于发现第二个示例更具可读性的任何人,请用真实代码再嵌套几次,然后再次尝试阅读:)

    【讨论】:

    • 有趣的是,我发现第二个更具可读性,并且当我第一次看到你的帖子时,我希望它是你的“可读”代码示例。我从来不理解现代编码实践中对 80 个字符的迷恋(我理解历史意义)。我通常保持在 100 个字符
    • 所以您是在建议我们使用 GOTO 语句? =)
    • 我们不会在这里开始讨论 :) 我会更新一个例子
    • 别担心,我是 j/k。 =)
    • 我还发现第二个示例更具可读性。我对“用真实代码再嵌套几次并尝试再次阅读”的反驳是,您应该尝试将这些额外的嵌套分解为额外的小型私有方法。
    【解决方案4】:

    我更喜欢更长的行,原因很简单:我可以在我的窗口中放入更多代码。必须垂直滚动才能阅读功能与能够将其放入单个屏幕之间存在巨大差异。如果所有内容都是换行的,以便函数从底部滚动而我的屏幕右半部分是空的,我认为这是一种巨大的浪费。请注意,在这里打开两个编辑器窗口也无济于事。

    【讨论】:

    • 如果您或您的少数同事(您知道他们也像您一样喜欢阅读代码)将阅读代码,这很好。但是,如果您正在为更大的用户群编写代码,那么它可能是不考虑周到的。
    【解决方案5】:

    它还取决于您使用的其他约定。在一项工作中,我们使用 Java 进行编程,约定使用长且描述性的标识符,这意味着一行中只有几个标识符可以放在一行中,而不会超过 80 个字符的限制。考虑到公司里的每个开发人员都得到了一个可以轻松容纳 200 个字符的宽屏显示器,我认为这非常愚蠢。有了这样的硬件一致性,强制执行一个愚蠢的小换行限制是没有意义的。

    【讨论】:

      【解决方案6】:

      更大的屏幕——更大的字体。我使用 GVim,Conslas 14pt 在 1280x800 屏幕分辨率下最大化。我尝试以大约 80-90% 的屏幕宽度换行。

      【讨论】:

        【解决方案7】:

        我坚持 80 行规则(并试图说服每个人都这样做)。一些原因:

        1. 您可以一次打开 2 个(或更多)编辑器。
        2. 比较工具也是如此。 - 大多数(全部?)并排显示两个(一些三个(一些更多?))文件。
        3. 有时您需要远程工作,在不同的工作站或笔记本电脑上工作,突然间,您格式精美的 120 字符转行代码看起来很糟糕。

        【讨论】:

        • 8 年后,双显示器和 1440p 显示器的价格低于 300 美元,您在此处列出的所有理由都得到了缓解。所以,我选择在这样一个不会使代码不可读的地方分行。我希望你仍然没有试图让其他人坚持 80 个字符。
        • 80 chars (not lines) 是 50 年前的计算机终端分辨率,今天遵循这个标准毫无意义。
        • Python 约定仍然建议尝试使用 80 个字符来保持代码在小窗口中的清洁和可读性。仅仅因为你有一个 3000 平方英尺/英尺的房子并不意味着你应该用垃圾填满它。如果您需要它来支持您的 5 口之家 - 那么一定要填满它。
        • 无论您使用 FHD 屏幕还是 USQFHD 屏幕,我敢打赌您更改字体大小,以便在所有屏幕上适应相同数量的文本(除非您有2.21:1 电影编辑屏幕或 1:1 MRI 屏幕)。 (旁注:Python PEP8 实际上指定了 79 而不是 80)
        • 当每个人都在使用 4k 屏幕时,人们会写更长的行吗?因为你有一个更宽的显示器并不意味着你应该写更长的行。有些人也喜欢纵向模式的显示器。作为快速测试,看看您是否可以阅读此内容,或者是否必须缩小浏览器窗口:pbm.com/~lindahl/brief.html
        【解决方案8】:

        我几乎只在笔记本电脑上编程,所以我同意较短的行。当然,我通常为 PDA 设计屏幕,所以我可以侥幸逃脱。但如果代码在开发人员之间共享,它最终会出现在某人的笔记本电脑上,滚动条让我哭泣。

        【讨论】:

          【解决方案9】:

          您不必水平滚动即可阅读代码。但更大的屏幕并不意味着更长的线路!一行的内容也有限制。

          所以我说:一如既往地保持在 70-80 个字符。更大的屏幕只是意味着 IDE 有更多的空间。

          【讨论】:

            猜你喜欢
            • 2010-10-05
            • 2020-05-28
            • 2013-07-03
            • 2010-10-21
            • 1970-01-01
            • 2016-10-04
            • 2018-08-29
            • 2016-07-31
            • 1970-01-01
            相关资源
            最近更新 更多