C定义格式化问题

时间:2009-09-13 23:11:05

标签: c++ c objective-c

我在考虑改变格式化风格。我一直这样做:

char *foo(IULabel *label, char *buffer) {
    UITextView  *tv;
    int         i;
    int         *j;

...
}

我觉得如果我写的话可能会更容易理解:

char * foo(IULabel * label, char * buffer) {
    UITextView *    tv;
    int             i;
    int *           j;

...
}

char* foo(IULabel* label, char* buffer) {
    UITextView*    tv;
    int             i;
    int*            j;

...
}

你是怎么做到的?

8 个答案:

答案 0 :(得分:13)

我使用的风格:

char *x;

因为这在逻辑上反映了C解析声明的方式 - “定义遵循使用”规则。不要认为“xchar *”,请认为“*xchar”。

这使您可以正确解析这些定义:

const char *x;

*xconst char

char * const x;

x,常数,在应用*后是一个字符)

char *x, y, **z;

*xcharychar**z是char)

<强>附录:

回应几条评论......

声明可以写成TYPE LABEL;的想法最终会破坏更复杂的类型,即使你在一行上禁止多个声明(我不同意,也是:int i, j;一直是惯用的C)。例如,如果我想将x声明为“指向10个数组的数组的指针”,则类型为char (*)[10](例如,这就是您在演员表中编写它的方式)。但是你不能使用TYPE LABEL;模式:

char (*)[10] x;    /* Not valid C :( */

函数指针是另一个例子。在这一点上通常的反驳是“总是使用typedef来复杂类型!”,在这里我觉得我们必须简单地分道扬and并同意不同意。您要么考虑逻辑上的不一致性和限制(“每行只声明一个变量”,“总是从简单的typedef中构建复杂类型”),要使声明看起来像您认为的那样,或者您没有

在回应Stroustrup评论时,我注意到K&amp; R使用char *x样式,在这里看起来我们在这个风格问题上有C / C ++分歧的根源。

答案 1 :(得分:4)

一位教授曾在大学告诉我“最重要的一贯风格规则”。只要你在各地都做同样的事情,这没关系。如果您是唯一一个从事该项目的人,请做出最适合您的事情。否则,与其他开发者一起提出,形成共识并与之合作。

答案 2 :(得分:4)

我认识的大多数C程序员都写道:

int *x;

我认识的大多数C ++程序员都写道:

int* x;

我认为这是因为C程序员认为x是“指向要解释为int的内存块的指针”,而C ++程序员则认为x更像是“int *类型的对象”

我是汇编程序员,但我喜欢第一种风格。

答案 3 :(得分:3)

编码风格完全是主观的,但我喜欢这个:

char* foo = "Foo";

对我来说更有意义,因为类型是*指向char的指针,所以指针符号出现在类型说明符旁边似乎很自然。

编辑:我认为stephentyrone在他的假设中可能是正确的。

答案 4 :(得分:3)

你的第一个会减少混乱。否则:

int* x, y;
乍一看,它们似乎是同一类型,但它们不是。第一个是指向int的指针,第二个是int。这更清楚:

int *x, y;

答案 5 :(得分:2)

这种格式的缺点之一:

UITextView *tv;
int         i;
int        *j;

有一天你需要添加另一个变量,其类型的字符多于UITextview

UITextView *tv;
int         i;
int        *j;
SomeOtherDataType t;

,您可以选择弄乱列布局并留下 broken window1 ,或者为其他变量添加空格并提交的修订控制行为引入模糊材料变化的不必要的重新格式化

我的偏好是每行声明一个变量,在有意义时按类型排序,并牺牲一些垂直空间以支持可读性和易于评论:

UITextView
   *tv;         // Data to be edited by the user.
int
    i,          // One-based index (for compatibility with BASIC)
   *j;          // Will be malloc'ed -- free it later.
SomeOtherDataType
    t;          // See p. 23 of req'ts doc for details.

然而,我对此并不完全满意,并且有兴趣看到其他解决方案。你的是什么?


<小时/> 1 如果我没有提到引用整篇文章here,我会失职。杰夫,你欠我20美元的地方? : - )

答案 6 :(得分:1)

这取决于语言是否使用,还取决于IDE的自动功能。

在C#中我不对齐行结尾,因为有注释分隔声明。

但是在VHDL中,声明很常见且表示布线,我更喜欢将行结尾与第二种格式对齐。

试一试,看看哪一个会更舒适,更节省时间。

答案 7 :(得分:1)

我认为这肯定是主观的,但如果我要对齐名称,那么我会将修改器直接放在它们旁边并直接对齐名称

char *foo(IULabel *label, char *buffer) {
  UITextView *tv;
  int         i;
  int        *j;

  ...
}

但通常,我只是做

char *foo(IULabel *label, char *buffer) {
  int i;
  int *j;
  UITextView *tv;
  ...
}

如果订单无关紧要,我会尝试从“短线”到“长线”订购东西:)