当前访客身份：游客 [
当前位置：
源代码管理十诫
若是还有可以毫无偏见地涉及各个编程语言，比源代码管理软件更必要的工具，我倒是很想见识一下。源代码管理软件是我们工作的必备工具，是许多开发团队的血液。那为什么我们都会对它有所误解呢？为什么都很难理解版本控制系统的核心价值和基本原理呢？
我总结出10条惯例——如果你愿意也可以用“戒律”——意味着必须服从它而且从一开始很难去理解。它们与所有类型编程语言的版本控制软件都有关联。在这里我选取了Subversion和.NET的几个例子，不过它们也广泛地适用于其他的一些技术。
第一诫.如果你现在还在使用VSS－请立刻停手
它已经死了。当然不完全对，它也存活了许多年，被全新的更实用的源代码管理工具超越之后还在苟延残喘地活着。准确地说当微软(还是会坚持一段时间的)，它才是真的死了。
平心而论，VSS还是一个不错的工具。在1995年，它的光芒被像Subversion这样类似于Git和Mercurial的分布式软件给遮盖住了。微软表示要取代它已经好多年了。
原因是因为不支持如今的标准所导致的一系列缺陷使它一直不被看好。众所周知它是，但不知何故它能坚持这么久，尽管它有那么多小故障，缺陷，并且不包含必需的功能（相对于今天的标准）。
第二诫.如果代码没放在源代码管理软件里，等于它不存在
每天重复读这句话——“使用源代码管理软件是唯一的有效措施”。除非你在工作时使用项目的源代码管理库来控制代码版本——否则代码等于没有存在过。
显然你曾发觉在你的本地机器上运行良好的代码在其他人那里运行的效果并不理想。是不是？他们不能获取你的最新版本，他们没法去归并代码文件，你没有正确地部署它（参考）而且如果你的SSD硬盘坏了的话你将永远地失去你的劳动成果。
只要你保持这个心态——代码只有提交后才是真的安全，才是其他良好编程习惯的保障。你可以把你的任务划分成许多很小的单元以便你逐一提交。你需要频繁地这么做。你就不必担心你的硬件会不会出棘手问题。
不过更重要的意义是（至少对于你的团队领导来说），通过源代码管理软件可以看到你做了什么。使用图表并列出项目清单是个好方法，不过怎么知道他们实际上在做些什么？而使用源代码管理软件进行工作就能看得一清二楚了。
第三诫.要早提交，常提交，并且不要觉得麻烦
关于前面那点，避免“幻影代码”（就是只能在你的机器上看到的代码）的唯一方法是经常提交你的任务并且不要觉得麻烦。它可以解决你的问题，不过这样做也会对你的工作产生其他的影响：
1.每个提交的修订都会为你提供一个还原点。如果你完全把代码搞砸了（没骗你，我们都这么做过），你是希望恢复到一个小时前的工作还是一周前的工作？
2.归并文件时会出现的危险会随着时间不断增加。归并文件一直很麻烦。如果你不是每天都保持提交代码，某一天你会突然发现你和其他人的更改内容会有50多个冲突。你不会为此感到高兴的。
3.它促使你把任务分离成分散的单元。通常人们都是快完成的时候才提交的，因为他们想把代码做成一个完整的逻辑单元模块。不过庞大的任务不可避免地要分离出较小的分散功能，而频繁地提交它们会使你更了解它们，你可以一个个地构建并提交。
如果你做到这些，你的提交历史不可避免地开始类似于一种半规律的样式，里面每个工作日都是在提交任务。当然不总是这样，也有停下来重构或测试，或者其他合理的活动也会中断标准的开发周期。
然而，当我在看一个独立的——尤其是完整的项目时，每当发现我们在一个标准的开发周期里，有一天或几天什么都没有做，我便会非常担忧。我之所以担忧 是因为这意味着什么地方出问题了。一般不是有人正在想方设法要把问题搞定的话，就是因为卡在某个问题上而导致项目完全没有进度。无论到底是什么情况，源代 码管理软件都会告诉你出现问题了。
第四诫.提交前要检查你更改了什么
往源代码管理软件里提交代码的步骤其实非常简单。（你恐怕会困惑上一条为什么说的那么麻烦。）一般只要发现文件内容有变更时都会不顾后果地把文件传上去。像这样——“我的项目根目录下有文件内容变更了，我要快点提交上去！”
如此会发生一件（或两件）事情：首先，程序员会没有意识地把目录下的垃圾代码文件也上传上去。一些人看到类似下面的窗口时，就会点击“选择全部”然后提交——这样源仓库里就会被本不应该存在的未调试的文件和其他垃圾文件给弄乱。
或者是，程序员实际上并没有检查他们更改过什么就把文件上传了。当你在工作中处理配置文件或项目定义文件时很容易就不经意把那些不想提交的文件给上传了，而且那些文件很可能就被别的程序员用到了。你真的会记住你在配置文件里的所有更改吗？
解决方法很简单：你必须在提交前立刻检查你改过什么地方。做起来其实比听起来还要容易。使用许多系统已经提供的“忽略”特性可以大幅度地减轻“不经意上传文件”的危险。你可以忽略Thumbs.db文件因为你压根不想上传它。你在每次修订后可能还有其他文件不想上传——那么就忽略掉它们吧！
至于文件里的更改，你通常可以使用某个流行的文本比较工具来观察差异。为什么我又要上传一次Web.config文件呢？
噢，我想起来了，我想把尝试密码失败的最大次数从5次减少到3次。啊，我差点没注意把一个虚拟的登录页面给上传上去了。这种在提交前做检查的练习可以让你更容易理解下一节的内容。
第五诫.写提交信息时一定要认真
这是一个古老的谚语（出处不详），大意是说“写每一条提交信息时就好象等下会读到它的人是一个斧头杀人狂，而且他还知道你住在哪里”。如果我是那个杀人狂并在研究你的代码想追踪bug的话，看到的提交信息全部都是“代码更新了”，小心，我会来砍你的！
我的解决办法就是解释清楚为什么要提交新的代码。每次你对代码进行更改都是有原因的。可能什么地方会崩溃。可能客户不喜欢现在的主题颜色。可能你仅仅要调整一下构建配置。无论是什么，这都是有原因的而且你要把原因用文字保留下来。
为什么？这样做的原因有很多，而且在不同环境下各不相同。举个例子，使用“归属”特性或其他类似的功能显示出谁改了代码那些地方。如果我不记得18 个月之前我对项目的Web.config文件改过什么地方或者我为什么要改动应用程序的设置，是因为我没有在当时留下一个适当的提交信息，而现在会非常简 单：
这是一个可以随时观察代码更改的软件的一种。无论我像下面那样想了解一个文件的完整更改历史，还是只想知道团队昨天做了什么，留下一个描述性的相关记录意味着只要不经意一瞥就能知道是什么情况了。
最后强调一下，当调试遇到错误时提交信息的重要性是无法估计的。举个例子，在你的集成环境里的最后更新的地方可以找到出错的原因。我的例子是非常显而易见的，不过把信息表示出来可以把很多棘手的问题变得极好解决。
把这条牢记于心，这里列出一些提交信息的反面教材：
1.可恶 2.能跑了 3.解决了一些混帐问题 4.解决了 5.改进了一点bug 6.上传了 7.排字错误 8.修订1024
好的，我从Stack Overflow网站的（译者注：帖子已经被删除了，原因难道是出现了脏话？）帖子里选取了以上内容，不过它们和我以前看过的提交信息并不相同。它们没有告诉你有关代码更改的任何有效信息；它们都是垃圾信息。
关于提交信息最后要注意的是；同一个程序员之后提交信息绝不能和前面的完全相同。原因很好理解：你向源代码管理 软件提交文件是因为对于上一个版本的代码有东西改变了。你现在的代码和之前的已经不一样了，如果你的提交信息是完整准确的，理论上就不能和前面的相同。如 果是相同的（可能有时真的会这样），日志就会难以阅读，因为没有办法区分两条提交有什么区别。
第六诫.你必须自己提交你的更改内容——不能委托他人
听起来很奇怪，但它的确会发生，我看过不止一次，最近的是上周。情况是这样的，源代码库被视为极高的地位。因为很多原因，团队会去追求完美代码的洁 净和单一。为了保持这种神圣的状态，代码只能由某个领头的程序员来提交，他在提交前会小心地整合，审查并（大概会）调整改善代码。
即使站在很远也能很容易评价这个方案。不太频繁的提交（可能一周几次），只有一个脱离团队其他程序员的人来提交，而且不可避免地在这段漫长的无提交时期里会有人的工作会导致项目混乱。非常非常不好。
这样做会有两个错误：首先，源代码管理软件并不意味着它里面代码是神圣不可侵犯的；至少在整个开发周期里是这样的。它应该是团队频繁整合文件，在出错时还原到正常并且共同解决问题的地方。不是自始至终都要这样做，只有在应用程序周期的发布时期为了达到某种状态时才做的。
另一个问题——并且真的是极为关键的——站在程序员的视角，这样等于你压根没有在用源代码管理软件！它等于没有同伴之间的代码整合，没有还原，提交信息没有负责人，什么都没有！你们仅仅是在自己的象牙塔里各自写各自的代码然后等着未来顺便某一天把它交给领导就完事了。
不要这样做。千万不要。
第七诫.一定要管理好数据库的版本
这一点是我们都知道必须要做的，但是很多人觉得它麻烦。问题是很多（或者是大部分）应用程序没了数据库就不能运行。如果你没有管理好数据库，那你实际上做的就是一个不完整的完全无用的应用程序。
几乎所有的版本控制系统的工作就是管理好文件系统内的文件。它只是对像HTML页面，图片，CSS，项目配置文件和其他在文件系统的独立单元这类典 型应用作用较大。问题是它确实没法在与程序有关联的数据库上起到作用。你总不能替换掉庞大的数据库，把所有旧数据文件和包含一大堆对象和数据日志文件统统 换掉。这样会让版本控制系统完全乱成一堆。
Red Gate公司开发的智能的使这个情况得到了合理解决。我在去年写的这篇帖子里详细说明了这款软件，所以我现在就不多说了；总之就是数据库管理现在会非常容易了！
老实说，如果你没有管理好你的数据库版本，你的开发会伴随着很大的问题。在更改数据库的时候没有源代码的管理，没有还原点，并且很难和团队密切合作。使用数据库版本控制系统可以使开发更轻松。
第八诫.编译生成的文件不要放进源代码管理软件里
简单地说：在编译运行项目时自动生成的结果文件不要放进源代码管理软件里。对于.Net开发的程序员，主要是&bin&和&obj&文件夹里通常会出现的.dll和.pdb文件。
为什么？因为如果你这样做，你的同事会恨你的。这意味着每当他们从版本控制系统里取下最新文件时会让你的编译文件覆盖掉他们的。这是一个双重噩梦 （你绝不能这样做），在他们下一次编译时就会出问题。而且只要他们重新编译后再把编译文件重新上传上去，同样的问题会以相反的方向再发生一次，不过这次你 是受害者。你肯定不想这样的。
当然另一个问题就是这样做很浪费。这会浪费源代码管理服务器的硬盘空间，会浪费带宽并会通过网络发送时一直潜伏着，而且这样做造成的不可避免的冲突会极度浪费你的时间。
所以我们继续使用之前提到的“忽略”方案。只要把像&bin&和&obj&这样的路径直接忽略掉，一切就真的很轻松了。只要按照这种方法做一次，所有人都会感到开心的。
其实我在写时就说到了在版本控制的服务器上不能提交此类文件。当然如果有值得这么做的原因的话，只有这种情况下你可以上传。不过我倾向于不要这么做以免将来会导致某个人在更新时发生冲突。
第九诫.不要上传你自己的用户设置
老实说，我认为很多人没有注意到他们把自己的私人设置文件上传到源代码管理软件里了。这样会出现的问题是：许多工具会产生只管理你自己本地配置的文 件。它们只对你有用而且通常和其他人的私人设置文件相异。如果你把它们上传到源代码管理软件里，很快你就会覆盖掉其他人的私人设置文件。这样并不好。
这是一个典型的.NET程序的例子：
假如你没有立刻清理的话，多余出来的就是扩展文件和类型描述，也就是.ReSharper.user文件和.suo（Solution User Option， 解决方案用户选项）两个文件，它们只属于你，对其他人无效。
为了理解这点，我们来看看ReSharper文件：
name=&SolutionAnalysisEnabled&True
id=&FF99-43AB-93F5-CA7/f:Web.config& caret=&1121& fromTop=&26&
id=&FF99-43AB-93F5-CA7/f:Site.Master.cs& caret=&0& fromTop=&0&
在这个例子里，仅仅是在用户文件里记录了我启动了解决方案分析功能。这只是针对我，我喜欢这个功能，其他人则不一定。通常因为他们用的是老化的便宜的机子，我有点跑题了。关键是我的设置会强制让其他人也执行。我这么做不代表其他人也要这么做。
旁注：VSS不完美的地方主要在于。可以看看这篇帖子。
这个原理同样也适用于.suo文件。不过这里看不到里面的内容（它不是XML格式，而是二进制），这个文件记录了解决方案浏览器的状态，发布设置和其他一些你不让强制用在其他人电脑的东西。
所以我们要再次使用忽略方案来处理。前提你现在用的不是VSS。
第十诫.附属文件也要集成在一起
这是十诫中的最后一条也是最最重要的一条。当应用程序需要外部的附属文件存在才可以正常运行的话，把那些文件也都放进源代码管理软件里！人们倾向于犯的错误是，在他们拥有自己设置文件和本地附属文件的环境里一切都表现得很好就把东西都上传了，之后觉得没问题了就不管了。但是其他人不能从源代码库里找到同样的附属文件的话，所有东西都会悲剧性地报错。
我想到这点是因为今天从源代码库里拖出某个旧项目并运行它时出现了这样的画面：
我以为NUnit一直在机器上，但这次没有。幸运的是使用可以快速解决问题，但是没有附属文件的话，不是每次都可以用同样的方式就能轻松解决的。有些情况下，它们并不是公开的，你很难全部都获取到。
我从源代码管理软件里取出的项目运行时之所以会报错是因为我发现&C:\Program Files...&路径下丢失了附属的文件。我花了不少时间用来联系最后更改过它的那个人（很明显他在世界上另一个很远的地方），获取了那个文件，把它放 进&Libraries&文件夹下并把它上传到了版本控制系统里，这样下一个提取文件的人就不需要再这么麻烦了。
当然另一个重要的原因是，如果你在任何一种集成环境里工作时，你的构建服务器不一定安装了那些库。你必须有那些文件才能运行。Doug Rathbone最近写了一篇很好的关于这点的文章(源代码管理软件里的第三方工具)。并不是非要那样做（我们也善意地评价了效果），不过它确实是一个很方便的建议。
因此推荐每个人第一天就把程序运行所需要的东西全都放进版本控制系统里。
没有哪一条是很难理解的。老实说，它们都很基础：尽快并频繁地提交，确认你提交的东西改了什么，还有东西一定要放进版本控制系统里，解释清楚你的提交信息和确保是你自己提交的，不要忘记数据库和不要忘记附属文件。还有就是不要使用VSS:)
原文来自：中文翻译：
想通过手机客户端（支持 Android、iPhone 和 Windows Phone）访问开源中国：
旧一篇： 3年前
新一篇： 3年前
你也许会喜欢
2楼：田培军
我全部满足
3楼：妖魔舞
N个人分别使用互相独立的数台PC,却共同开发同一个系统,求如何使用源代码管理
6楼：edielei
此文仅作参考，不能按文章要求全照做。很明显作者对SVN使用依然不是很熟！
20:45 (非会员)
8楼：AFASF
21:24 (非会员)
我自己建了个SVN，我就喜欢把我个人的配置文件放到SVN里面，这样我换台电脑就不用重新搭建开发环境了，给别人用时我就要求他们建立开发目录时按我的目录设置来建立，这样只要CHECK OUT一下，完全一样的开发环境就建立好了，要知道配置一次开发环境也是很恼火的。
9楼：dbkmeteor
这些是最基本的守则吧。。。
10楼：F.L.F
从不写提交信息。。。。。。囧
11楼：烟头
引用来自“田培军”的评论我全部满足数据库管理用什么？？？？ 没有特别好的吧
12楼：ExtremeTalk
微软体系的程序员就是喜欢用VSS
13楼：ExtremeTalk
微软体系的程序员就是喜欢用VSS
14楼：tangguo168
就是有点懒得写提交信息
15楼：田培军
引用来自“烟头”的评论引用来自“田培军”的评论我全部满足数据库管理用什么？？？？ 没有特别好的吧sell脚本。嘿嘿
16楼：heiing
总结得太好了，数据库SQL源码管理这一点我们没做到
17楼：烟头
引用来自“田培军”的评论引用来自“烟头”的评论引用来自“田培军”的评论我全部满足数据库管理用什么？？？？ 没有特别好的吧sell脚本。嘿嘿那很麻烦啊
得手工维护吧
能坚持下去么？ 我们开始差不多也是 10个人左右的时候 基本上就很难控制了
18楼：www.specialsjordans.
16:07 (非会员)
Hey, thanks for the blog article.Really thank you! Fantastic.
19楼：cheap jordans
12:00 (非会员)
/forum/viewthread.php?tid=5679725&pid=6095371&page=1&extra=page%3D1#pid6095371cheap jordans
与内容无关的评论将被删除，严重者禁用帐号
本周热点资讯
本站最新资讯使用 Eclipse自动清理代码 - 加俊 - ITeye技术网站
博客分类：
干净、易于阅读的代码可以使不熟悉程序的开发人员快速完整地理解程序，从而使软件维护比其他方法更加有效。
编写干净代码有助于其他开发人员阅读、理解和维护您编写的代码。但是，并不是所有人都赞成 “漂亮”、“精密” 或 “干净”
等定义。不同的开发人员拥有不同的风格和审美鉴赏力。到现在为止，Eclipse
通过少量修饰以一种简单的功能方式设定了导入代码的格式。Eclipse V3.3
中对这些操作进行了扩展，从而提供了更宽泛的清理功能级别。Eclipse V3.3
允许您清除代码、添加缺少的代码并应用某种编码样式。向导将帮助您配置清理设置并将其存储起来以供稍后使用。
下面将讨论清理的基本概念并提供有助于保持代码干净的工具的概览。
用配置文件管理清理配置
某个具体的清理配置被称为一个
配置文件。配置文件可以保存，这样您就可以将设置提供给其他人或把来自早期项目和其他人的设置应用到当前代码中。根据组织的编码约定，配置文件可以应用于
所有的 Eclipse 项目，这样便可以在所有开发团队中获得相同的代码样式。
首选项为配置文件提供了管理功能。配置文件可被创建、编辑和删除。您可以指定在工作区中全局使用的配置文件。当您第一次打开工作区首选项并浏览到
Java & Code Style & Clean Up 时，您将看到活动配置文件 Eclipse
[built-in]。此内置配置文件已经过预先配置并且是随 Eclipse 一起交付的。内置配置文件有两个：Eclipse 和 Save
Participant。这两个配置文件定义了两个最小限度的清理配置，可基本上删除不必要代码。您可以通过将它们设为活动配置文件来查看这些内置配置文
件的设置。所有详细信息如详细信息区域所示。
图 1. 内置的详细信息
现有配置文件可作为各类模板使用，并且可以扩展和定制这些模板。因此，从下拉式菜单中选择现有配置文件作为活动配置文件并单击 edit。内置配置文件不能更改。可以使用内置配置文件作为您自己的配置文件的基础或简单地将内置配置文件按原样应用到代码中。
要创建您自己的配置文件，请单击 New。为配置文件命名并从下拉式菜单中选择现有配置文件进行初始化。取消选中 Open the edit dialog now 并单击 OK
图 2. 新建配置文件
要共享配置文件，请使用导出功能。要打开配置文件，请单击 Edit，然后单击 Export。为配置文件命名，然后单击 OK，接下来就可以共享配置文件了。
图 3. 导出配置文件
要将 XML 文件中的外部配置应用到项目中，必须先将其导入。在主清理首选项中单击 Import，选择文件，然后单击 OK.
清理设置分为五个主要类别。每个类别都显示在相应选项卡中，选项卡由设置部分和预览部分构成。预览用于立即显示设置对代码的影响。尝试使用这些设置并观察预览中的代码发生怎样的变化，以了解每种更改将怎样影响您的代码。当您在主清理首选项中单击 Edit，或在创建新配置文件时选择 Open the edit dialog now，将弹出编辑所有这些设置的对话框。
下面将讨论可用的设置及其优缺点。由于许多设置可以风格各异，因此将不提供任何推荐。注意，如果不选择具体选项，您的代码将保持键入时的样子。
一、Code Style
第一个选项卡用于处理编码样式并定义应当如何显示块、表达式和变量声明。
1、Control statements
选择　Use blocks in if, while, for, and do statements　可定义使用大括号的位置。大括号有助于提高代码可读性。使用大括号时更易于看出哪些内容属于同一个单元。在添加属于 if 或 else 条件的另一条语句时，还可以帮助避免错误。另一方面，大括号太多会使代码变得臃肿并可能使代码难于处理。
选择 Convert for loops to enhanced 将使用 for 循环符号，这是由 Java(TM) V5.0 引入的，用于减少代码。注意，此转换不具有向后兼容性。
2、Expressions
选择 Use parentheses around conditions 可定义使用圆括号的位置。对于圆括号，请参阅以上关于大括号的讨论。
3、Variable declarations
选择 Use modifier 'final' where possible 可定义使用 final 关键字的位置。final 修饰符不但可用于声明不能更改的变量，而且还是强制永远设定私有字段的优秀选择。final 修饰符对于性能、健壮性和正确性至关重要。
二、Member Accesses
第二个选项卡允许您定义应当怎样访问类型成员。
1、Non static accesses
需要使用 this 限定词访问字段或方法时选中该选项。this 限定词帮助您快速查看哪些字段或方法是正在编写的当前类的成员。它可以帮助您区分使用同一名称的字段和局部变量。
2、Static accesses
使用复选框来定义限定设置。可以通过声明类限定静态成员访问以更好地识别定义该成员的类型。另一方面，长类名可能使简单的成员访问变得臃肿并且使成员访问看上去不具有可读性或跨度多行代码。
三、Unnecessary Code
第三个选项卡允许您为删除未使用的代码和多余代码指定设置。
1、Unused code
使用第一个复选框可以删除未使用的导入。如果不使用 Organize imports 或 Strg+Shift+o 组合键，则这样自动删除不使用的导入将帮助您使项目保持尽可能地小且没有任何未使用的库。
使用第二个复选框可以删除未使用的私有成员。私有成员只能在保存类中访问。如果不使用私有成员，则不需要它们。私有成员只会增加编译器的开销。重构代码后如果拥有大量未使用的遗留代码，则删除会十分高效。另一方面，这样做会十分危险。假定您在设计尚未使用但可能在将来使用的新方法的原型。此清理选项如果处于激活状态将删除这些方法，并且可能会错过重要的工作。
2、Unnecessary code
使用第一个复选框来删除多余代码。多余代码的存在会导致运行时的额外开销，这取决于您使用的编译器。
使用第二个复选框可以去掉多余的 $NON-NLS$ 标记。这些标记仅由 Eclipse 使用来识别不应当具体化的字符串。
四、Missing Code
第四个选项卡允许您添加缺少代码。
1、Annotations
定义要将哪些注释添加到代码中。因为当使用不赞成使用的方法或者覆盖已标记方法未能正确覆盖某一个超类中的方法时，Java V5.0 @Override 或 @Deprecated 注释将帮助编译器生成错误。注意，这些注释不具有向后兼容性。
2、Potential programming problems
如果需要添加序列版本 ID，则定义此设置。对于实现 Serializable 接口的类，建议这些类使用私有静态 final 变量定义一个序列版本 UID。此变量可以自动生成。它用于在反序列化过程中检查兼容性。
五、Code Organizing
第五个选项卡虽然位于最后但不可忽略其重要性，它用于帮助您组织代码。
1、Formatter
定义在代码清理内是否应当使用格式程序。查阅格式程序首选项：Preferences & Java & Code Style & Formatter。
2、Imports
定义是否应当使用 Organize Imports。查阅组织导入首选项：Preferences & Java & Code Style & Organize Imports。
3、Members
定义是否需要按字母序把成员分类。有时，将成员按字母序分类非常好可以更好地浏览代码。不过，也可能有人会反对这样做。假定您将组织您的代码，使彼此调用的方法靠近放置在一起以便于进行代码浏览。排序可能会重新组织这些方法，并且它们可能不是所需的顺序。概览视图提供了一项优秀的功能用于给视图中的成员排序，但是不能给代码中的成员排序。具体配置和给成员排序的方法可以在 Preferences & Java & Appearance & Members Sort Order 中找到。
如何应用配置文件
在创建了清理配置文件后，可以通过多种方法将其应用到代码中。最简单的方法是在 Java 编辑器中打开上下文菜单并选择 Source & Clean Up。
要预览清理结果，请在清理向导中单击 Next。这时向导将计算代码更改数目。根据选定的编译单元数目，完成此过程可能需要花费一段时间。在下一个页面中，将为您呈现将要应用的更改。
更BT的应用-保存代码时应用
清理操作不但可以手动执行，而且还可以在执行 Java 文件的保存操作期间执行。要启用此功能，请转到 Window & Preferences & Java & Editor & Save Actions 并选择附加操作。请按前述配置清理操作，然后就会在每次保存 Java 文件时都执行这些清理操作。请注意，执行那些操作有时会加大开销并且降低工作台的速度。同时，如果没有想到清理操作，您可能会在保存刚刚编写的代码后觉得很困惑为什么代码不太一样。
iammonster
浏览: 1041931 次
来自: 北京
不错的汇总，楼主有心
这里有篇文章讲解jconsole是，感觉还行，说的也到位： j ...
jconsole的使用其实并不复杂，主要是对jvm的一些概念要 ...
我有个问题啊，你是怎么处理255的呢，我跟断点明明看到有个25 ...
我也碰到这种情况，是某个节点因为重启把iptables又起来了 ...