它还取决于执行 LOC 计算的工具。它是否将只有一个符号的行视为代码（例如：C 风格语言中的 { 和 }）？这绝对不会使其变得更复杂，但确实使其更具可读性。
只是我的两分钱。
Not always true. While it is usually preferable to have a low LOC, it doesn't mean the code is any less complex. In fact, its usually more-so. Code thats been optimized to get the minimal number of cycles can be completely unreadable, even by the person who wrote it a week later.
As an example from a recent project, imagine setting individual color values (RGBa) from a PNG file. You can do this a bunch of ways, the most compact being just 1 line using bitshifts. This is a lot less readable and maintainable then another approach, such as using bitfields, which would take a structure definition and many more lines.
It also depends on the tool doing the LOC calculations. Does it consider lines with just a single symbol on them as code (Ex: { and } in C-style languages)? That definitely doesn't make it more complex, but does make it more readable.
我觉得有点没用。无论如何，某些类型的功能（例如用户输入处理）都会有点冗长。我更愿意使用某种形式的复杂性度量。当然，您可以将两者和/或您喜欢的任何其他指标结合起来。您所需要的只是一个好工具 - 我使用 Source Monitor （除了满意的用户之外，我与他没有任何关系）它是免费的，可以为您提供 LOC 和复杂性指标。
我在编写代码时使用 SM 来让我注意到过于复杂的方法。然后我回去看看他们。大约有一半的时间我会说，好吧，事情需要那么复杂。我真正想要的是与 SM 一样好的（免费）工具，但它还支持某种标签列表，其中显示“忽略方法 X、Y 和 Z - 它们需要变得复杂” 。但我猜这可能很危险，这就是为什么我到目前为止还没有向 SM 的作者建议该功能。
I find it a bit useless. Some kinds of functions - user input handling, for example , are going to be a bit long winded no matter what. I'd much rather use some form of complexity metric. Of course, you can combine the two, and/or any other metrics that take your fancy. All you need is a good tool - I use Source Monitor (with whom I have no relationship other than satisfied user) which is free and can do you both LOC and complexity metrics.
I use SM when writing code to make me notice methods that have got too complex. I then go back and take a look at them. About half the time I say, OK, that NEEDS to be that complicated. What I'd really like is (free) tool as good as SM but which also supports a tag list of some sort which says "ignore methods X,Y & Z - they need to be complicated". But I guess that could be dangerous, which is why I have so far not suggested the feature to SM's author.
发布评论
评论（4）
并不总是如此。虽然通常最好具有较低的 LOC，但这并不意味着代码的复杂性有所降低。事实上，通常更是如此。经过优化以获得最少循环数的代码可能完全不可读，即使是一周后编写它的人也是如此。
作为最近项目的示例，想象一下从 PNG 文件设置单独的颜色值 (RGBa)。您可以通过多种方式来完成此操作，最紧凑的是使用位移位仅一行。与另一种方法（例如使用位字段）相比，这种方法的可读性和可维护性要低得多，这需要结构定义和更多行。
它还取决于执行 LOC 计算的工具。它是否将只有一个符号的行视为代码（例如：C 风格语言中的 { 和 }）？这绝对不会使其变得更复杂，但确实使其更具可读性。
只是我的两分钱。
Not always true. While it is usually preferable to have a low LOC, it doesn't mean the code is any less complex. In fact, its usually more-so. Code thats been optimized to get the minimal number of cycles can be completely unreadable, even by the person who wrote it a week later.
As an example from a recent project, imagine setting individual color values (RGBa) from a PNG file. You can do this a bunch of ways, the most compact being just 1 line using bitshifts. This is a lot less readable and maintainable then another approach, such as using bitfields, which would take a structure definition and many more lines.
It also depends on the tool doing the LOC calculations. Does it consider lines with just a single symbol on them as code (Ex: { and } in C-style languages)? That definitely doesn't make it more complex, but does make it more readable.
Just my two cents.
在一个不平凡的项目中，LOC 很容易获得并提供合理的信息。我在新项目中的第一步总是计算 LOC。
LOCs are easy to obtain and deliver reasonable information whithin one not trivial project. My first step in a new project is always counting LOCs.
我认为当 LOC 减少时，它可以用来奖励团队（假设他们仍在生产有价值的软件和可读代码......）。
I'm thinking it could be used to reward the team when the LOC decreases (assuming they are still producing valuable software and readable code...).
我觉得有点没用。无论如何，某些类型的功能（例如用户输入处理）都会有点冗长。我更愿意使用某种形式的复杂性度量。当然，您可以将两者和/或您喜欢的任何其他指标结合起来。您所需要的只是一个好工具 - 我使用 Source Monitor （除了满意的用户之外，我与他没有任何关系）它是免费的，可以为您提供 LOC 和复杂性指标。
我在编写代码时使用 SM 来让我注意到过于复杂的方法。然后我回去看看他们。大约有一半的时间我会说，好吧，事情需要那么复杂。我真正想要的是与 SM 一样好的（免费）工具，但它还支持某种标签列表，其中显示“忽略方法 X、Y 和 Z - 它们需要变得复杂” 。但我猜这可能很危险，这就是为什么我到目前为止还没有向 SM 的作者建议该功能。
I find it a bit useless. Some kinds of functions - user input handling, for example , are going to be a bit long winded no matter what. I'd much rather use some form of complexity metric. Of course, you can combine the two, and/or any other metrics that take your fancy. All you need is a good tool - I use Source Monitor (with whom I have no relationship other than satisfied user) which is free and can do you both LOC and complexity metrics.
I use SM when writing code to make me notice methods that have got too complex. I then go back and take a look at them. About half the time I say, OK, that NEEDS to be that complicated. What I'd really like is (free) tool as good as SM but which also supports a tag list of some sort which says "ignore methods X,Y & Z - they need to be complicated". But I guess that could be dangerous, which is why I have so far not suggested the feature to SM's author.