Sonar翻译
第一章Fixing the Water Leak（漏水修复）... 4
第八章Security Audit and Reports（安全审计和报告）... 30
第九章Built-in Rule Tags（内置规则标签）... 33
第十四章Metric Definitions(指标定义)[if !vml]
[endif]......................... 44
[endif]......................... 49
第十六章Activity and History（项目的活动和历史）... 51
第十八章SonarLint Smart Notifications（SonarLint智能通知）... 54
User Guide（用户指南）
Yourfirst logged-in view of the SonarQube platform will be the Projects space,which defaults to showing your favorite projects.
SonarQube平台的第一个登录视图是Projects space，默认显示您最喜欢的项目。
Fromthere, you may want to head to the Project
Page of
your current project, where you'll see all the primary indicators of quality
gathered together. First, and most important, is the Quality
Gatestatus. Does the project pass or not? From there, you candecide what needs to be worked on.
从这里开始，您可能希望转到当前项目的项目页面，在那里您将看到质量的所有主要指标聚集在一起。首先，也是最重要的，是质量之门的地位。这个项目是否通过?从那里，你可以决定需要做什么。
Or youcould head to the Issues space, to see your personal leak, i.e. the Issuesyou'veintroduced recently.
What are
issues? They mark spots in the Code where
violations of Rules werefound.
或者你可以去“问题空间”，看看你的个人信息泄露，也就是你最近提出的问题。问题是什么?他们在发现违规行为的代码中进行了标注。
第一章Fixing the Water Leak（漏水修复）
What is the Water Leak(什么是漏水)
Imagineyou come home one day to find a puddle of water on the kitchen floor. As youwatch, the puddle slowly gets larger.
想象有一天你回到家，发现厨房地板上有一滩水。当你看着，水坑慢慢变大。
Do youreach for the mop? Or do you try to find the source and fix it? The choiceis obvious, right? You find the source of the leak!
你伸手去拿拖把吗?或者您是否试图找到漏水源并修复它?选择是显而易见的，对吧?你找到水泄漏的源头了!
So whydo anything different with code quality? When you analyze an application withSonarQube and realize that it has a lot of technical debt, the knee-jerkreaction is generally to start remediating – either that or put together aremediation plan. This is like mopping the floor once a day while ignoring thesource of the water.
那么为什么在代码质量上有任何不同呢?当你用SonarQube分析一个应用程序并意识到它有很多技术缺陷时，下意识的反应通常是开始补救——要么开始补救，要么制定一个补救计划。这就像每天拖地一次，却忽略了漏水源。
Typicallyin this traditional approach, just before release a periodic code quality auditresult in findings the developers should act on before releasing. This approachmight work in the short term, especially with strong management backing, but itconsistently fails in the mid to long run, because:
通常在这种传统的方法中，在发布一个周期性的代码质量审核结果之前，开发人员应该在发布之前采取行动。这种方法可能在短期内有效，特别是在强有力的管理层支持下，但在中长期内却总是失败，因为:
1.The code review comes too late in the process, and no stakeholderis keen to get the problems fixed; everyone wants the new version to ship.
代码审查在过程中来得太晚了，没有一个涉众热衷于解决问题;每个人都希望新版本上市。
2.Developers typically push back on the recommendations made byan external team that doesn't know the context of the project. And by the waythe code under review is obsolete already.
开发人员通常会对不知道项目上下文的外部团队提出的建议进行反驳。顺便说一下，正在审查的代码已经过时了。
3.There is a clear lack of ownership for code quality with thisapproach. Who owns quality? No one!
这种方法明显缺乏对代码质量的管控权。谁负责质量管理?没有人!
4.What gets reviewed is the entire application before it goes toproduction and it is obviously not possible to apply the same criteria to allapplications. A negotiation will happen for each project, which will drain allcredibility from the process
需要审查的是整个应用程序在投入生产之前，显然不可能对所有应用程序应用相同的标准。每一个项目都会进行谈判，这会耗尽整个过程的可信度
5.Instead,why not apply the same simple logic you use at home to the way you manage codequality? Fixing the leak means putting the focus on the “new” code, i.e.the code that was added or changed since the last release. Then things get mucheasier:
相反，为什么不应用您在家里使用的简单逻辑来管理代码质量呢?修复泄漏意味着将重点放在“新”代码上，即自上次发布以来添加或更改的代码。事情就变得简单多了:
The Quality
Gate canbe run every day, and passing it is achievable. There are nosurprises atrelease time.
质量部门可以每天运行，代码质量通过是可以实现的。这样在发布的时候就没有意外。
It's pretty difficult for developers to push back on problemsthey introduced the previous day. Instead, they're generally happy to fix theproblems while the code is still fresh.
对于开发人员来说，将前一天输入的问题推回去是相当困难的。相反，他们通常乐于在代码仍然新鲜的时候修复问题。
There is a clear ownership of code quality
代码质量有明确的所有权，责任权。
The criteria for go/no-go are consistent across applications,and are shared among teams. Indeed new code is new code, regardless of whichapplication it is done in
go/no-go的标准在应用程序之间是一致的，并且在团队之间是共享的。实际上，新代码就是新代码，不管它是在哪个应用程序中完成的。
The cost is insignificant because it is part of the developmentprocess
成本并不重要，因为它是开发过程的一部分。
As abonus, the code that gets changed the most has the highest maintainability, andthe code that doesn't get changed has the lowest, which makes a lot ofsense. Because of the nature of software, and the fact that we keep makingchanges to it, the debt will naturally be reduced. Where it isn’t is where itdoesn't need to be.
另外，更改最多的代码具有最高的可维护性，而未更改的代码具有最低的维护性，这很有意义。由于软件的性质，以及我们不断地对其进行修改，错误自然会减少。不存在的地方
就是不需要存在的地方。
How to do it(怎么做)
SonarQubeoffers two main tools to help you find your leaks:
SonarQube提供了两种主要工具来帮助您找到泄漏（漏洞）。
1.Leak Period metrics show the variance in your measuresbetween the current code and a specific point you choose in its history,typically the previous_version
泄漏周期度量显示当前代码和历史中选择的特定点(通常是前一个版本)之间度量的差异
2.New Code is primarily detected based on SCM "blame"data (starting from the first analysis within your Leak Period), with fallbackmechanisms when needed. See SCM
integration formore details.
新的代码主要是基于SCM“错误”数据(从泄漏期间的第一次分析开始)进行检测，在需要时使用回退机制。有关更多细节，请参阅SCM集成。
3.Quality
Gates allowyou to set boolean thresholds against which your code is measured. Use themwith differential metrics to ensure that your code quality moves in the rightdirection over time.
质量部门允许您设置布尔阈值，并根据此阈值对代码进行度量。将它们与不同的度量一起使用，以确保您的代码质量随时间向正确的方向移动。
第二章Quality gates（质量检验关）
Overview（概述）
Aquality gate is the best way to enforce a quality policy in your organization.It's there to answer ONE question : can I deliver my project to productiontoday or not?
质量检验关是在组织中实施质量方针的最好方法。它回答了一个问题:我今天是否可以将我的项目交付生产?
In orderto answer this question, you define a set of Boolean conditions based onmeasure thresholds against which projects are measured. For example:
为了回答这个问题，您定义了一组布尔条件，这些条件是基于测量阈值来测量项目的。例如:
1.No new blocker issues
没有新的拦截器问题
2.Code coverage on new code greater than 80%
新代码的代码覆盖率大于80%等
Ideally,all projects will be verified against the same quality gate, but that's notalways practical. For instance, you may find that:
理想情况下，所有项目都将通过相同的质量检验关进行验证，但这并不总是实用的。例如，你可能会发现:
1.Technological implementation differs from one application toanother (you might not require the same code coverage on new code for Web orJava applications).
技术实现在不同的应用程序之间是不同的(您可能不需要对Web或Java应用程序的新代码进行相同的代码覆盖)
2.You want to ensure stronger requirements on some of yourapplications (internal frameworks for example).
您希望确保对某些应用程序(例如内部框架)有更强的需求等
Which iswhy you can define as many quality gates as you wish. Quality Gates aredefined and managed in theQuality
Gatespage found in the top menu.
这就是为什么你可以定义任意数量的质量门。质量门是在顶部菜单中的质量门页面中定义和管理的。
Configuration（使用最好的质量把关配置）
The
quality gate "Sonar way" is provided by SonarSource, activated by
default and considered as built-in and so read-only. It represents our view of
the best way to implement the Fixing
the Water Leakconcept. At eachSonarQube release, we adjust automatically this default quality gate accordingto SonarQube's capabilities.
质量关卡“Sonar way”由SonarSource提供，默认激活，被认为是内置的，所以是只读的。它代表了我们对解决漏水问题的最佳方法的看法。在每个SonarQube版本中，我们会根据SonarQube的功能自动调整默认的质量关卡
Threemetrics allow you to enforce a given Rating of Reliability, Security andMaintainability, not just overall but also on new code. These metrics arerecommended and come as part of the default quality gate. We strongly adviseyou to adjust your own quality gates to use them to make feedback more clear toyour developers looking at their quality gate on their project page.
三个指标允许您执行一个给定的可靠性、安全性和可维护性的评级，虽然不是全面的，但仍然适用新代码。这些指标是推荐的，作为默认质量检验关的一部分。我们强烈建议您调整您自己的质量检验关，以便在使用它们时，使您的开发人员在项目页面上查看质量检验关时可以得到更清晰的反馈。
Don'tforget also that quality gate conditions must use differential values. There isno point for example to check an absolute value such as : Number of Lines ofCode is greater than 1000.
也不要忘记质量检验关的条件是必须使用不同的值。例如，没有必要检查绝对值，例如:代码行数大于1000。
推荐质量检验关
[if !vml]
[endif]
Thecurrent status is displayed prominently at the top of the Project
Page:
当前状态显示在项目页面顶部的显著位置
质量检验关状态
当前状态显示在项目页面顶部的显著位置
[if !vml]
[endif]
Getting Notified When a Quality
Gate Fails（当质量检验关失败时得到通知）
Thanks
to the notification
mechanism, users can be notified when a quality gatefails. To do so, subscribe to theNew
quality gate statusnotification either for all projectsor a set of projects you're interested in.
由于有了通知机制，用户可以在质量检验关失败时得到通知。为此，您可以订阅所有项目或感兴趣的一组项目的新的quality gate状态通知。
Security（安全）
QualityGates can be accessed by any user (even anonymous users). All users can viewevery aspect of a quality gate.
任何用户(甚至匿名用户)都可以访问质量检验关。所有用户都可以查看质量检验关的各个方面。
To make
changes (create, edit or delete) users must be granted the Administer
Quality Profiles and Gatespermission.
要进行更改(创建、编辑或删除)，用户必须获得管理质量概要和Gates权限
Aproject administratorcan choosewhich quality gates his/her project is associated with. SeeProject
Settings formore.
项目管理员可以选择与他/她的项目相关联的质量门。有关更多信息，请参见项目设置。
Defining Quality Gates（定义质量检验关）
Tomanage quality gates, go toQuality
Gates(top menu bar).
EachQuality Gate condition is a combination of :
要管理质量检验关，请访问质量检验关(顶部菜单栏)
每个质量门条件是:
1.measure测量
2.period: Value (to date) or Leak(differentialvalue over the Leak period) 期间:值(到目前为止)或泄漏(泄漏期间的差异值)
3.comparison operator 比较运算符
4.warning value (optional) 预警值(可选）
5.error value (optional) 错误值(可选)
For instance, a condition might be: 例如，一个条件可能是:
1.measure: Blocker issue措施:拦截器的问题
2.period: Value 区间:值
3.comparison operator: >比较运算符:>
4.error value: 0误差值:0
Which
can be stated as: No blocker issues. 可表述为:无拦截器问题
第三章Projects(项目)
TheProjects area allows you to explore projects by multiple metrics in both theoverall and leak persepectives. You can focus on just your favorite projects,explore all the projects in your SonarQube instance, or choose sub-sets ofprojects based on languages, project tags, and metric values such as:
项目区域允许您通过多个度量在整体和泄漏渗透中探索项目。您可以只关注您喜欢的项目，探索SonarQube实例中的所有项目，或者根据语言、项目标记和度量值，例如:
[if !supportLists]§ [endif]QualityGate status
[if !supportLists]§ [endif]NewBugs, Vulnerabilities, or Code Smells
[if !supportLists]§ [endif]OverallReliability, Security or Maintainability ratings
[if !supportLists]§ [endif]Newor Overall Coverage
[if !supportLists]§ [endif]Newor Overall Duplications
1.质量检验关状态
2.新的bug、漏洞或代码异味
3.总体可靠性、安全性或可维护性评级
4.新的或整体覆盖率
5.新的或整体复制
Once you
have your selection of projects, the project visualizations can help you gain
deeper insights into your project set, letting you see at a glance, for
instance, which projects are in trouble in terms of coverage or reliability.
When you find a particular project you want to focus on, you can drill into
the Project
Homepagefor more detail.
一旦您有了项目的选择，项目可视化可以帮助您对项目集有更深入的了解，让您一目了然，例如，哪些项目在覆盖率或可靠性方面有问题。当您找到想要关注的特定项目时，您可以深入到项目主页了解更多细节。
第四章Applications（应用程序）
What is an Application?（应用程序是什么）
AnApplication is an aggregation of projects into a synthetic project.
应用程序是将项目聚合为合成项目。
Application?（我们为什么要使用应用程序）
Assumeyou have a set of projects which has been split for technical reasons, butwhich shares a lifecycle; they interact directly in production and are alwaysreleased together. With an Application, they can be treated as a single entityin SonarQube with a unified Project Homepage, Issues list, Measures space, andmost importantly: Quality Gate.
假设您有一组项目，由于技术原因被拆分，但它们共享一个生命周期;它们在生产中直接交互，并且总是一起发布。有了应用程序，它们可以被视为SonarQube中的单个实体，具有统一的项目主页、问题列表、度量空间，最重要的是:质量把关。
Portfolio?（这与文件夹有何不同）
Applicationsand Portfolios are both aggregations of projects, but they have different goalsand therefore different presentations. A Portfolio is designed to be a veryhigh-level, executive overview that shows how a package of projects that mayonly be tangentially related are doing quality-wise, and what the trends are.Applications allow you to see your set of projects as a larger, overallmeta-project. For instance, because all the projects in an application shiptogether, if one of them isn't releasable then none of them are, and anApplication's consolidated Quality Gate gives you an immediate summary of whatmust be fixed across all projects in order to allow you to release the set.
应用程序和文件夹都是项目的集合，但是它们有不同的目标，因此呈现也不同。文件夹被设计成一个非常高级的、执行性的概述，它显示了一组可能只与质量相关的项目是如何进行质量管理的，以及趋势是什么。应用程序允许您将项目集看作一个更大的、整体的元项目。例如，因为应用程序中的所有项目一起发布，如果其中一个项目不能发布，那么没有一个项目是可发布的，应用程序的统一质量检验关为您提供了所有项目中必须修复的内容的直接摘要，以便您能够发布集合。
How do I set up an Application?（如何设置应用程序）
Applicationsare created and edited in the global Portfolio administration interface:Administration > Configuration >
Portfolios. For more, seeConfiguring
Portfolios and Applications. Applications must becreated initially by a user with global administration rights, but afterset-up, administration of an individual Application can be delegated to otherusers.
在全局组合管理界面中创建和编辑应用程序:管理>配置>组合。有关更多信息，请参见配置组合和应用程序。应用程序最初必须由具有全局管理权限的用户创建，但是在设置之后，单个应用程序的管理可以委托给其他用户。
Okay, I made an Application, but it doesn't
have any data in it. Now what?（我做了一个应用，里面没任何数据，现在怎么办）
An Application is automatically re-calculatedafter each analysis of one of its projects. If you want immediate(re)calculation, a user with administration rights on the Application can usetheRecomputebuttonin the Application-levelAdministration
Edit Definition interface. Theglobal Portfolio administration interface:Administration > Configuration > Portfolios offers the ability to queuerecomputation of all Applications and Portfolios at once.
在对一个应用程序的每个项目进行分析之后，应用程序将自动重新计算。如果希望立即(重新)计算，在应用程序上具有管理权限的用户可以在应用程序级（管理>编辑）定义接口中使用Recompute按钮。全局投资组合管理接口:管理>配置>文件夹，能够同时对所有应用程序和文件夹的重新计算进行排队。
I use branch analysis with my projects. Can I
do that in Applications too?
Branches areavailable for applications. They allow you to aggregate long-lived branchesfrom the projects in an application.
我在项目中使用分支分析。我能在应用程序中做到吗?
应用程序可以使用长寿命的分支。它们允许您从应用程序中的项目中聚合长期存在的分支。
How do I get an Application branch?
Once anApplication has been set up, anyone with administration rights on theApplication can manually create a new branch in theAdministration > Edit Definition interface. Branches can also bemanaged from the global Administration > Configuration > Portfoliosinterface. Foreach Application branch you can choose which project branch should be included,or whether the project should be represented in the branch at all.
如何获得应用程序分支?
一旦建立了应用程序，任何对应用程序具有管理权限的人都可以在管理>编辑定义接口中手动创建新的分支。分支也可以从全局管理>配置>文件夹接口进行管理。对于每个应用程序分支，您可以选择应该包含哪个项目分支，或者项目是否应该在分支中表示。
第五章Portfolios（文件夹）
The PortfolioHome Page is the central place for managers and tech leads to keep an eye onthe Releasability of the projects under their supervision. Releasability isbased on the project's quality gate: green or orange (pass or warning) isreleasable. Red (error) is not. Each Portfolio home page offers anaggregate view of the releasability of all the projects in the Portfolio.
At the
top of the page, you can easily see whether overall Portfolio is currently
rated as releasable and if any projects in the Portfolio have failed their
Quality Gate. And the Reliability, Security, and Maintainability ratings show
the overall health of the Portfolio in these three domains, along with an
indicator of the worst-performing project(s) in each domain.
For eachdomain you see:
[if !supportLists]· [endif]the rating (see Metric
Definitionsfor more details abouthow they are computed)
[if !supportLists]· [endif]an indicator of when the ratinglast changed
[if !supportLists]· [endif]an indicator of theworst-performing project(s) in the domain
文件夹的主页
文件夹主页是管理人员和技术负责人关注项目在他们监督下的可发布性的中心位置。可发布性基于项目的质量大门:绿色或橙色(通过或警告)是可发布的。红色(错误)是不可发布。每个文件夹主页提供了文件夹中所有项目可发布性的综合视图
在页面的顶部，您可以很容易地看到总体文件夹目前是否被评为可发布的，以及文件夹中的任何项目是否通过质量检验。可靠性、安全性和可维护性评级显示了这三个领域的文件夹的整体状况，以及每个领域中表现最差的项目的一个指标。
对于你看到的每个域：
1.评级(有关如何计算的详细信息，请参阅度量定义)
2.评价最近一次改变的指标
3.领域中表现最差的项目的指示器
TheReleasability Rating tells you the ratio of projects in the Portfolio thatdo NOT have aFAILEDQualityGate (ie QG beingPASSEDorWARNING) :
[if !supportLists]· [endif]A: > 80%
[if !supportLists]· [endif]B: > 60%
[if !supportLists]· [endif]C: > 40%
[if !supportLists]· [endif]D: > 20%
[if !supportLists]· [endif]E: <= 20%
可发布性评级
可发布性评级告诉你文件夹中通过质量检验关的项目的比例(即QG通过或警告):
A: > 80%
B: > 60%
C: > 40%
D: > 20%
E: <= 20%
Reliability, Security and Maintainability
Ratings
Each ofthe Reliability, Security and Maintainability Ratings for a Portfolio iscalculated as the average of the ratings for all projects included in thePortfolio. SonarQube converts the rating for each project to a number (seeconversion table below), calculates an average for the portfolio and convertsthat average back to a rating. Averages that land exactly on the 0.5 mark arerounded up (i.e. the result is the "lower" of the two possibleratings, so an average of 2.5 would result in a "C" rating).
Thisgives an “issue density" measure on the three axes of Reliability,Security and Maintainability for your Portfolio.
Ratingconversion table:
可靠性、安全性和可维护性评级
文件夹的每个可靠性、安全性和可维护性评级都被计算为包括在文件夹中的所有项目的评级的平均值。SonarQube将每个项目的评级转换为一个数字(参见下面的转换表)，计算组合的平均值并将该平均值转换回评级。正好落在0.5点的平均值会被四舍五入(也就是说，结果是两个可能的评级中的“较低”，所以平均2.5会得到一个“C”评级)。
这为您的文件夹提供了一个关于可靠性、安全性和可维护性三个轴的“问题密度”度量。
等级换算表:
[if !vml]
[endif]注意:文件夹主页也可以在子文件夹级别上使用
On aPortfolio Home Page you can choose to download an overview ofthe Portfolio as a PDF. To do that, simply click on the "Print asPDF" button. This is really convenient, for example, if you're going intoa meeting where you may not have access to your SonarQube instance.
If youdon't want to perform this action every time, you can subscribe to receive thePDF by email. The frequency of the mailing is decided by the administrator ofthe Portfolio.
Pleasenote you will receive the PDF only if the Portfolio is computed.
Portfoliosare created and edited in the global Portfolio administration interface:Administration > Configuration >
Portfolios. For more, seeConfiguring
Portfolios and Applications.
打印为PDF或订阅
在文件夹主页上，您可以选择以PDF的形式下载文件夹的概述。要做到这一点，只需点击“打印为PDF”按钮。这非常方便，例如，如果您要参加一个可能无法访问SonarQube实例的会议。如果您不想每次都执行此操作，您可以通过电子邮件订阅接收PDF。邮寄的频率由组合的管理员决定。请注意，您将收到PDF只有当文件夹是计算的。
文件夹在全局文件夹管理界面中创建和编辑:管理>配置>文件夹。有关更多信息，请参见配置组合和应用程序。
第六章Issue(问题)
Whilerunning an analysis, SonarQube raises an issue every time a piece of codebreaks a coding rule. The set of coding rules is defined through the quality
profile associatedwith the project.
Eachissue has one of five severities:
[if !supportLists]1. [endif]BLOCKER
Bug with a high probability to impact the behavior of the application inproduction: memory leak, unclosed JDBC connection, .... The code MUST beimmediately fixed.
[if !supportLists]2. [endif]CRITICAL
Either a bug with a low probability to impact the behavior of the applicationin production or an issue which represents a security flaw: empty catch block,SQL injection, ... The code MUST be immediately reviewed.
[if !supportLists]3. [endif]MAJOR
Quality flaw which can highly impact the developer productivity: uncoveredpiece of code, duplicated blocks, unused parameters, ...
[if !supportLists]4. [endif]MINOR
Quality flaw which can slightly impact the developer productivity: lines shouldnot be too long, "switch" statements should have at least 3cases, ...
[if !supportLists]5. [endif]INFO****Neither a bug nor a quality flaw, just a finding.
Ideally,the team wouldn't introduce any new issues (any new technical debt). SonarLint for Eclipse, SonarLint
for IntelliJ, and SonarLint for
VisualStudiocan help developersbecause they provide the ability to perform local analyses to check their codebefore pushing it back to the SCM. But in real life, it's not alwayspossible to code without any new technical debt, and sometimes it's not worthit.
So newissues get introduced.
在运行分析时，SonarQube每次违反编码规则时都会引发一个问题。编码规则集是通过与项目关联的质量概要定义的。
每个问题有五个严重性:
1.拦截器
错误概率高的影响应用程序的行为在生产:内存泄漏,未关的JDBC连接（数据库连接）,....代码必须立即修复。
2.至关重要的
要么是影响应用程序在生产环境中的行为的低概率错误，要么是代表安全缺陷的问题:空捕获块、SQL注入、……必须立即审查代码。
3.主要
可以高度影响开发人员生产力的质量缺陷:未发现的代码、重复的块、未使用的参数……
4.小
质量缺陷会轻微影响开发人员的工作效率:行不应该太长，“switch”语句至少有3种情况，……
5.信息
不是一个bug，也不是一个质量缺陷，只是一个发现。
理想情况下，团队不会引入任何新问题(任何新的技术缺陷)。用于Eclipse的SonarLint、用于IntelliJ的SonarLint和用于VisualStudio的SonarLint可以帮助开发人员，因为它们提供了在将代码推回SCM（软件配置管理）之前执行本地分析的能力。但在现实生活中，不需要任何新的技术负担就不可能编写代码，有时甚至不值得。
所以新问题被引入。
Sometimes,issues are self-evident once they're pointed out. For instance, if your teamhas agreed to a init-lower, camelCase variable naming convention, and an issueis raised on My_variable,you don't need a lot of context to understand the problem. But in othersituations context may be essential to understanding why an issue was raised.That's why SonarQube supports not just the primary issue location, where theissue message is shown, but also secondary issue locations. For instance,secondary issues locations are used to mark the pieces of code in a methodwhich add Cognitive Complexity to a method.
Butthere are times when a simple laundry list of contributing locations isn'tenough to understand an issue. For instance, when a null pointer can bedereferenced onsome paths through the code, what youreally need are issue flows. Each flow is a setof secondary locations ordered to show the exact path through the code on whicha problem can happen. And because there can be multiple paths through the codeon which, for instance a resource is not released, SonarQube supports multipleflows.
理解问题的上下文
有时候，问题一旦被指出，就不言自明了。例如，如果您的团队同意采用一种更低的camelCase变量命名约定，并且My_variable上出现了一个问题，那么您不需要太多的上下文来理解这个问题。但在其他情况下，上下文可能对理解为什么会提出问题至关重要。这就是为什么SonarQube不仅支持显示问题消息的主要问题位置，而且支持次要问题位置。例如，次要问题位置用于标记方法中的代码片段，从而增加了方法的认知复杂性。
但有时，一个简单的捐赠地点列表不足以理解一个问题。例如，当空指针可以在代码的某些路径上解除引用时，您真正需要的是问题流。每个流都是一组二级位置，这些位置是为了显示通过代码可能发生问题的确切路径。而且，由于代码中可以有多个路径，例如不释放资源，SonarQube支持多个流。
SonarQube'sissues workflow can help you manage your issues. There are seven differentthings you can do to an issue (other than fixing it in the code!): Comment,Assign, Confirm, Change Severity, Resolve, Won't Fix, and False Positive.
Theseactions break out into three different categories. First up is the"technical review" category.
问题编辑
SonarQube的问题工作流可以帮助您管理问题。对于一个问题，您可以做七件不同的事情(除了在代码中修复它!):注释、分配、确认、更改严重性、解决、不会修复以及假阳性。
这些行动分为三个不同的类别。首先是“技术评审”类。
Confirm, False Positive,Won't Fix, Change Severity, and Resolve fall into this category, which presumesan initial review of an issue to verify its validity. Assume it's time to reviewthe technical debt added in the last review period - whether that's a day, aweek, or an entire sprint. You go through each new issue and do one:
[if !supportLists]· [endif]Confirm - Byconfirming an issue, you're basically saying "Yep, that's a problem."Doing so moves it out of "Open" status to "Confirmed".
[if !supportLists]· [endif]False Positive -Looking at the issue in context, you realize that for whatever reason, thisissue isn't actually an issue,erm... "problem." It's not actually a problem. So you mark it FalsePositive and move on. Requires Administer Issues permission on the project.
[if !supportLists]· [endif]Won't Fix -Looking at the issue in context, you realize that while it's a valid issue it'snot one that actually needs fixing. In other words, it represents acceptedtechnical debt. So you mark it Won't Fix and move on. Requires AdministerIssues permission on the project.
[if !supportLists]· [endif]Change Severity - Thisis the middle ground between the first two options. Yes, it's a problem, butit's not as bad a problem as the rule's default severity makes it out to be. Orperhaps it's actually far worse. Either way, you adjust the severity of theissue to bring it in line with what you feel it deserves. RequiresAdminister Issues permission on the project.
[if !supportLists]· [endif]Resolve - If youthink you've fixed an open issue, you can Resolve it. If you're right, thenext analysis will move it to closed status. If you're wrong, its status willgo to re-opened.
Additionally,Security Hotspots allow the following:
[if !supportLists]· [endif]Detect-'Administer Security
Hotspots' permission required.Confirms a Security Hotspot asa true issue and manually opens a Vulnerability.
[if !supportLists]· [endif]Clear-'Administer Security
Hotspots' permission required. Marks a Security Hotspotor manually opened Vulnerability as being without issue and shouldn't befixed.
[if !supportLists]· [endif]Request Review-Request that a Security Auditor review changes made to remediate a manuallyopened Vulnerability.
[if !supportLists]· [endif]Reject-'Administer Security
Hotspots' permission required. After review ,reject theremediation for a manually opened Vulnerability and return it to an openissue.
If you
tend to mark a lot of issues false positive or won't fix, it means that some
coding rules are not appropriate for your context. So, you can either
completely deactivate them in the quality
profile or use issue exclusions to narrow
the focusof the rules so they are notused on specific parts (or types of object) of your application.Similarly, making a lot of severity changes should prompt you to considerupdating the rule severities in your profiles.
As youedit issues, the related metrics (e.g. New Bugs), will update automatically, aswill the Quality Gate status if it's relevant.
技术评审
确认，假阳性，不会修复，改变严重性，和解决属于这一类，它假设一个问题的初始审查，以验证其有效性。假设是时候回顾一下上次回顾期间增加的技术缺陷了——无论是一天、一周还是整个冲刺期。你浏览每一期，然后做一个:
确认——通过确认一个问题，你基本上可以说“是的，这是一个问题。”这样做将使它从“开放”状态变为“确认”状态。
假阳性——从上下文来看这个问题，你会意识到不管出于什么原因，这个问题实际上不是问题，呃……“问题”。这其实不是问题。所以你标记它为假阳性，然后继续。要求管理项目的许可。
不会修复——在上下文中查看这个问题，您会发现虽然它是一个有效的问题，但实际上并不需要修复。换句话说，它代表了可接受的技术缺陷。所以你标记它不会修复，然后继续。要求管理项目的许可。
更改严重性——这是前两个选项之间的中间地带。是的，这是一个问题，但问题并不像规则的默认严重性所显示的那样严重。或者更糟。无论哪种方式，你都要调整问题的严重性，使其符合你认为它应该得到的结果。要求管理项目的许可。
解决——如果你认为你已经解决了一个悬而未决的问题，你可以解决它。如果您是正确的，下一个分析将把它移动到关闭状态。如果您错了，它的状态将重新打开。
此外，安全热点允许以下情况:
检测——需要“管理安全热点”权限。确认一个安全热点是一个真正的问题，并手动打开一个漏洞。
清除——需要“管理安全热点”权限。将安全热点或手动打开的漏洞标记为没有问题，不应该修复。
请求审核——请求安全审核员审核修改以修复手动打开的漏洞。
拒绝——“管理安全热点”权限要求。审查后，拒绝对手动打开的漏洞进行修复，并将其返回到一个打开的问题。
如果您倾向于将许多问题标记为假阳性或无法修复，这意味着某些编码规则不适合您的上下文。因此，您可以在质量概要中完全禁用它们，或者使用问题排除来缩小规则的焦点，这样它们就不会用于应用程序的特定部分(或对象类型)。类似地，进行大量的严重程度更改应该会促使您考虑更新配置文件中的规则严重性。
当您编辑问题时，相关的度量标准(例如新的bug)将自动更新，如果与之相关，质量检验关状态也会自动更新。
Onceissues have been through technical review, it's time to decide who's going todeal them. By default they're assigned to the last committer on the issue line(at the time the issue is raised), but you can certainly reassign them toyourself or someone else. The assignee will receive email
notificationof the assignment if hesigned up for notifications, and the assignment will show up everywhere theissue is displayed, including in the My Issues list in the My Account space.
性格
一旦问题通过了技术审查，就该决定由谁来处理了。默认情况下，它们被分配给问题行上的最后一个提交者(在提出问题时)，但是您当然可以将它们重新分配给自己或其他人。如果受让人签署了通知，他将收到任务的电子邮件通知，任务将显示在任何显示问题的地方，包括在我帐户空间的My Issues列表中。
At anytime during the lifecycle
of an issue, you can log a comment on it.Comments are displayed in the issue detail in a running log. You have theability to edit or delete the comments you made.
常规
在问题生命周期的任何时候，您都可以对其进行日志记录。注释显示在运行日志中的问题细节中。你可以编辑或删除你的评论。
All ofthese changes and more can be made to multiple issues at once using the BulkChange option in the issues search results pane.
部分变化
所有这些更改和更多更改都可以使用issues搜索结果窗格中的Bulk Change选项一次性针对多个问题进行。
[if !supportLists]· [endif]Issues come from rules,
and rules are collected in profiles.Only certain users can edit profiles, but every user can view them.
其他
问题来自规则，规则在配置文件中收集。只有某些用户可以编辑配置文件，但每个用户都可以查看它们。
第七章Rules（规则）
In SonarQube, analyzers contribute ruleswhich are executed on source code to generate issues. There are four types ofrules:
[if !supportLists]· [endif]Code Smell (Maintainability domain)
[if !supportLists]· [endif]Bug (Reliability domain)
[if !supportLists]· [endif]Vulnerability (Security domain)
[if !supportLists]· [endif]Security Hotspot (Security domain)
For Code Smells and Bugs, zerofalse-positives are expected. At least this is the target so that developersdon't have to wonder if a fix is required.
For Vulnerabilities, the target is to have more than 80% of the issues to betrue-positives.
Security Hotspot rules are purposefully designed to draw attention to code issecurity-sensitive. It is expected that more than 80% of the issues will bequickly resolved as "Won't Fix" after review by a Security Auditor.
The Rules page is the entry point whereyou can discover all the existing rules or create new ones based on providedtemplates.
在SonarQube中，分析器贡献在源代码上执行的规则来生成问题。有四种规则:
1.代码异味(可维护性域)
2.BUG(可靠性域)
3.脆弱性(安全域)
4.安全热点(安全域)
对于代码的异味和bug，预计不会出现误报。至少这是目标，这样开发人员就不必担心是否需要修复。
对于漏洞来说，目标是有超过80%的问题是真实的。
安全热点规则的目的是为了引起人们对代码安全性敏感的注意。预计超过80%的问题将在安全审计人员审查后迅速解决，因为“无法修复”。
Rules页面是您可以发现所有现有规则或根据提供的模板创建新规则的入口点。
Bydefault, when entering the top menu item "Rules", you will see allthe available rules brought by the analyzers installed on your SonarQubeinstance. You have the ability to narrow the selection based on search criteriain the left pane:
[if !supportLists]· [endif]Language:the language to which a rule applies.
[if !supportLists]· [endif]Type:Bug, Vulnerability, Code Smell or Security Hotspot rules.
[if !supportLists]· [endif]Tag:it is possible to add tags to rules in order to classify them and to helpdiscover them more easily.
[if !supportLists]· [endif]Repository:the engine/analyzer that contributes rules to SonarQube.
[if !supportLists]· [endif]Default Severity:the original severity of the rule - as defined by the analyzer that contributesthis rule.
[if !supportLists]· [endif]Status:rules can have 3 different statuses:
[if !supportLists]· [endif]Beta:Therule has been recently implemented and we haven't gotten enough feedback fromusers yet, so there may be false positives or false negatives.
[if !supportLists]· [endif]Deprecated:Therule should no longer be used because a similar, but more powerful and accuraterule exists.
[if !supportLists]· [endif]Ready:Therule is ready to be used in production.
[if !supportLists]· [endif]Available Since:date when a rule was first added on the SonarQube instance. This is useful tolist all the new rules since the last upgrade of a plugin for instance.
[if !supportLists]· [endif]Template:display rule templates that allow to create custom rules (see later on thispage).
[if !supportLists]· [endif]Quality Profile: inclusionin or exclusion from a specific profile
If a
quality profile is selected, it is also possible to check for its active severity
and whether it is inherited or not. See the Quality
Profiledocumentation for more.
规则
默认情况下，当输入顶部菜单项“规则”时，您将看到安装在SonarQube实例上的分析程序带来的所有可用规则。您可以根据左边窗格中的搜索条件缩小选择范围:
1.语言:应用规则的语言。
2.类型:Bug、漏洞、代码嗅探或安全热点规则。
3.标记:可以向规则中添加标记，以便对它们进行分类并帮助更容易地发现它们。
4.存储库:为SonarQube提供规则的引擎/分析器。
5.默认严重程度:规则的原始严重程度——由贡献该规则的分析器定义。
6.状态:规则可以有3种不同的状态:
Beta:这个规则最近已经实施了，我们还没有从用户那里得到足够的反馈，所以可能会有假阳性或假阴性。
不赞成:不应该再使用该规则，因为存在一个类似但更强大且更准确的规则。
准备好:该规则已经准备好可以在生产中使用。
7.从:第一次在SonarQube实例上添加规则的日期开始。例如，列出自上次插件升级以来的所有新规则是很有用的。
8.模板:显示允许创建自定义规则的规则模板(请参阅本页面后面的内容)。
9.质量概要:包含在或排除在特定概要中。
如果选择了质量概要，还可以检查它的活动严重程度以及它是否被继承。有关更多信息，请参阅质量概要文档。
To seethe details of a rule, either click on it, or use the right arrow key. Alongwith basic rule data, you'll also be able to see which, if any, profiles it'sactive in and how many open issues have been raised with it.
The 2following actions are available only if you have the right permissions("Administer Quality Profiles and Gates"):
[if !supportLists]· [endif]Add/Remove Tags:
[if !supportLists]· [endif]It is possible to add existingtags on a rule, or to create new ones (just enter a new name while typing inthe text field).
[if !supportLists]· [endif]Note that some rules havebuilt-in tags that you cannot remove - they are provided by the plugins whichcontribute the rules.
[if !supportLists]· [endif]Extend Description:
[if !supportLists]· [endif]Extending rule descriptions is
useful to let users know how your organization is using a particular rule for
instance or to give more insight on a rule.
[if !supportLists]· [endif] Note that the extension
will be available to non-admin users as a normal part of the rule details.
规则的细节
要查看规则的详细信息，可以单击它，或者使用右箭头键。除了基本的规则数据之外，您还可以看到它在哪些(如果有的话)配置文件中是活动的，以及它引发了多少开放问题。
只有当您拥有正确的权限(“管理质量配置文件和门”)时，以下两个操作才可用:
1.添加/删除标签:
可以在规则上添加现有标记，也可以创建新标记(只需在文本字段中输入新名称即可)。
注意，有些规则有内置的标签，您无法删除——它们是由贡献规则的插件提供的。
2. 扩展描述:
扩展规则描述对于让用户知道您的组织如何使用特定的规则(例如)或对规则提供更多的了解非常有用。
请注意，该扩展将作为规则详细信息的正常部分提供给非管理员用户。
Rule Templates and Custom Rules
RuleTemplates are provided by plugins to allow users to define their own rules inSonarQube. For instance, the template "Architectural Constraint" canbe used to create any kind of rule that checks forbidden access from a set offile to another set of files.
Ruletemplates are like cookie cutters from which you can stamp out new,"custom rules". To find templates, use the template facet:
[if !vml]
[endif]
Tocreate a custom rule from a template, you will have to fill the followinginformation:
[if !supportLists]· [endif]Name
[if !supportLists]· [endif]Key (auto-suggested)
[if !supportLists]· [endif]Description (Markdown format issupported)
[if !supportLists]· [endif]Default Severity
[if !supportLists]· [endif]Status
[if !supportLists]· [endif]The parameters specified by thetemplate
It'seasy to navigate from a template to the custom rules defined from it: justclick on the link in the "Custom Rules" section and you will end upon the details of the given rule.
规则模板和自定义规则
规则模板由插件提供，允许用户在SonarQube中定义自己的规则。例如，可以使用模板“体系结构约束”来创建检查从一组文件到另一组文件的禁止访问的任何类型的规则。
规则模板类似于cookie切割器，您可以从中删除新的“自定义规则”。要找到模板，使用模板方面:
[if !vml]
[endif]
要从模板中创建自定义规则，您需要填写以下信息:
1.名字
2.键(输入框)
3.描述(支持标记格式)
4.默认的严重性
5.状态
6.模板指定的参数
很容易从模板导航到从模板定义的自定义规则:只需单击“自定义规则”部分中的链接，就会看到给定规则的详细信息。
[if !vml]
[endif]
自定义规则
自定义规则与其他规则一样，只是可以完全编辑甚至删除:
[if !vml]
[endif]
请注意，在删除自定义规则时，它不会从物理上从SonarQube实例中删除，而是将其状态设置为“remove”。这允许在SonarQube中正确显示与此规则相关的当前或旧问题，直到它们被完全删除。
扩展编码规则
可以添加自定义编码规则。有关详细信息和教程，请参阅添加编码规则。
第八章Security Audit and Reports（安全审计和报告）
Whateverthe maturity level of the SAST solution used to scan software, manyvulnerabilities can only be spotted through a manual code review process. Security auditors can use SonarQube to help guide their code review process byhighlighting sensitive pieces of code (Security
Hotspots) such as use of an encryption algorithm, execution of anOS command, access to the file system, and so on. Once these sensitive placesin the code are identified, it's up the Security Auditor to determine whetheror not a Vulnerability exists at each Security Hotspot. While security skillsare required to qualify a Security Hotspot as a true Vulnerability, allstakeholders can agree that identified Vulnerabilities can be exploited in asoftware execution context.
A Security
Auditor is the person in charge of making sure an applicationhas no security problems and giving recommendations on how to remediateidentified threats. This role can be part of the development team or a personoutside the team who is responsible for running security audits.
无论用于扫描软件的SAST解决方案的成熟度如何，许多漏洞都只能通过手工代码审查过程来发现。安全审核员可以使用SonarQube，通过突出显示敏感代码(安全热点)，如使用加密算法、执行OS命令、访问文件系统等，来帮助指导代码审查过程。一旦识别出代码中的这些敏感位置，就由安全审核员来确定每个安全热点是否存在漏洞。虽然需要安全技巧才能将安全热点限定为真正的漏洞，但所有涉众都同意可以在软件执行上下文中利用已识别的漏洞。
安全审核员负责确保应用程序没有安全问题，并就如何纠正已识别的威胁提出建议。这个角色可以是开发团队的一部分，也可以是团队之外负责运行安全审计的人员。
The
Security Reports are designed to quickly give you the big picture on your
application's security, with breakdowns of where you stand in each of the OWASP
Top 10 and SANS Top 25 categories,
along with CWE-specific
details. The Security Reports are fed by the analyzers, which rely on the rules
activated in your Quality Profiles to raise security issues. If there are no
rules corresponding to a given OWASP category activated in your Quality
Profile, you will get no issues for that specific category and the rating
displayed will be 'A'. An 'A' rating doesn't mean you are safe for that
category, only that you have no issues related to the activated rules.
You canuse the reports to:
[if !supportLists]· [endif]Communicateto stakeholders the current state of the project and show the area atrisks
[if !supportLists]· [endif]Run your security audit andmanage the backlog of issues you have to review and which quantity of them werediscarded because they have been already reviewed.
如何使用安全报告?
安全报告的设计目的是让您快速了解应用程序安全性的总体情况，包括OWASP Top 10和SANS Top 25类别中的各个类别，以及特定于cwef的详细信息。安全报告由分析程序提供，分析程序依赖于在您的质量配置文件中激活的规则来引发安全问题。如果在您的质量配置文件中没有与给定OWASP类别相对应的规则，那么您将不会遇到该特定类别的问题，并且显示的等级将是“A”。A的评级并不意味着你对这个类别是安全的，只是你没有与激活的规则相关的问题。
你可以使用报告:
1.与项目干系人沟通项目的当前状态，并显示风险区域
2.运行您的安全审计并管理您必须审查的问题的积压，以及因为已经审查过而丢弃了哪些数量的问题。
How to perform a Security Audit with SonarQube?
Prior torunning the analysis of your application, be sure that all the Vulnerabilityrules are active in the Quality Profile for each language associated with yourProject. Then, on top of the Vulnerabilities, determine which Security Hotspotrules you want to activate. Once you activate all of the security rules, youwill run your code scan, as usual, and analyzers will generate Vulnerabilitiesand Security Hotspots issues.
You'llhave the opportunity to review Vulnerabilities, but it is assumed that they arereal problems to fix. Your Security Auditor, along with the documentationprovided for each Vulnerability rule are resources available to help developersfind a solution and implement fixes.
For theSecurity Hotspots, it's up to the Security Auditor to go to the SecurityReports menu and start a review based on the OWASP Top 10 and SANS Top 25reports. Both reports follow the same process:
[if !supportLists]§ [endif]Clickon the figures on the Open column to get the full list of allissues for a particular category
[if !supportLists]§ [endif]Reviewissues one by one and decide whether or not there is a real Vulnerability; atthis stage you need security skills, you can't guess
[if !supportLists]§ [endif]Ifyou determine that an issue really is a Vulnerability, click on the Detectoption,otherwise click on the Clearoptionto remove it from the queue
See Issue
Lifecyclefor more detail on the statuses andactions possible on a Security Hotspot issue.
如何使用SonarQube执行安全审计?
在运行应用程序分析之前，请确保所有漏洞规则都活跃在与项目相关的每种语言的质量概要中。然后，在漏洞之上，确定要激活哪些安全热点规则。一旦激活了所有的安全规则，您将像往常一样运行代码扫描，分析程序将生成漏洞和安全热点问题。
您将有机会检查漏洞，但假定它们是需要修复的真正问题。您的安全审核员以及为每个漏洞规则提供的文档都是可用于帮助开发人员找到解决方案和实现修复的资源。
对于安全热点，应该由安全审核员根据OWASP Top 10和SANS Top 25 report来查看安全报告菜单。两份报告遵循相同的过程:
1.单击Open列上的数字以获得特定类别的所有问题的完整列表
2.逐个检查问题，判断是否存在真正的漏洞;在这个阶段你需要安全技能，你无法猜测
3.如果您确定某个问题确实是漏洞，请单击检测选项，否则单击Clear选项将其从队列中删除
有关安全热点问题的状态和可能的操作的更多细节，请参阅问题生命周期。
第九章Built-in Rule Tags（内置规则标签）
Tagsare a way to categorize rules and issues. Issues inherit the tags on the rulesthat raised them. Some tags are language-specific, but many more appear acrosslanguages. Users can add tags to rules and issues, but most rules have sometags out of the box. Here is a non-comprehensive list of what some of thosebuilt-in tags mean:
[if !supportLists]· [endif]brain-overload-there is too much to keep in your head at one time
[if !supportLists]· [endif]bad-practice-the code likely works as designed, but the way it was designed is widelyrecognized as being a bad idea.
[if !supportLists]· [endif]bug-something is wrong and it will probably affect production
[if !supportLists]· [endif]cert -
relates to a rule in a CERT standard.
There are currently three CERT standards: C, C++,
and Java.Many of these rules are not language-specific, but are good programmingpractices. That's why you'll see this tag on non-C/C++, Java rules.
[if !supportLists]· [endif]clumsy-extra steps are used to accomplish something that could be done more clearlyand concisely. (E.G. calling .toString() on a String).
[if !supportLists]· [endif]confusing-will take maintainers longer to understand than is really justified by what thecode actually does
[if !supportLists]· [endif]convention-coding convention - typically formatting, naming, whitespace...
[if !supportLists]· [endif]cwe -
relates to a rule in the Common Weakness Enumeration. For
more on CWE in SonarQube language plugins, and on security-related rules in general,
see Security-related
rules.
[if !supportLists]· [endif]design-there is something questionable about the design of the code
[if !supportLists]· [endif]lock-in-environment-specific features are used
[if !supportLists]· [endif]misra -
relates to a rule in one of the MISRAstandards. While theMISRA rules are primarily about C and C++, many of them are notlanguage-specific (E.G. don't use a float as a loop counter) but are simplygood programming practices. That's why you'll see these tags on non-C/C++rules.
[if !supportLists]· [endif]owasp-.* -
relates to a rule in the OWASP
Top Tensecurity standards. Note, that theOWASP Top Ten is a list of high-level vulnerabilities which translates to many,many potential rules.
[if !supportLists]· [endif]pitfall-nothing is wrong yet, but something could go wrong in the future; a trap hasbeen set for the next guy, & he'll probably fall into it and screw up thecode.
[if !supportLists]· [endif]sans-top25-.* -
relates to the SANS Top 25 Coding Errors,which are security-related. Note that the SANS Top 25 list is pulleddirectly from the CWE.
[if !supportLists]· [endif]security-relates to the security of an application.
[if !supportLists]· [endif]suspicious-it's not guaranteed that this is abug,but it looks suspiciously like one. At the very least, the code should bere-examined & likely refactored for clarity.
[if !supportLists]· [endif]unpredictable-the code may work fine under current conditions, but may fail erratically ifconditions change.
[if !supportLists]· [endif]unused-unused code, E.G. a private variable that is never used.
[if !supportLists]· [endif]user-experience-there's nothing technically wrong with your code, but it may make some or allof your users hate you.
标记是对规则和问题进行分类的一种方法。问题继承了引发它们的规则的标记。有些标记是特定于语言的，但是更多的标记出现在不同语言之间。用户可以向规则和问题添加标记，但大多数规则都有一些开箱即用的标记。下面是一些内置标签的非综合性列表:
1.大脑超负荷——一次有太多东西要记在脑子里
2.糟糕的实践——代码可能按照设计的方式工作，但是它的设计方式被广泛认为是一个坏主意。
3.bug ——出现错误，可能会影响生产
4.证书——与证书标准中的规则相关。目前有三个CERT标准:C、c++和Java。其中许多规则不是特定于语言的，而是很好的编程实践。这就是为什么你会在非C/ c++ Java规则上看到这个标签。
5.笨拙——额外的步骤是用来完成一些可以更清楚和简洁地完成的事情。(例如在字符串上调用. tostring())。
6.混淆——维护者需要更长的时间才能理解代码的实际功能
7.约定——编码约定——通常是格式化、命名、空格……
8.cwe ——与公共弱点列举中的一个规则有关。有关SonarQube语言插件中的CWE和安全相关规则的更多信息，请参阅安全相关规则。
9.设计——代码的设计有一些问题
10.锁定——使用了与环境相关的锁定特性
11.misra——与misra标准中的一个规则相关。虽然MISRA规则主要是关于C和c++的，但是它们中的许多并不是特定于语言的(例如，不要使用浮点数作为循环计数器)，而是很好的编程实践。这就是为什么你会在非C/ c++规则上看到这些标签。
12.owasp——涉及OWASP十大安全标准中的一个规则。注意，OWASP Top 10是一个高级漏洞列表，可以转换为许多潜在的规则。
13.陷阱-没有什么是错误的，但有些东西可能会在未来出错;为下一个家伙设置了一个陷阱，他很可能会掉进去，把代码搞砸。
14.sans-top25——与SANS的前25个编码错误有关，这些错误与安全性相关。请注意，SANS Top 25列表是直接从CWE中提取的。
15.安全性——与应用程序的安全性相关。
16.可疑的——不能保证这是一个bug，但是它看起来很可疑。至少，应该重新检查代码，并可能重构代码以使其清晰。
17.不可预测——代码在当前条件下可能运行良好，但是如果条件发生变化，可能会出现不正常的失败。
18.未使用过的——未使用的代码，例如从未使用过的私有变量。
19.用户体验-你的代码在技术上没有任何问题，但它可能会让你的一些或所有用户讨厌你。
第十章User Account（用户账户）
As a SonarQube user you have your own space
where you can see the things that are relevant to you:
作为SonarQube用户，你有自己的空间，可以看到与你相关的东西:
It givesyou a summary of:
[if !supportLists]§ [endif]yourGroups
[if !supportLists]§ [endif]yourSCM accounts
主页
它给你一个总结:
1.你的组（Group）
2.供应链管理账户
In
addition to being able to change your password, if your instance is not using a
3rd party authentication mechanism such as LDAP or any OAuth provider (GitHub,
Google Account, ...), you can manage your own authentication
tokens.
You can
create as many Token as you want. Once a Token is created, you can use it
to publish analysis to a project where you have the execute
analysispermission.
安全
除了能够更改密码之外，如果您的实例没有使用第三方身份验证机制，例如LDAP或任何OAuth提供者(GitHub、谷歌帐户…)，您还可以管理自己的身份验证令牌。
您可以创建任意数量的令牌。一旦创建了令牌，您就可以使用它将分析发布到具有execute analysis权限的项目中。
Thenotifications feature allows any logged in user to subscribe to the followingemail notifications:
[if !supportLists]· [endif]Changes in issues assignedto me or reported by me
[if !supportLists]· [endif]Issues resolved as false
positive or won't fix
[if !supportLists]· [endif]My New Issues
[if !supportLists]· [endif]New issues
[if !supportLists]· [endif]New quality
gate status
...globally or for specific projects.
Tosubscribe to notifications, tick the events you want to subscribe to.
See Notifications
- Administration toadminister this notification mechanism.
通知
通知功能允许任何登录用户订阅以下电子邮件通知:
1.由我负责或报告的问题的变化
2.问题解决为假阳性或不会修复
3.我的新问题
4.新问题
5.新的质量检验关状态
…全球或特定项目。
要订阅通知，请勾选要订阅的事件。
请参阅通知-管理来管理此通知机制。
From
this tab, you can see for all the Projects you have the Administerpermission,when these Projects have been analyzed for the last time and their currentQuality Gate status.
项目
从这个选项卡中，您可以看到您拥有管理权限的所有项目，当这些项目最后一次被分析以及它们当前的质量检验关状态时。
第十一章User Token（用户令牌）
Each user has the ability to generate tokens
that can be used to run analyses or invoke web services without access to the
user's actual credentials.
每个用户都能够生成令牌，这些令牌可用于运行分析或调用web服务，而无需访问用户的实际凭据。
Togenerate a token, to goUser
My Account > Security. Your existing tokens are listedhere, each with a Revoke button.
The format the bottom of the page allows you to generate new tokens. Once you click the generate button, you will see the token value.Copy it immediately; once you dismiss the notification you will not be able toretrieve it.
如何生成令牌
要生成令牌，请使用用户>
My Account > Security。这里列出了现有的令牌，每个令牌都有一个Revoke按钮。
页面底部的表单允许您生成新的令牌。单击generate按钮后，您将看到令牌值。立即将其复制;一旦您取消了通知，您将无法检索它。
How to Use a Token
User tokens have to be used as areplacement of your usual login:
[if !supportLists]· [endif]when running analyses on your code: replace your login by
the token in the sonar.login property.
[if !supportLists]· [endif]when invoking web services: just pass the token insteadof your login while doing the basic authentication.
In both cases, you don't need to provide
a password (so when running analyses on your code, the property sonar.password is optional).
如何使用令牌
必须使用用户令牌代替您通常的登录:
1.在对代码进行分析时:用sonar中的令牌替换您的登录。登录属性。
2.调用web服务时:只需在执行基本身份验证时传递令牌而不是登录。
在这两种情况下，都不需要提供密码(因此在对代码运行分析时，属性sonar)。密码是可选的)。
第十二章Code Viewer（代码查看器）
The codeviewer is the heart of SonarQube: it displays the source code of a file (bothsource and test files), and its high-level statistics:
[if !supportLists]· [endif]Lines
[if !supportLists]· [endif]Issues(generatedby the rules activated on the quality profile)
[if !supportLists]· [endif]Test coveragebyunit or integration tests
[if !supportLists]· [endif]Duplicationswithinthe same file or in other files
[if !supportLists]· [endif]SCM informationlikewho last committed a specific line and when
You willland on the code viewer:
[if !supportLists]· [endif]when drilling down from theMeasures and Code pages.
[if !supportLists]· [endif]when reviewing issues on
the Issues page.
[if !supportLists]· [endif]when searching for a particularfile using the search input at the top-right.
The codeviewer has two aspects, the current file and pinned files.
代码查看器是SonarQube的核心:它显示文件(源代码和测试文件)的源代码及其高级统计信息:
1.线条
2.问题(由质量概要上激活的规则生成)
3.按单元测试或集成测试进行测试
4.同一文件或其他文件中的重复
5.SCM信息，比如谁最近提交了一个特定的行，以及何时提交的
您将登陆代码查看器:
1.当从度量和代码页向下钻取时。
2.在问题页面上查看问题时。
3.当使用右上角的搜索输入搜索特定文件时。
代码查看器有两个方面，当前文件和固定文件。
当前文件
The codeviewer is composed of 2 parts:
[if !supportLists]· [endif]Theheaderliesacross the top of the file. It displays useful information such as # lines, #issues, coverage and duplication percentages.
[if !supportLists]· [endif]Thesource codeis inthe center, decorated with additional information such as SCM data, coverageand duplications bars.
Theheader can contain up to four data blocks, one per main axis: Lines, Issues, Coverage(forsource files) or Tests (for
test files), and Duplications.Data blocks which aren't relevant to the current file won't be shown. Forinstance, if the project has no tests, the coverage number will be omitted.Similarly, the duplications block will be omitted if there are no duplications.
The mainpurpose of the code viewer is to show source code and any problems it mayhave. For that reason, issue, duplication, and test decorations are alwaysvisible, but issues may be collapsed if you don't come to the code viewer fromthe Issues page, and a yellow highlight is present on all new code.
Thelight yellow background is meaning: new code during the leak period.
The dark yellow background is meaning: new code during the leak period notcovered by tests.
布局
代码查看器由两部分组成:
1.头在文件的顶部。它显示有用的信息，如#行、#问题、覆盖率和复制百分比。
2.源代码在中心，用诸如SCM数据、覆盖率和重复栏等附加信息装饰。
包头
包头最多可以包含四个数据块，每个主轴一个:行、问题、覆盖率(源文件)或测试(测试文件)和重复。不会显示与当前文件不相关的数据块。例如，如果项目没有测试，覆盖号将被省略。类似地，如果没有重复，那么重复块将被省略。
源代码
代码查看器的主要目的是显示源代码及其可能存在的任何问题。出于这个原因，问题、重复和测试装饰总是可见的，但是如果您没有从问题页面来到代码查看器，那么问题可能会崩溃，并且在所有新代码上都会出现一个黄色的高亮显示。
浅黄色背景的意思是:泄漏期间的新代码。暗黄色背景的意思是:在泄漏期间没有被测试覆盖的新代码。
额外的操作
代码查看器头部右上角的actions菜单提供了其他选项。
[if !vml]
[endif]
其中最值得注意的是“显示详细信息”，它会打开一个模式弹出窗口，其中包含文件上的其他数据:
[if !vml]
[endif]
固定的文件
源文件和规则描述都可以直接固定:
[if !vml]
[endif]
或从另一个文件的复制细节。
您可以调整当前活动固定窗口的高度，最小化它，最大化它，并关闭它。如果您更改上下文或锁定另一个文件，当前活动窗口将自动最小化
进一步的阅读
要了解更多有关代码查看器的信息，请参阅:
查看报道
查看测试
查看重复
第十三章UI Tips（界面提示）
搜索项目、视图、开发人员、文件
在顶部菜单的右上方，你有一个搜索引擎[if !vml]
[endif]，允许你快速访问你的项目，视图，开发人员，文件，…
单击图标或键入's'将焦点移到输入。当第一次打开时，这个对话框显示了最近浏览过的组件。开始键入搜索输入，列表将重新填充匹配的开发人员、项目、模块等。
[if !vml]
[endif]
使用快捷键
界面中有许多键盘快捷键。点击右上角的[if !vml]
[endif]或者直接输入“?”查看列表:
[if !vml]
[endif]
快速访问您最喜欢的
web界面提供了将组件标记为收藏夹的功能。
[if !vml]
[endif]
本地化
web界面以您在浏览器设置中设置的首选语言显示。
如果不是，请让管理员添加相应的语言包。看看可用的包。
第十四章Metric Definitions(指标定义)[if !vml]
[endif]
这不是一个详尽的指标列表。有关完整列表，请参阅SonarQube实例上的api/metrics WebAPI。
复杂性
[if !vml]
[endif]
重复
[if !vml]
[endif]
问题
[if !vml]
[endif]
严重程度
[if !vml]
[endif]
可维护性
[if !vml]
[endif]
质量检验关
[if !vml]
[endif]
可靠性
[if !vml]
[endif]
安全
[if !vml]
[endif]
大小
[if !vml]
[endif]
测试
[if !vml]
[endif]
[if !vml]
[endif]
对于集成测试和总体测试，不存在关于测试执行的度量
第十五章Concepts（概念）[if !vml]
[endif]
体系结构
[if !vml]
[endif]
质量
[if !vml]
[endif]
[if !vml]
[endif]
第十六章Activity and History（项目的活动和历史）
The
Project Activity page offers a comprehensive list of the analyses on file for a
project (subject to Housekeeping),and the ability to see the evolution of project measures over time.
Graphson the activity page help you understand the evolution of up to three measuresof your choice against each other. Graph mouseovers show the measure values andevents associated with particular analyses.
项目活动页面提供了一个项目文件分析的综合列表(根据内务管理)，以及查看项目度量随时间变化的能力。
活动页面上的图表可以帮助您了解您选择的三个度量之间的差异。图鼠标移出显示与特定分析相关的度量值和事件。
Thereare four types of events:
[if !supportLists]· [endif]Quality Gate - the status of
the quality
gatechanged.
[if !supportLists]· [endif]Profile - the quality profileused to analyze the project changed - either the profile was edited, or adifferent profile was used to analyze the project.
[if !supportLists]· [endif]Version - the project's versionchanged.
[if !supportLists]· [endif]Other - an event was manually
created on a snapshot. See Managing
History.
Events
are shown on the project
front pageand in the project Activitypage.
事件
有四种类型的事件:
1.质量门——质量门的状态改变。
2.概要文件——用于分析项目变更的质量概要文件——或者编辑概要文件，或者使用不同的 概要文件来分析项目。
3.版本——项目的版本改变了。
4.另一个—一个事件是在快照上手动创建的。看到管理的历史。
事件显示在项目首页和项目活动页面。
Visualizations are available to help you gain
deeper insights into your projects' current statuses and histories.
可视化可以帮助您更深入地了解项目的当前状态和历史。
How do I compare current state for multiple
projects or project components?
TheProjects space allows you to filter the projects in your instance by multiple,measure-based criteria. Once you've chosen your set, you don't have to stare atthe raw numbers to identify the risks its projects face. Instead, several visualizations(Projects >
Perspective) are available to help you understand eachproject's relative position in terms of each of the major axes:
[if !supportLists]· [endif]Risk - Reliability and Securityratings, test coverage, technical debt, and lines of code
[if !supportLists]· [endif]Reliability - Reliabilityrating, Reliability remediation effort, lines of code, and Bug count
[if !supportLists]· [endif]Security - Security rating,Security remediation effort, lines of code, and Vulnerability count
[if !supportLists]· [endif]Maintainability -Maintainability rating, Technical debt, lines of code, and Code Smell count
[if !supportLists]· [endif]Coverage - Coverage,complexity, and uncovered lines
[if !supportLists]· [endif]Duplications - Duplicated Lines%, lines of code, and duplicated blocks
At theproject level these same visualizations are available in theMeasurestab to help you compare project components. TheProject Overview corresponds to the Risk visualizationin the Projects space, For the other five graphs, choose the Overview option under the relevant domain.
Additionally,treemaps are also available for percentage and rating metrics at the projectlevel. Navigate to them in the Measures tab using the perspective selector inthe right pane.
如何比较多个项目或项目组件的当前状态?
项目空间允许您通过多个基于度量的标准筛选实例中的项目。一旦您选择了您的集合，您就不必盯着原始的数字来识别项目面临的风险。相反，一些可视化(project >透视图)可以帮助您了解每个项目在每个主要轴上的相对位置:
风险——可靠性和安全评级，测试覆盖率，技术债务和代码行
可靠性——可靠性评级，可靠性补救工作，代码行，和错误计数
安全性——安全性评估、安全性修复工作、代码行数和漏洞计数
可维护性——可维护性评级、技术债务、代码行数和代码气味计数
覆盖——覆盖、复杂性和未覆盖的线条
重复——重复行的百分比、代码行和重复的块
在项目级别，Measurestab中提供了这些相同的可视化效果，帮助您比较项目组件。项目概览对应于项目空间中的风险可视化，对于其他五个图，选择相关域中的概览选项。
此外，treemaps还可用于项目级别的百分比和评级度量。使用右侧窗格中的透视图选择器在Measures选项卡中导航到它们。
How do I visualize metric history?
At theproject level, the Activity tab offers several canned line graphsof selected metrics across time, with convenient mouseovers to show graphdetails and the ability to easily narrow the graph to a slice of the project'shistory. Beyond the canned graphs, you also have the ability to map the metricsof your choice against each other in a Custom graph.
如何将度量历史形象化?
在项目级别上，Activity选项卡提供了几个固定的线图，这些线图包含了各个时间点的选定指标，通过方便的鼠标移动来显示图的细节，并且能够轻松地将图缩小到项目历史的一部分。除了固定的图形之外，您还可以在定制的图形中相互映射您选择的度量。
[if !vml]
[endif]
第十八章SonarLint Smart Notifications（SonarLint智能通知）
SonarLint
Smart Notifications is available as part of theDeveloper
Edition.
Smartnotifications allow developers usingConnected
ModeinSonarLinttoreceive in-IDE notifications from SonarQube when:
[if !supportLists]· [endif]the Quality Gate status (failed/ success / warning) of a project /solutionopen in the IDEchanges
[if !supportLists]· [endif]a SonarQube analysis raises newissuesintroduced by
this developer in a project /solution open in the IDE
SonarLint智能通知是开发版的一部分
智能通知允许在SonarLint中使用连接模式的开发人员在以下情况下接收SonarQube的in- IDE通知:
在IDE中打开的项目/解决方案的质量检验关状态(失败/成功/警告)
SonarQube分析提出了该开发人员在IDE中开放的项目/解决方案中引入的新问题。
Activate/deactivate Notifications
Theactivation or deactivation of notifications must be done individually, by eachdeveloper directly in SonarLint (on the IDE side).
Receivingnotifications is configurable on the SonarLint side on a SonarQubeserver-by-server basis.
激活/停用通知
通知的激活或停用必须由每个开发人员在SonarLint(在IDE端)中单独完成。
接收通知在SonarLint端是可配置的，基于SonarQube服务器对服务器。
