有没有理由在Java / C#/ C ++中编写简洁代码?

时间:2009-03-20 14:20:59

标签: c# java coding-style

你有没有发现自己用Java,C#或C ++编写简洁代码?

如果是这样,为什么?考虑到使用这些语言的情况,你认为在任何情况下都应该接受这个吗?

12 个答案:

答案 0 :(得分:23)

这取决于你对'简洁'的定义。

如果您的意思是“简短而重要”,那么它与良好代码的愿景非常吻合。

如果你的意思是“神秘”,那就有问题了。

答案 1 :(得分:15)

答案 2 :(得分:12)

这取决于“简洁”的含义。我当然喜欢编写简洁的代码,它以最简单的方式表达我想要实现的内容。例如,我喜欢LINQ让我表达数据管道的方式,而不是编写循环来转换或过滤集合的“旧”方式,或者找到最大值等等。这只是的重复代码在某处的模板方法中。

另一方面,较短的代码总是比较长的代码更具可读性。有条件的算子在这方面是争议的主题。是:

Foo x = null;
if (condition)
{
    x = y;
}
else
{
    x = z;
}

或多或少可读:

Foo x = condition ? y : z;

好吧,如果“条件”,“y”和“z”都非常简单,条件运算符就会胜出。如果你必须通过箍来使“y”和“z”单个表达式执行多个语句更具可读性,那么if / else形式可能更具可读性。

简而言之,我编写了最易读的代码。这通常(但不总是)简洁的代码。

答案 3 :(得分:4)

尝试始终编写清晰的代码。有时清晰的代码很简洁,但通常不是。

为什么呢?因为在6个月的时间里,你需要了解你想要达到的目标。你做得越快越好。

答案 4 :(得分:4)

编写实际源代码时,尽可能保持健壮(不牺牲性能)。 IE:

var result = GetResultFromFoo(GetOtherResult()).DoSomeCalculation(CallAnotherMethod());

编写起来可能很有趣,但祝你好运。没有任何好处,只需将其分解为此;

var result = GetOthereEsult();
var fooResult = GetResultFromFoo(result);
var anotherMethodResult = CallAnotherMethod();
var finalResult = fooResult.DoSomeCalculation(anotherMethodResult);

更容易调试。

我唯一能够看到编写尽可能简洁代码的理由,是源代码的大小是否重要(例如,在每秒数百次提供的JavaScript文件中)或故意尝试混淆时代码,但是通常有软件可以帮助你。因此,国际海事组织的底线,并不是真的没有太多理由。

答案 5 :(得分:2)

除了所有其他问题之外,更短的代码更好,因为您可以立即看到更多代码。

答案 6 :(得分:2)

请记住,代码的阅读频率高于编写代码,并且在编写代码时会记住您的读者(读者甚至可能是您)。不要像你一样编写代码,假设读者是愚蠢的,也不要写代码,假设它的含量越少越好。

像Joel Coehoorn建议的那样写“简短而重要”。

答案 7 :(得分:2)

我发现对人类的可读性是LONG run中代码最重要的特性。

可读性包括简洁,准确和清晰。如果你把东西混在一起,你的读者会感到困惑。如果你的代码清楚易读,你不需要很多评论。如果你把局部的,命名良好的变量中的复杂事物分解在一起,那么你会非常有助于读者,同时隐含地记录你的行为。

编写良好的代码将为您生存。力求完美:)

答案 8 :(得分:1)

@j_random_hacker(无法在评论中添加评论)

在我6个月后,我发现很难解读我写的一段代码。 事实上,这部分也很重要

答案 9 :(得分:1)

我是代码的忠实粉丝,我可以阅读。我看过一些看起来像“简洁”的代码:

int af = yb; 
while(af<ex){af++;af*=4;}

很容易看到以编程方式完成的工作,但实际上在意义方面做的事情是模糊不清的。我宁愿拥有我之后可以阅读的变量名,而不是试图保存几个字符的代码并使用简洁的名字。好的代码并不总是意味着最短。好的代码是关于良好的算法,良好的文档,良好的可维护性。我不关心代码有多长,如果它具有所有这些属性,那就是很好的代码。

答案 10 :(得分:0)

假设你正在使用“简洁”一词带有“神秘”的含义:

除非它是一个混淆的编码竞赛,否则我认为用编译语言编写简洁代码毫无意义。我可能只在我自己的私人项目中编写了简洁的C ++代码。从来没有其他人会看到的代码。

否则,简洁(在“到点”的意义上)代码优于详细代码。

答案 11 :(得分:0)

java中的详细代码和命名有一个机械缺点:某些JVM下的内存占用。这可能只是围绕流程虚拟大小和内存映射的jar文件的感知问题,但它确实存在。大jar文件==大(感知)内存使用情况。

你可能不得不把事情做到极端,因为这是可以衡量的简洁性,但它是一个有趣的“真实”效果。

就其他人所说的实际建议而言,首先编写好的代码,然后担心优化。