清晰的书写格式对编程很重要
本帖最后由 apple_03 于 2012-9-24 00:38 编辑近日,由于需要翻看了WINCE的驱动源代码,不看则已,一看惊人!
请看以下一段:PHYSICAL_ADDRESS ioPhysicalBase = { dwi.ioWindows.dwBase, 0};
ULONG inIoSpace = 1;
if (TranslateBusAddr(m_hParent,(INTERFACE_TYPE)dwi.dwInterfaceType,dwi.dwBusNumber, ioPhysicalBase,&inIoSpace,&ioPhysicalBase)) {
if (inIoSpace) {
m_bIsIo = TRUE;;
m_pRegVirtualAddr = (PVOID)ioPhysicalBase.LowPart;
}
else {
// Map it if it is Memeory Mapped IO.
m_pRegVirtualAddr = MmMapIoSpace(ioPhysicalBase, dwi.ioWindows.dwLen,FALSE);
m_bIsIo = FALSE;
}
}
return (m_pRegVirtualAddr!=NULL);
注意第3行的末尾,这个“{”竟然是第133列的位置上!如此遥远的位置,很容易让人漏看了。
M$怎么也是大公司,代码的书写方式居然如此丑陋。
写成: PHYSICAL_ADDRESS ioPhysicalBase = { dwi.ioWindows.dwBase, 0};
ULONG inIoSpace = 1;
if (TranslateBusAddr(m_hParent,(INTERFACE_TYPE)dwi.dwInterfaceType,dwi.dwBusNumber, ioPhysicalBase,&inIoSpace,&ioPhysicalBase))
{
if (inIoSpace)
{
m_bIsIo = TRUE;;
m_pRegVirtualAddr = (PVOID)ioPhysicalBase.LowPart;
}
else
{
// Map it if it is Memeory Mapped IO.
m_pRegVirtualAddr = MmMapIoSpace(ioPhysicalBase, dwi.ioWindows.dwLen,FALSE);
m_bIsIo = FALSE;
}
}
return (m_pRegVirtualAddr!=NULL);不是很清晰吗?功能段的起始和结束在何处一目了然,头绪也厘得很清楚。
这只是不同的风格而已,但是你仔细看,他们是有对齐的,知道的人都懂的~~ 本帖最后由 apple_03 于 2012-9-24 00:50 编辑
是的,是需要“很仔细”看。这无疑是增加难度,浪费时间,清晰一点不好吗?
难怪M$整天发补丁,说不准和这有关系呢{:lol:} 确实有人喜欢把左花括号写在末尾的,我也是习惯都写在左侧。但是看起来都没觉得有太大问题,可能是习惯了 本帖最后由 myqiang1990 于 2012-9-24 01:05 编辑
我也非常不喜欢这种风格...让人对半天...总让人感觉乱七八糟的..但是大师级人物偏偏喜欢这种风格..还真烦....有时候我宁愿用格式化工具。。从新格式化一次代码。。变成其他第二种风格再看.... 人家微软看代码都不用人,用机器自已找
还有一堆专门写代码的机器人。。。^)^ 我就一直喜欢把“{”放在末尾,不知道那些人说不看不懂是什么意思,还是没找到方法。放在末尾有一个好处,看代码从来不用管“{”的以关键字为开始,以“}结束”。
if(a!=B){ //以关键字为开始
代码;
for(;;){ //以关键字为开始
代码;
} //for结束
} //if结束 风格不一样,吧,以后看到if else 默认后面有一个{ ,为了验证可以ctrl+end看一下 代码风格的问题!
实际上,这种风格可以节省很大阅读的空间。也是非常多的工程师喜欢的风格。
如果用带有 ”括号对齐显示“ 文本浏览器看起来,是非常的轻松的。 本帖最后由 apple_03 于 2012-9-24 09:38 编辑
117433525 发表于 2012-9-24 02:34 static/image/common/back.gif
这种所谓的“省空间”的想法,应该抛弃。
我还见过这种:
if(Upstate==KEY_IN){if(Count>=40){if(Task==0){if()}.... }....}
是不是更省空间?
是否愿意这样写?
书写整齐,易看,不产生歧义才是最好,“省空间”的想法早已过时了:
1、现在的硬盘那么大,在整个代码工程来看,省那一行的作用,完全可以忽略;
2、现在编辑器的功能强大了,使用代码折叠功能,N多行的代码都可以一行代替显示,
如果你的编辑器没有代码折叠动能,建议还是及早更换。
在M$的代码里,那个 “{”竟然可以在 133列,很多编辑器都屏幕完整显示这一行,
必须费力地使用右向光标,或者拉鼠标。省下来的一行,造成阅读的时间,体力的浪费,
简直是谋财害命。 我比较喜欢花括号(或Begin)在左边独占一行。 本帖最后由 117433525 于 2012-9-24 10:09 编辑
apple_03 发表于 2012-9-24 09:29 static/image/common/back.gif
这种所谓的“省空间”的想法,应该抛弃。
我还见过这种:
我还见过这种:
if(Upstate==KEY_IN){if(Count>=40){if(Task==0){if()}.... }....}
是不是更省空间?
=====================================================
你说的这种肯定是不行的,但是不明白的是以关键字为开始,和你的单独站一行花括号就影响那么大就会那么丑陋吗?你要对查看代码的开始是以左边花括号开始,那请问这个花括号的上面一行你不用看吗,你直接不看那个括号就行了,只看关键字。
完全就是风格的问题,你看不懂只能说你没掌握方法。我是看起来两种都一样。 我喜欢楼主的头像{:lol:} 又是这个争论,没意义的。
我一直坚持“K&R”风格,就是楼主位MS的风格。 同意117433525 ,我就是这么搞的。而且我也不觉得在浏览代码上有多难受,很清晰,一目了然。 本帖最后由 apple_03 于 2012-9-24 11:46 编辑
117433525 发表于 2012-9-24 10:20 static/image/common/back.gif
看来你确实不明白:
出现这两种情况:
1:
if (a==BBBBBBBBBBBBBBBBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRRRRRRRROOPPPPYYYYYYYYYYTTTTTTTTTTTTTT) break;
if (b==MGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH9999999999999999999999999999) {
.....
.....
}
2:
if (a==BBBBBBBBBBBBBBBBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRRRRRRRROOPPPPYYYYYYYYYYTTTTTTTTTTTTTT) {
if (b==MGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH9999999999999999999999999999)break;
.....
.....
}
======================================================================
代码行超长,在显示器上无法一次看到完整一行的时候(133列,甚至更长的时候),依靠关键字能马上判断对应关系吗?
说明一下:在M$的PB5.0,PB6.0的里,是没有117433525画的那种虚线对应图的,而且代码行之间几乎没有空行,看起来麻烦很多。 喜欢花括号在左边另占一行的风格,看起来比较规整。 国外很多代码都是这样的风格的,这点毋庸置疑。
至于楼主抱怨的问题,我觉得是程序员不想为了几个长语句而破坏风格一致性。 你想,其他所有代码都是起始花括号在前,唯有一部分不一样,是不是也挺别扭的?
apple_03 发表于 2012-9-24 11:44 static/image/common/back.gif
看来你确实不明白:
出现这两种情况:
我是喜欢{独占一行的方式,但是你提到的这个我认为是一种不规范,一行的长度超过一定值的时候例如40个,就应该换行.(这个在华为编程规范里面也有提到,这个是很好的).不过"{"在行尾的好处也学习了(之前不知道为什么这么写,但是书上就说linux下的代码需要这种规范). 就是这种情况了:
出现这两种情况:
1:
if (a==BBBBBBBBBBBBBBBBDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDRRRRRRRROOPPPPYYYYYYYYYYTTTTTTTTTTTTTT) break;
if (b==MGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHH9999999999999999999999999999) {
.....
.....
}
2:
if (a==BBBBBBBBBBBBBBBBDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDRRRRRRRROOPPPPYYYYYYYYYYTTTTTTTTTTTTTT) {
if (b==MGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHH9999999999999999999999999999)break;
.....
.....
}
======================================================================
永远的 k & r 风格。。。。。 我也喜欢用楼主位这种风格。 个人喜好而已 一致性的问题吧
知道这个东西有问题也只能接着用
我自己写程序的时候也是,往往是到了快结束时发现某些地方可以改进,但是改毛啊,又不是什么致命问题,下一个工程再统一升级。
难受啊,想改啊,但是忍住了。
这算是强迫症的一种么?{:sweat:} 经典C的风格啊。
不过我还是喜欢括号独占一行那种 apple_03 发表于 2012-9-24 11:44 static/image/common/back.gif
看来你确实不明白:
出现这两种情况:
正确的应该写成:
1:
if (a==BBBBBBBBBBBBBBBBDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDRRRRRRRROOPPPPYYYYYYYYYYTTTTTTTTTTTTTT) break;
if (b==MGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHH9999999999999999999999999999) {
.....
.....
}
2:
if (a==BBBBBBBBBBBBBBBBDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDRRRRRRRROOPPPPYYYYYYYYYYTTTTTTTTTTTTTT) {
if (b==MGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHH9999999999999999999999999999)break;
.....
.....
}
自然是很清晰的 很规范的写法,缩进起到很重要的作用。
楼主如果去写Python估计要抓狂,因为Python是不使用花括号,纯粹靠缩进来表示作用域的。 {:titter:} 大公司的程序大部分是 lz位的写法的 gzhuli 发表于 2012-9-24 15:37 static/image/common/back.gif
很规范的写法,缩进起到很重要的作用。
楼主如果去写Python估计要抓狂,因为Python是不使用花括号,纯粹靠 ...
缩进能起阅读提示的作用,自己写代码甚至习惯手工用空格来缩进。 {:handshake:}
在C里,作用域是用"{" 和“}”来限制的,不是靠缩进来限制的。
至于python,没有弄过,所以没有抓狂 {:lol:}
相对而言,个人喜欢风格更优美,更严谨的Pascal {:tongue:} 本帖最后由 apple_03 于 2012-9-25 09:34 编辑
mitchell 发表于 2012-9-24 15:11 static/image/common/back.gif
正确的应该写成:
1:
你的写法是比较清晰的,我自己写代码也会采用这种方式。
你写的:
if (a==BBBBBBBBBBBBBBBBDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDRRRRRRRROOPPPPYYYYYYYYYYTTTTTTTTTTTTTT) break;
如果不是编辑器自动给换行的,那么应该是:
if (a==BBBBBBBBBBBBBBBBDDDDDDDDDDDDDDDDDDDDDDDDD \ // 续行符
DDDDDDDDDRRRRRRRROOPPPPYYYYYYYYYYTTTTTTTTTTTTTT) break;
但是,你去查一下WINCE里驱动的代码,每行长度超过120个字符的,比比皆是;
甚至可以整个代码没有一个空行。
可能M$是大公司,怪异的代码风格得到很多人追捧,标新立异或者是潮流吧。
年纪大了,不追赶潮流,还是坚持最正统的C。 "{" 放在哪里,有几种被大众接受的规范的:
K&R
缩进为4格,{跟在控制语句后面
GNU
函数类型定义另起一行。缩进为2格。{另起一行。
还有其他几个不是很记得了。
每个公司都有自己的规定,建议使用一种,MS的用的是K&R 风格,习惯问题而已,没有什么需要争议的。 JAVA风格全是放后面的 我也比较喜欢第二种风格。 个人习惯吧,我比较喜欢 { 占一行,看起来很清晰 各人风格不同而已,实际上如果if嵌套较多,且每个条件内代码比较多的话,还是楼主位的阅读起来更清晰明了 本帖最后由 monkerman 于 2012-9-25 10:15 编辑
唉......都是老师引导的好啊. 因为大家初学编程的时候老师绝大多数用的是楼主心目中的那种风格.{:lol:}
我以前也是书上的写法. 现在已经完全改过来了. 一是一屏阅读的代码量增加. 因为我不吝惜空行. 二是Linux, U-boot等优秀代码的风格就是这样, 混熟了就不厌了.
struct xxx {
xxxxx;
};
if () {
} else {
}
for () {
}
void foo(void )
{
}
switch () {
case :
case :
case :
}
萝卜白菜各有所爱. 不同风格而已.{:lol:} int16_t Math_min(int16_t value1,int16_t value2){
if(value1<value2)return value1;
return value2;
}
不知不觉,我已经习惯了后面带号了。 monkerman 发表于 2012-9-25 10:00 static/image/common/back.gif
唉......都是老师引导的好啊. 因为大家初学编程的时候老师绝大多数用的是这种风格.
我以前是书上的 ...
我的书写风格与您的完全相同。支持一下 lisn3188 发表于 2012-9-25 10:03 static/image/common/back.gif
int16_t Math_min(int16_t value1,int16_t value2){
if(value1
函数的括号还是另起一行比较好看 楼主如果多接触开源项目的话就会发现这种代码风格可能是最普遍的,并且有很多都直接写进了代码规范里面 Google的go语言甚至强制要求大括号放在后面的,大括号新起一行的风格直接就报语法错误! 括号独占一行打断阅读代码时候的大脑理解流程 还是关键字起行的好 本帖最后由 root 于 2012-9-28 11:22 编辑
不同的风格,一般像linux /GNU 都有自己的代码规范指引,可以下来自己看.印象中linux推荐的规范是这样的
不过偶不喜欢.偶喜欢那种初学者的规范,看起来清晰,一般我的屏幕分辨率大,所以多几行没有问题.而且我的函数也不是太长,并且我的缩进也不大,至于对齐就靠emacs了.
这是K&R提倡的风格但是还是有很大的差距..个人比较喜欢{:dizzy:} 我们公司的code的书写格式必须是楼主说的第二种, 不同国家的必须一致遵守的。
这样项目合作也好进行的。 eclipse格式化后的代码都是楼主这样的,个人觉得这种风格省空间,特别是有很多嵌套的if-else的地方,看习惯了就行,不能说它不好。 把“{”跟分支语句(if while等等)放在一行使得代码比较紧凑,我一般也这么写 本帖最后由 jimmy_xt 于 2012-11-5 09:33 编辑
纯粹的代码风格问题,完全是个人喜好了。
我用的是“Tab”缩进,“{”放在行首
(代码是抄别人的AVR的FAT32驱动中的一部分)
另,貌似论坛会对“Tab”进行转换,全乱了{:cry:}uint8_t read_line(char* buffer, uint8_t buffer_length)
{
memset(buffer, 0, buffer_length);
uint8_t read_length = 0;
while(read_length < buffer_length - 1)
{
uint8_t c = uart_getc();
if(c == 0x08 || c == 0x7f)
{
if(read_length < 1)
continue;
--read_length;
buffer = '\0';
uart_putc(0x08);
continue;
}
uart_putc(c);
if(c == '\n')
{
buffer = '\0';
break;
}
else
{
buffer = c;
++read_length;
}
}
return read_length;
}
页:
[1]