Does anyone know the correct way to explicitly specify which rules Gendarme will use? Or which rules to exclude? I'm not having a lot of joy searching the Mono documentation for the answer.
What I'm trying to do is to specify the rules one by one in the Gendarme rules.xml file like this:
<rules include="AvoidAssemblyVersionMismatchRule" from="Gendarme.Rules.BadPractice.dll"/>
Doing this, I'm hoping we can then switch off the rules we don't care about. The problem is, after specifying all the rules in this way, I'm getting a different number of defects detected compared with when I use the default method Gendarme provides, which is of the form:
<rules include="*" from="Gendarme.Rules.BadPractice.dll"/>
<rules include="*" from="OTHER DLL NAMES"/>
Has anyone done this before? Or can anyone point me in the direction of some Gendarme rules usage documentation?
To answer my own question:
Specifying the rules explicitly as I outlined above is the correct way to customise the rules list, the reason I was getting a different number of results back was because the "default" rule set in Gendarme leaves out scanning for Code Smells, once I added this scan to the default list, the defect totals matched.
Related
I am just beginning to use clang-format, and what I would like to do it map it's rules to my coding standard and identify discrepancies.
The clang-format documentation does a great job describing rules which have options
However, after playing with it, I realized it does a bunch of stuff that is not optional, and I can't find documentation on it.
For instance, it will add spaces around binary operators, turning a = b+c; into a = b + c; There is no way to turn this off, so it is not listed on the ClangFormatStyleOptions page.
I'm fine with not being able to rules off, but I can't find anywhere that it says it is going to add spaces around binary operators. I don't know if applies to all binary operators or just some. Thinking beyond this one rule, I basically have no idea what it is going to do without running a ton of test cases and finding out.
I can't seem to find a list of ALL the rules it applies. I am sure I am missing it somewhere. Can someone point it out?
I found this question here in which OP asks for a way to profile an ANTLTR grammar.
However the answer is somewhat unsatisfying as it is limited to grammars without actions and - even more important - it is an automated profiling that will (as I see it) use the defaul constructor of the generated lexer/parser to construct it.
I need to profile a grammar, that does contain actions and that has to be constructed using a custom constructor. Therefore I'd need to be able to instantiate the lexer + parser myself and then profile it.
I was unable to find any information on this topic. I know there is a profiler for IntelliJ but it works quite similar to the one described in the linked question's answer (maybe it's even the same).
Does anyone know how I can profile my grammar with this special needs? I don't need any fancy GUI. I'd be satisified if I get the result printed to the console or something like that.
To wrap it up: I'm searching for either a tool or a hint on how to write some code that lets me profile my ANTLR grammar (with self-instantiated lexer/parser).
Btw my target language is Java so I guess the profiler has to be in Java as well.
A good start is setting Parser.setProfile() to true and examine what you get from Parser.getParseInfo() after a parse run. I haven't yet looked closer what's provided in detail by the profiling result, but it's on the todo list for my vscode extension for ANTLR4 to provide profiling info for grammars to help improving them.
A hint for getting from the decision info to a specific rule: there's a decision number, which is an index into ATN.decisionToState. The DecisionState instance you can get by this is an ATNState descendant, which allows to get a ATNState.ruleIndex from it. The rule index then can be used with your parser's ruleNames property to find the name of that rule. The value is also what is used for the rule's enum entry.
I use this extension for Atom, to design my API, written in RAML.
I think I have a problem here :(I masked title and baseUri, sorry) :
If I follow RAML 1.0 specs, I should put a "!include". Strangely, apiworkbench detects no mistake.
If I do that :
Why didn't this work?
Very good conversations. Indeed the specification should be more clear about that, but the reason why libraries follows a different approach than normal !include is that an include simply adds new nodes to an existing where ever you used the !include keyword. Since it really is a simple "add" operation, it does not cover up for any cyclic dependencies.
Libraries are very much different and the use of namespaces (uses) are very much different. The purpose of libraries is to create a common shareable group of assets/definitions of best practices that people also use to create their own libraries or other definitions on top. Cyclic dependencies are inevitable. For that, the RAML workgroup had to come up with a different mechanism than what you have with !include. Hence, for libraries you should always use:
uses
lib: mylib.raml
Hope that explains the rationality behind it, but please let me know if you have more questions.
No, for libraries you must NOT use the include keyword.
It seems the specification is not very clear about this or at least I could not find it clearly specified anywhere. Thus raising an issue about this would be a good idea.
But if you check the examples in the specification you will see that when using libraries (with the "uses" keyword) the "!include" is omitted.
When writing proofs I noticed that Agda's auto proof search frequently wouldn't find solutions that seem obvious to me. Unfortunately coming up with a small example, that illustrates the problem seems to be hard, so I try to describe the most common patterns instead.
I forgot to add -m to the hole to make Agda look at the module scope. Can I make that flag the default? What downsides would that have?
Often the current hole can be filled by a parameter of the function I am about to implement. Even when adding -m, Agda will not consider function parameters or symbols introduced in let or where clauses though. Is there something wrong with simply trying all of them?
When viewing a goal, symbols introduced in let or where clauses are not even displayed. Why?
What other habits can make using auto more effective?
Agda's auto proof search is hardwired into the compiler. That makes it fast,
but limits the amount of customization you can do. One alternative approach
would be to implement a similar proof search procedure using Agda's
reflection mechanism. With the recent beefed up version of reflection using
the TC monad,
you no longer need to implement your own unification procedure.
Carlos
Tome's been working on reimplementing these ideas (check out his code
https://github.com/carlostome/AutoInAgda ). He's been working on several
versions that try to use information from the context, print debugging info,
etc. Hope this helps!
Hi I'm out of setting up an TFS server and I want to set some check-in rules.
I for example want to be able to set rules about method lenght, complexity and so on, I found NDepend very convenient can I somehow use NDepend to run some rules on the files trying to check in.
I also want to be able to bypass the rules sometimes.
Are there any blogs or discussions around this, if it wont work with NDepend are there any other tools or ways I can use?
I would be very careful about this. I worked at a place once that had strict method length rules. If Calculate(a,b,c) ended up 1.5 times the limit length, the devs would just move the last third of the function into Calculate2() and call it from Calculate(). All the active locals would become parameters, of course - sometimes there would be a dozen of them. The resulting mess passed the automated tests for method length but were definitely not better or more maintainable than the long methods would have been.
Would it have been nice if the devs had spotted something refactorable in the middle of the method, pulled it out and given it a good name? Yes it would. But systems are all game-able, and the sorts of "dammit I just want to check in and go home" changes that are made to comply with method length rules (among others) make the code worse. A lot worse.
Also to bypass the rules there's a way on the checkin to say you are bypassing and why.