C风格的逻辑和重构

Question

我喜欢评估单个表达式作为一个值和一个布尔值的语言。例如，A = 1的计算结果为真，而且1的计算结果为真。如果这种做法对我的智库中的开发人员来说非常普遍，假设没有副作用，重构这些表达式是否错误？

我在工作中讨论代码气味时有一个长期的讨论，但是这个逻辑复杂度是为什么我喜欢C这么好。例如，对于我来说，切换到Java是很困难的，因为它不允许这种效果（false！= 0）。

有什么想法？

Answer 1

没有什么真正的理由要大量地将非零值重用为true，将零/零作为false。然而！通常这些可能会妨碍可读性。通常在使用指针时，我将使用if (somePtr != NULL)而不是仅仅使用if (somePtr)，因为我觉得它更好地描述了......不解除引用空指针的意图。

如果逻辑过于复杂，这是一个可读性的问题，但如果你不认为它很难阅读？为什么需要重构？

Answer 2

这是完全主观的，但我认为这使得Perl（它允许你用许多不同的方式表达某种东西，以不同程度的清晰度）和Java（更多 - 或者不是一种束缚与纪律的语言）。有些人喜欢（或需要）结构，在这种情况下，Java更适合他们。其他人喜欢更自由的语言允许的创造力。

如果你有一个经验丰富的程序员团队，那么创造性语言将允许他们完成更多的工作。如果你有喜欢“更紧密”语言的同事，那么也许这也说明了一些事情，或者不是。但那只是我的个人意见。 :-P

Answer 3

Java是严格打字，我碰巧认为有很多优点;如果防止了一件事的交叉错误。我认为C的灵活性和控制力有其自身的地位，但Java确实发挥了作用，确保大型团队不会被糟糕的程序员拖得太远。 C和Java在语法上类似但不相同; Java被认为是有原因的，我都是这个原因。

尽管我的看法;再加上你可以用一些聪明的重载或新功能打破Java的严格打字。

Answer 4

我认为这确实只是成语熟悉程度的问题。例如，linux内核有很多成语。

例如，你永远不会做

static int x = 0;

取而代之，您需要：

static int x;

（编译器将使其为零内核家伙争论，不是我。）

你不这样做：

如果（X！= NULL）

你这样做：

如果（X）

你不这样做：

如果（东西==什么） 返回0; else return 1;

你这样做：

return（something！= whatever）;

而且，整数偶尔出现这种混合与布尔可以出来真的很方便，像这样：build_assert.h

它的肉是：

 
#define EXPR_BUILD_ASSERT(cond) \ 
    (sizeof(char [1 - 2*!(cond)]) - 1) 

他们使用goto的宽松的错误处理路径，这有点逆势。

当涉及到可读性和可维护性时，一行或两行事情可能是一次洗牌。这是微不足道的东西。可维护性和可读性部门中的真正肉食（从我的经验）是更大规模的事情。对我来说，很多面向对象的东西往往会使代码更易于写入，但难以阅读，而且难以进行DEBUG。对我而言，这是一个净亏损。所以，我不是oop的忠实粉丝。哎呀...我转移话题。