所谓的编程 style 真是个让人纠结的事情

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 3721 天前的主题，其中的信息可能已经有所发展或是发生改变。

就拿花括号来说吧，我至少已经折腾了2次关于花括号的style了。

一开始是这样：
if (exp) {

} else {

}

但是时间长了就发现问题了，有的时候这样就显得特别密，挨得太紧了

然后又这样：
if (exp)
{

}
else
{

}

额，时间长了现在又觉得，妈的，这样也不咋滴，有的时候花括号里只有一个语句的时候就显得很蛋疼，不用括号又不行，得保持编程风格的统一不是。

期间还这样过：
if (exp) exp1;

还这样过：
if(exp) exp1;

然后有段时间觉得python那样整挺好，但是时间长了发现也有这样那样的问题。于是虽然纠结，还是决定，妈的，既然怎样都不会满意，就这样吧，不管了。

于是就这样了：
if (exp)
{

}
真是纠结，其实写程序就是人生的写照啊，trade off。上帝保佑我不要哪天突然觉得不满意再次试图改变编程风格。

括号

exp

编程

47 条回复 • 2014-10-25 04:00:56 +08:00

dorentus

2014-10-23 16:08:57 +08:00

int main()
{
if (exp) {
}
else {
}

return 0;
}

jetbillwin

2014-10-23 16:11:47 +08:00

编程风格不是需要强制遵循，但是他所产生的目的是促进团队之间的代码规范，减少审阅代码时候的难度。没有团队，编程风格的意义不大；有了团队，却特立独行坚持自己的风格，团队合作的灾难。

jiyinyiyong

2014-10-23 16:12:14 +08:00

所以说缩进才是设计更合理的编程风格
其次使用 end 来标记代码块
再其次像 Go 那样强制放在行尾
再其次使用 Lisp 风格的圆括号

jox

2014-10-23 16:14:57 +08:00

@dorentus 我试过这样子，函数单独那样整，其他的那样整，最后还是全部都用函数那样的，老纠结了。也许想在程序中获得“生命的大和谐”这件事情本身就是错的，从一开始我就错了。

logeable

2014-10-23 16:15:09 +08:00

强迫症伤不起,硬是要
if(exp)
{

}
else
{

}

while(exp)
{

}

hcymk2

2014-10-23 16:17:55 +08:00

我觉得LZ是不过几天就会发PHP到底是不是最好的语言的类似帖子了。

jox

2014-10-23 16:18:33 +08:00

@jetbillwin 是啊，一般都是头头儿说我们要这么整，那我们下面的就没啥好纠结的了。但是自己写的程序有的时候用的编程语言跟工作上用的编程语言不一样啊，这个时候就蛋疼了。

@jiyinyiyong python那样只靠缩进来区分的也挺操蛋的，写一条语句，编辑器很难知道我是什么意思，只能自己瞎猜。

jsq2627

2014-10-23 16:20:02 +08:00

谭浩强
int main(){
return 0;}

gangsta

2014-10-23 16:21:01 +08:00

看下这个:
https://github.com/Suxiaogang/Code_Guide

jiyinyiyong

2014-10-23 17:12:32 +08:00

@jox 这个判断是基于习惯的.. 当然这个问题也跟习惯关系紧密
如果你对缩进不敏感甚至喜欢随手写错, 我再怎么说缩进好你也不会同意的
真的用缩进, 空白和 tab 的使用非常严谨, 很少会出错
而编译器识别缩进(当然打错字符另算)比人强大多了, 不知道哪个语法解析那么弱

songco

2014-10-23 17:14:03 +08:00 via iPhone

团队使用相同的IDE code format配置，用一段时间就习惯了…

limbo0

2014-10-23 17:15:10 +08:00

换python!!!

nicai000

2014-10-23 17:15:58 +08:00

你没有规则, Linux kernel的规则是能嵌套的结构就不换行例如if, 不能嵌套的block就换行例如函数

jox

2014-10-23 17:21:10 +08:00

@jiyinyiyong 不是编译器，是编辑器。现在的编辑器好多都带自动缩进的功能嘛，一敲回车，下一行就帮用户自动缩进了，python的话缩进决定了代码块，在一个函数里，前几行还好说，开始出现结构体之后就不好判断了，假设我是编辑器，用户敲一下回车，我上哪知道用户的这一行是要跳出之前的代码块呢还是要继续留在这个代码块里编辑呢，这样自动缩进实现起来就很困难，我反正是不知道该咋整。

但是带括号或者end这样标记的，就没有这个问题。另外除了python的解释器，编译器识别缩进干啥？python的解释器分析的是完整的一段代码，而我说的是情况是编辑器需要预测，因为python存在多种情况，这怎么预测嘛

Doubear

2014-10-23 17:29:15 +08:00

某猿下班路过天桥，见一人欲跳河自杀，忙冲上前去拉住那人。
“兄弟，世界如此美好，何以自寻短见？”
“哎！我写的程序老是出问题，领导把我炒了。女朋友因为我被炒，也跟我分手了，活着还有什么意思。”
“啥？程序员？大括号放同行还是下一行？”说罢紧紧盯着跳河哥。
跳河哥一愣，“下一行，咋了？哎~！”
跳河哥话没完，已经被一觉踹下了河。同时传来了一声怒吼：“去死吧！异教徒！”

caiych

2014-10-23 17:29:52 +08:00

@jox 也是有办法的吧…
双回车作为返回上一级缩进，为了逻辑清晰加的空行1个差不多就够了吧。

otakustay

2014-10-23 17:36:16 +08:00

于是我现在是这样：

if (exp) {

}
else {
}

jox

2014-10-23 17:40:22 +08:00

@Doubear 这个把我逗笑了，这个太特么逗了

