| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As planned, it's time to develop rule set. We should let users
themselves to decide which rule to use, so it's necessary to make a
whole set. Besides, the set shall be configurable.
So, the rules set should has 2 levels: rules themselves, to be shown to
users, as well as map from our abstract rules to rule in specific tools
such as clang-tidy.
Then it comes: how to make abstract rule set and the map to target rule?
We can define abstract rules in string, and write the map in tool
settings. That't why I change tool config from xml to yaml.
In short, I want to achieve such an effect:
```yaml
NullPointer: "Dont use null pointer"
StructInit: "Struct Init"
```
and in tools config:
```yaml
clangTidy:
path: "/path/to/clang-tidy"
params: ""
rule_mapping:
NullPointer: "xxx"(spercific rule name in clang-tidy)
StructInit: "yyy"
....
```
Hoping it will work as the way I need.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old top menu is too hard to use(it's in chaos, and tools button is
dealed together with other buttons, which makes it hard to add other
tools).
In this commit, the top menu is reorganized, especially tool button.
It's also registered by settings.xml autometically now.
Besides, exec func of tool class is set protected but no longer public,
to make the only aviable in the same package but not outside, so that
tools could be exec only by ToolsRegister::executeTools, which will
check if the tools has been registered first.
|
| |
|
|
|
|
|
|
|
|
|
| |
The bug report result table should enable people to ensure one by one
menually, and there's 3 kinds of states: not sure, currect issure, or
wrong report. However, in the old report it's a yes/no question. So it's
changed, and the state for each row also works nolonger as intager but
enum, to make it more readable.
Besides, all codes of this project get formatted, to make it clean, and
no more change caused by format in later commits.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit, I made HUGE changes:
What about the main class?
===========
The Main class is devided into 2 parts, one is just to call main func,
while the other works as the ui frame of the whole program, to make
them clear.
In the old program, in the main function we `new Main`, and the main
code of ui is in the constuctor of Main. What a chaos! In fact, the
whole ui is not necessary to be in Main class. Let's make another room.
Decoupling!!!
===========
Decouple the execute part of each check tool into independent class.
As you see, there's a new package named `toolsconfig`, and an abstract
class `ToolsConfig` is the basic class of all other tool class. Path,
paramaters, textPanel, result are all in each class.
Also, to make it easier to use, there's a class named `ToolsRegistry`.
Its core is a "hash map : tool name --> tool class". As a result of
which, we need to call the constructor of each class, and they will
register themselves.
The best way to construct them, is to do while parsing the settings.xml.
In order to make lower change to MyContorlUtil::loadToolsRoad, I made a
trick here, using the tool name to find its class by reflection, then
new an object for it and calls the constructor.
Hope all changes works well. Best wishes.
|
| | |
|
| | |
|
| |
|
We-unite