|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
我的文章不会对您的学习起到实质性的作用,您能否成功,还得靠自己的,坚持,坚持,再坚持,就是步入成功的不二法门。标准 If Then Else 格局
结构
这由法式员决意。分歧的花括号款式会发生些微分歧的样不雅。一个通用体例是:
if (前提1) // 正文
{
}
else if (前提2) // 正文
{
}
else // 正文
{
}
假如你有效到else if 语句的话,凡是最好有一个else块以用于处置未处置到的其他情形。可以的话
放一个纪录信息正文在else处,即便在else没有任何的举措。
前提格局
老是将恒量放在等号/不等号的右边,例如:
if ( 6 == $errorNum ) ...
一个缘由是假设你在等式中漏了一个等号,语法反省器会为你报错。第二个缘由是你能立即找到数值
而不是在你的表达式的末尾找到它。需求一点工夫来习气这个格局,然而它的确很有效。
--------------------------------------------------------------------------------
switch 格局
Falling through a case statement into the next case statement shall be permitted as long as a comment is included.
default case总应当存在,它应当不被抵达,但是假如抵达了就会触发一个毛病。
假如你要创建一个变量,那就把一切的代码放在块中。
例如
switch (...)
{
case 1:
...
// FALL THROUGH
case 2:
{
$v = get_week_number();
...
}
break;
default:
}
--------------------------------------------------------------------------------
continue,break 和 ? 的利用:
Continue 和 Break
Continue 和 break 实际上是变相的荫蔽的 goto办法。
Continue 和 break 像 goto 一样,它们在代码中是有魔力的,所以要俭仆(尽量少)的利用它们。
利用了这一复杂的魔法,因为一些未公然的缘由,读者将会被定向到只要天主才晓得的中央去。
Continue有两个次要的成绩:
它可以绕过测试前提。
它可以绕过等/不等表达式。
看看上面的例子,思索一下成绩都在哪儿产生:
while (TRUE)
{
...
// A lot of code
...
if (/* some condition */) {
continue;
}
...
// A lot of code
...
if ( $i++ > STOP_VALUE) break;
}
注重:"A lot of code"是必需的,这是为了让法式员们不克不及那末轻易的找失足误。
经由过程以上的例子,咱们可以得出更进一步的划定规矩:continue 和 break 夹杂利用是引发灾害的准确办法。
?:
费事在于国民常常试着在 ? 和 : 之间塞满了很多的代码。以下的是一些明晰的毗连划定规矩:
把前提放在括号内以使它和其他的代码相分别。
假如能够的话,举措可以用复杂的函数。
把所做的举措,“?”,“:”放在分歧的行,除非他们可以清晰的放在统一行。
例如
(condition) ? funct1() : func2();
or
(condition)
? long statement
: another long statement;
--------------------------------------------------------------------------------
声明块的定位
声明朝码块需求对齐。
来由Justification
明晰。
变量初始化的相似代码块应当列表。
The ??token should be adjacent to the type, not the name.
例如
var $mDate
var& $mrDate
var& $mrName
var $mName
$mDate = 0;
$mrDate = NULL;
$mrName = 0;
$mName = NULL;
--------------------------------------------------------------------------------
每行一个语句
除非这些语句有很亲切的接洽,不然每行只写一个语句。
--------------------------------------------------------------------------------
短办法
办法代码要限制在一页内。
来由
这个思惟是,每个办法代表着一个完成独自目标的手艺。
从久远来讲,过量的有效参数是毛病的。
挪用函数比不挪用要慢,然而这需求具体思索做出决意(见premature optimization 未完美的优化)。
--------------------------------------------------------------------------------
纪录一切的空语句
老是纪录下for或是while的空块语句,以便清晰的晓得该段代码是漏失落了,仍是居心不写的。
while ($dest++ = $src++)
; // VOID
--------------------------------------------------------------------------------
不要采取缺省办法测试非零值
不要采取缺省值测试非零值,也就是利用:
if (FAIL != f())
比上面的办法好:
if (f())
即便 FAIL 可以含有 0 值 ,也就是PHP以为false的暗示。在或人决意用-1取代0作为掉败前往值的时分,
一个显式的测试就能够匡助你了。就算是对照值不会变更也应当利用显式的对照;例如:if (!($bufsize % strlen($str)))
应当写成:if (($bufsize % strlen($str)) == 0)以暗示测试的数值(不是布尔)型。一个常常出
成绩的中央就是利用strcmp来测试一个字符等式,了局永久也不会等于缺省值。
非零测试采取基于缺省值的做法,那末其他函数或表达式就会遭到以下的限制:
只能前往0暗示掉败,不克不及为/有其他的值。
定名以便让一个真(true)的前往值是相对明显的,挪用函数IsValid()而不是Checkvalid()。
--------------------------------------------------------------------------------
布尔逻辑类型
大局部函数在FALSE的时分前往0,然而发扬非0值就代表TRUE,因此不要用1(TRUE,YES,诸如斯类)等式检测一个布尔值,应当用0(FALSE,NO,诸如斯类)的不等式来取代:
if (TRUE == func()) { ...
应当写成:
if (FALSE != func()) { ...
--------------------------------------------------------------------------------
凡是防止嵌入式的赋值
有时分在某些中央咱们可以看到嵌入式赋值的语句,那些布局不是一个对照好的少冗余,可读性强的办法。
while ($a != ($c = getchar()))
{
process the character
}
++和--操作符相似于赋值语句。因而,出于很多的目标,在利用函数的时分会发生反作用。利用嵌入式赋值
进步运转时功能是能够的。不管如何,法式员在利用嵌入式赋值语句时需求思索在增加的速度和削减的可维
护性二者间加以衡量。例如:
a = b + c;
d = a + r;
不要写成:
d = (a = b + c) + r;
固然后者可以节俭一个周期。但在久远来看,跟着法式的保护费用垂垂增加,法式的编写者对代码垂垂遗忘,
就会削减在成熟期的最优化所得。
--------------------------------------------------------------------------------
重用您和其别人的艰辛任务
跨工程的重用在没有一个通用布局的情形下几近是不成能的。对象合适他们现有的办事需求,分歧的进程有着
分歧的办事需求情况,这使对象重用变得很坚苦。
开辟一个通用布局需求事后消费很多的勉力来设计。当勉力不胜利的时分,不管出于甚么缘由,有几种举措推
荐利用:
就教!给群组发Email乞助
这个复杂的办法很少被利用。由于有些法式员们感觉假如他向其别人乞助,会显得本人程度低,这多傻啊!做新
的风趣的任务,不要一遍又一遍的做他人已做过的器材。
假如你需求某些事项的源代码,假如已有或人做过的话,就向群组发email乞助。了局会很欣喜哦!
在很多大的群组中,团体常常不晓得其别人在干甚么。你乃至可以发明或人在找一些器材做,而且自愿为你写代
码,假如人们在一同任务,里面就总有一个金矿。
告知!当你在干事的时分,把它告知一切人
假如你做了甚么可重用的器材的话,让其别人晓得。别害臊,也不要为了回护骄傲感而把你的任务功效藏起来。
一旦养成同享任务功效的习气,每一个人城市取得更多。
Don't be Afraid of Small Libraries
关于代码重用,一个罕见的成绩就是人们不从他们做过的代码中做库。一个可重用的类能够正荫蔽在一个法式目
录而且决不会有被分享的冲动,由于法式员不会把类分拆出来到场库中。
如许的个中一个缘由就是人们不喜好做一个小库,对小库有一些不准确感到。把如许的感到克制失落吧,电脑才不
关怀你有几何个库呢。
假如你有一些代码可以重用,并且不克不及放入一个已存在的库中,那末就做一个新的库吧。假如人们真的思索重
用的话,库不会在很长的一段工夫里坚持那末小的。
If you are afraid of having to update makefiles when libraries are recomposed or added then don't include libraries in your makefiles, include the idea of services. Base level makefiles define services that are each composed of a set of libraries. Higher level makefiles specify the services they want. When the libraries for a service change only the lower level makefiles will have to change.
Keep a Repository
Most companies have no idea what code they have. And most programmers still don't communicate what they have done or ask for what currently exists. The solution is to keep a repository of what's available.
In an ideal world a programmer could go to a web page, browse or search a list of packaged libraries, taking what they need. If you can set up such a system where programmers voluntarily maintain such a system, great. If you have a librarian in charge of detecting reusability, even better.
Another approach is to automatically generate a repository from the source code. This is done by using common class, method, library, and subsystem headers that can double as man pages and repository entries.
--------------------------------------------------------------------------------
评价正文
正文应当是讲述一个故事
Consider your comments a story describing the system. Expect your comments to be extracted by a robot and formed into a man page. Class comments are one part of the story, method signature comments are another part of the story, method arguments another part, and method implementation yet another part. All these parts should weave together and inform someone else at another point of time just exactly what you did and why.
Document Decisions
Comments should document decisions. At every point where you had a choice of what to do place a comment describing which choice you made and why. Archeologists will find this the most useful information.
利用标头申明
使用相似ccdoc的文档抽取体系。在这一文档的其他局部描写的是怎样使用ccdoc纪录一个类和办法。
这些标头申明可以以如许的一个体例来提取并剖析和加以组织,它们不像普通的标头一样是无用的。
因而花工夫去填上他吧。
正文结构
工程的每局部都有特定的正文结构。
Make Gotchas Explicit
Explicitly comment variables changed out of the normal control flow or other code likely to break during maintenance. Embedded keywords are used to point out issues and potential problems. Consider a robot will parse your comments looking for keywords, stripping them out, and making a report so people can make a special effort where needed.
Gotcha Keywords
:TODO: topic
Means there's more to do here, don't forget.
:BUG: [bugid] topic
means there's a Known bug here, explain it and optionally give a bug ID.
:KLUDGE:
When you've done something ugly say so and explain how you would do it differently next time if you had more time.
:TRICKY:
Tells somebody that the following code is very tricky so don't go changing it without thinking.
:WARNING:
Beware of something.
:PHARSER:
Sometimes you need to work around a pharser problem. Document it. The problem may go away eventually.
:ATTRIBUTE: value
The general form of an attribute embedded in a comment. You can make up your own attributes and they'll be extracted.
Gotcha Formatting
Make the gotcha keyword the first symbol in the comment.
Comments may consist of multiple lines, but the first line should be a self-containing, meaningful summary.
The writer's name and the date of the remark should be part of the comment. This information is in the source repository, but it can take a quite a while to find out when and by whom it was added. Often gotchas stick around longer than they should. Embedding date information allows other programmer to make this decision. Embedding who information lets us know who to ask.
Example
// :TODO: tmh 960810: possible performance problem
// We should really use a hash table here but for now we'll
// use a linear search.
// :KLUDGE: tmh 960810: possible unsafe type cast
// We need a cast here to recover the derived type. It should
// probably use a virtual method or template.
See Also
See Interface and Implementation Documentation for more details on how documentation should be laid out.
--------------------------------------------------------------------------------
Interface and Implementation Documentation
There are two main audiences for documentation:
Class Users
Class Implementors
With a little forethought we can extract both types of documentation directly from source code.
Class Users
Class users need class interface information which when structured correctly can be extracted directly from a header file. When filling out the header comment blocks for a class, only include information needed by programmers who use the class. Don't delve into algorithm implementation details unless the details are needed by a user of the class. Consider comments in a header file a man page in waiting.
Class Implementors
Class implementors require in-depth knowledge of how a class is implemented. This comment type is found in the source file(s) implementing a class. Don't worry about interface issues. Header comment blocks in a source file should cover algorithm issues and other design decisions. Comment blocks within a method's implementation should explain even more.
--------------------------------------------------------------------------------
总的来说,在这一个月左右的时间中,学到的不少,但是也遇到不少的问题,比如批量图片的上传,一直到现在也不懂,如何实现动态的增加上传图片的数量。 |
|