@caiych 这样其实本质上跟使用花括号和end标记是一样的，都需要用户输入额外的信息才能准确判断用户的意图，这种解决方案其实还不如直接用标记呢，标记可以自动化，双回车还得用户自己敲

caiych

2014-10-23 17:50:37 +08:00

@jox 我觉得差不多吧。双回车不必标记差，自动生成的标记结束的时候也要出去嘛。
用户无论如何是需要做一点什么的

happywowwow

2014-10-23 17:53:41 +08:00

if(exp){

}
else{

}

while(exp){

}
一直喜欢这样，没变过

python 无烦恼

LMkillme

2014-10-23 17:53:54 +08:00

函数
- (void) func()
{

}

if (){

}else{

}

for (){

}

while(){

}

jox

2014-10-23 18:03:47 +08:00

@caiych python我就是觉得在试图解决可读性这个问题的时候又带来了新的问题，我觉得设立标准之后利用工具自动化是更好的解决方案，不过通过缩进来提升可读性效果不大，看别人的或者自己6个月前写的代码总是不容易的。嘛，又跑题了。

banbanchs

2014-10-23 18:05:44 +08:00

@jox 默认继续代码块，想跳出按退格就返回上一级缩进，现在我接触的编辑器/IDE都是这么干的，而已感觉上就跟其他括号标记的语言输入个'}'一样嘛

kaizixyz

2014-10-23 18:10:02 +08:00

同一个项目组
用
同一个IDE
同一个格式化插件
同一个格式化配置
然后设成每次保存文件之后自动格式化~

这样风格不一致也不行啦
然后合并代码就简单多啦~

然后其实我喜欢以下风格多一些

if (exp)
{

}
else
{

}

sanddudu

2014-10-23 18:13:37 +08:00

一开始那个其实叫 K&R 风格，我也一直在用，好处是代码比较紧凑

当然还是根据个人喜好定

jiyinyiyong

2014-10-23 18:37:15 +08:00

@jox 哦, 看错了.
你说的问题, 对我来说, 在多层缩进结束之后, 怎么回到正确的缩进, 确实有点不舒服
可能我没有依靠编辑器自动提供缩进的原因, 我觉得这个很自然应该是程序员做的
不过还好动态语言的代码通常依靠灵活性来缩减了长度, 我觉得问题还在能接受范围内
而且依赖缩进线的话问题也比较容易解决

深层的区别是写代码时, 依赖编辑器调整代码块, 还是程序员自己调整代码块
依赖编辑器就需要引入新的符号方便算法去识别, 这些符号就有可能形成干扰
手动维护代码块就可能出现深层嵌套结束不容易调整..
随我来说有个括号在哪跳来跳去搞不好还编辑错了, 是我不能忍的

xxstop

2014-10-23 18:37:18 +08:00

if () {
// 这种是最好看的style...
}

ffffwh

2014-10-23 18:39:33 +08:00

我一般大括号必加，哪怕只有一行

lincanbin

2014-10-23 18:57:28 +08:00

我现在是这样
```
if (exp)
{
/*
Code1
*/
}else {
/*
Code2
*/
}
```

Neear

2014-10-23 19:33:32 +08:00

这几天觉得horstmann style 不错
if(exp)
{ //this code
//code
}
但是支持此风格的编辑器不好找

Neear

2014-10-23 19:34:20 +08:00

if(exp)
{(3 space) //this code
(4 space)//code
}

librehat

2014-10-23 20:17:46 +08:00

我觉得KDE他们的Style不错，努力把自己的style和他们统一

zts1993

2014-10-23 20:28:12 +08:00

我比较喜欢 IDE自动排版的风格

levn

2014-10-23 20:43:31 +08:00

lisp是最好的语言

Hysteria

2014-10-23 20:52:15 +08:00

@dorentus 握爪，我一直这种风格。

lushl9301

2014-10-23 21:41:25 +08:00

平时自己写严格follow google的c style。

看linux的丧失tab indent到也是可以接受这个设定。。。lol

kemad

2014-10-23 22:04:17 +08:00 via iPad

其实像Go一样，官方出个fmt工具就没人争了。

precisi0nux

2014-10-23 22:07:58 +08:00 via iPhone

Life is short, use Python.

leyle

2014-10-23 22:46:34 +08:00

int main()
{
int a = 1, b = 2, xxx = 3;
if(exp = jiong)
{
xxx = 4;
}
else
{
zzz;
}

return 0;
}

leyle

2014-10-23 22:47:24 +08:00

@leyle 自动把我的空格缩进给去掉了。我是四个空格缩进。

jox

2014-10-23 22:49:30 +08:00

@leyle 那啥，你这段代码似乎有点问题，第一个if里面是个赋值语句。

另外我觉得这样初始化变量不太好
int a = 1;
int b = 2;
int xxx = 3;

这样我觉得好一些，要是初始化变量的话，我一般都这么写。

yfwu

2014-10-24 08:18:29 +08:00 via Android

看到樓上有人說缩进 > end 代码块 > Go 强制放在行尾 > Lisp 风格的圆括号

身為王垠粉絲我表示順序應該顛倒過來
先不說 Lisp 前綴表示對應語法樹之簡潔
縮排對於操作代碼（移動，或是附加到 with as 結構中）根本是種災難
不需要額外考慮格式的語言才好
就好像用 markdown 寫博文不需要考慮字體一樣

leyle

2014-10-24 09:43:26 +08:00

@jox 嗯，确实少写了个等号。^-^
我是两种初始化风格都在用，如果是简单无意义名字的变量，比如上面的 a，b，i，j 这些，我就写在一行，用逗号表达式了，
如果是有意义的名字，比如说 apple， price，v2ex 这些，就是一行语句只初始化一个变量。