I'm trying to write a custom FxCop code analysis rule
that will warn developers from methods containing too deeply nested code blocks,
and will urge them to re-factor out the mess.
ex. I'm trying to avoid the following situation:
if(condition)
{
foreach(var item in items)
{
if(anotherCondition)
{
for(var product in item.Products)
{
// even more nested statement blocks...
}
}
}
}
I get a stackoverflow when I override the VisitBlock(Block block) method
that counts the block's depth, because apparently, there is a cyclic reference
from one of the properties of the block to
the block itself.
i.e. the following is true for some i: block.Statements[i] == block
Why does such a cyclic reference exist? How to avoid it?
Thanks!
after some more research, I've figured out I had actually TWO main problems
The VisitXXX methods are not visiting nodes in an abstract syntax tree of the source code
but actually visit nodes in the generated IL. Just compare the generated IL instructions per method
and the generated statements per method.Body.
I wonder what we could have achieved if FxCop
could provide us with a true AST visitor?
To answer my initial question, to prevent developers of writing too many nested
code blocks, we should just scan the method code by ourselves, I mean, take out the start line and the end line inside the SourceContext property of the method.Body and keep track of every
'{' and '}' we find. Increment counter for '{' and decrement counter for '}'. That should work, right?
Related
This question already has answers here:
Why is a ConcurrentModificationException thrown and how to debug it
(8 answers)
Closed 3 years ago.
I am programming a sorting system to school that must split some people into two cars, but I am stuck and I don't know how to continue.
When I delete the second when, it was working. But I need it there so I don't know what to do.
I already tried iterators but I am new in kotlin and it didn't work.
for (firstPeople in firstCar){
when {
k.contains(firstPeople.toString()) -> secondCar.add(j)
// println(secondCar)
k.contains(firstPeople.toString()) -> firstCar.add(j)
// println(firstCar)
else -> when {
firstCar.size > secondCar.size -> secondCar.add(j)
firstCar.size < secondCar.size -> firstCar.add(j)
else -> firstCar.add(j)
}
}
}
Error:
Exception in thread "main" java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at MainKt.main(Main.kt:65)
at MainKt.main(Main.kt)
Thank you so much for the answer.
Looks like you are using and ArrayList. And you are inserting an item in it while iterating via iterator: (firstCar.add(j). Here is what its JavaDoc says:
The iterators returned by this class's iterator and listIterator methods are fail-fast: if the list is structurally modified at any time after the iterator is created, in any way except through the iterator's own remove or add methods, the iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.
It means that you may modify the collection only using the iterator methods, and not directly.
Try to avoid list modification, or use iterator's add method, or use copy on write collections.
First of all, this question is related but not solved by
Advanced Java-like enums in Ruby
Static analysis of exhaustive switch statements of enums
Then about the question itself : when programming in Java with IDEs like Eclipse, it's possible to have a warning when we implement a switch statement on an enum, and we forgot some cases in the switch statement (very useful after adding an extra possible value to the enum and we forget to edit all switches based on this enum)
Is it possible to have the same kind of static analysis in Ruby ? Is there a way to implement enums so that we'd get a warning (maybe after running rubocop or something) if we forget to implement a case ?
EDIT
This "enum" I'm talking about could be any type of Set like object with a finite number of values, the most simplest form being an array of symbols, but maybe it is not enough/convenient to perform analysis with it hence why I am starting this question
On of my use case involve checking all possible errors after performing Policy checks
class CanShowArticlePolicy
def call
list_of_exceptions = [:unpublished, :deleted,
:offensive_content_detected]
# business logic that returns either true or false and add exception information exception, can be mocked as
#error = list_of_exceptions.sample
false
end
end
# in another file like a controller or service
article = Article.find(id)
policy = CanShowArticlePolicy.new(article)
if policy.call
render_article
else
# Where I'm trying to be exhaustive
case policy.error # <== Goal : detect here we are swithing on an "enum" with finite values and we should be exhaustive
when :unpublished
render_unpublished_error
when :deleted
render_gone
# <<= Here I would like to get a rubocop error because we've forgotten to handle the `:offensive_content_detected` case
end
Maybe a solution would be to have instead something like an annotation
case enum_value # #exhaustive-case with ::CanShowArticlePolicy::ErrorEnum
and the annotation would have for effect of the static analysis trying to find a ::CanShowArticlePolicy::ErrorEnum array containing the symbols, and making sure there are as many when statements as number of items in the frozen ErrorEnum
I recently asked how to test in RSpec if a block was called and the answers to that question seem to work in a simple case. The problem is when the initialization with the block is more complex. Then it is done in before and reused by a number of different tests in the context, among them the one testing if the block was evaluated. See the example:
context "the node definition using block of code" do
before do
#n=node do
# this block should be called
end
# some more complex setup concerning #n
end
it "should call the block" do
# how to test it?
end
# here a bunch of other tests using #n
end
In this case the solution with side effect changing value of a local variable does not work. Raising an exception from the block is useless since the whole statement must be properly evaluated to be used by the other tests.
Obviously I could do the tests separately, but it seems to stink, since I must copy-paste the initialization part and since the was-the-block-called test inherently belongs to this very context.
How to test if the block was evaluated in such a case?
Explanation for question asked by #zetetic below.
The context is that I'm implementing a kind of DSL, with nodes defined by their parameters and blocks of code (that can define something else in the scope of node). Since the things defined by the node's block can be pretty generic, at least for the first attempt I just need to be sure the block is evaluated and that what a user provides there will be considered. For now does not matter what it is.
Probably I should refactor my tests now and using mocks make them test behaviors rather then implementation. However it will be a little bit tricky, for the sake of some mixins and dynamic handling of messages sent to objects. For now the cincept of such tests is a little bit fuzzy in my head ;-)
Anyway your answers and comments helped me to better understand how RSpec works and explained why what I'm trying to do looks as if it did not fit to the RSpec.
Try something like this (untested by me):
context "the node definition using block of code" do
let(:node){
node = Node.new "arg1", "arg2", node_block
# more complex stuff here
node
}
context "checking the block is called" do
let(:node_block) {
double = double("node_block")
double.should_receive("some kind of arg").and_return("something")
# this will now cause a fail if it isn't called
double
}
it "should call the block" do
node.blah()
end
end
let(:node_block) {
# some real code
}
subject { node.blah() }
it { should == 2 }
# ...
end
So that's a very shaky piece of code (you'll have to fill in the gaps as you didn't give very much to go on, and let is obviously a lambda too, which could mean you've got to play around with it a bit) that uses let and a double to check it's called, and avoids using before, which is really for side effects not setting up variables for use in the specs.
#zetetic makes a very insightful comment that you're not testing behaviour here. I'm not against using rspec for doing more unit test style stuff (guidelines are made to be broken), but you might ask how later tests will pass when using a real block of code if that block isn't being called? In a way, I'm not even sure you need to check the block is called, but only you know.
I'm writing an algorithm that detects clones in source code. E.g. if there is a block like:
for(int i = o; i <5; i++){
doSomething(abc);
}
...and if this block is repeated somewhere else in the source code it will be detected as a clone. The method I am using at the moment is to create hashes for lines/blocks and compare them with hashes of other lines/blocks in the same source to see if there are any matches.
Now, if the same block as above was to be repeated somewhere with only the argument of doSomething different, it would not be detected as a clone even though it would appear very much like a clone to you and me. My algorithm detects exact matches but doesn't detect matching blocks where only the argument is different.
Could anyone suggest any ways of getting around this issue? Thanks!
Here's a super-simple way, which might go too far in erasing information (i.e., might produce too many false positives): replace every identifier that isn't a keyword with some fixed name. So you'd get
for (int DUMMY = DUMMY; DUMMY<5; DUMMY++) {
DUMMY(DUMMY);
}
(assuming you really meant o rather than 0 in the initialization part of the for-loop).
If you get a huge number of false positives with this, you could then post-process them by, for instance, looking to see what fraction of the DUMMYs actually correspond to the same identifier in both halves of the match, or at least to identifiers that are consistent between the two.
To do much better you'll probably need to parse the code to some extent. That would be a lot more work.
Well if you're going todo something else then you're going to have to parse to code at least a bit. For example you could detect methods and then ignore the method arguments in your hash. Anyway I think it's always true that you need your program to understand the code better than 'just text blocks', and that might get awefuly complicated.
The first thing I do in a public method is to validate every single parameter before they get any chance to get used, passed around or referenced, and then throw an exception if any of them violate the contract. I've found this to be a very good practice as it lets you catch the offender the moment the infraction is committed but then, quite often I write a very simple getter/indexer such as this:
private List<Item> m_items = ...;
public Item GetItemByIdx( int idx )
{
if( (idx < 0) || (idx >= m_items.Count) )
{
throw new ArgumentOutOfRangeException( "idx", "Invalid index" );
}
return m_items[ idx ];
}
In this case the index parameter directly relates to the indexes in the list, and I know for a fact (e.g. documentation) that the list itself will do exactly the same and will throw the same exception. Should I remove this verification or I better leave it alone?
I wanted to know what you guys think, as I'm now in the middle of refactoring a big project and I've found many cases like the above.
Thanks in advance.
It's not just a matter of taste, consider
if (!File.Exists(fileName)) throw new ArgumentException("...");
var s = File.OpenText(fileName);
This looks similar to your example but there are several reasons (concurrency, access rights) why the OpenText() method could still fail, even with a FileNotFound error. So the Exists-check is just giving a false feeling of security and control.
It is a mind-set thing, when you are writing the GetItemByIdx method it probably looks quite sensible. But if you look around in a random piece of code there are usually lots of assumptions you could check before proceeding. It's just not practical to check them all, over and over. We have to be selective.
So in a simple pass-along method like GetItemByIdx I would argue against redundant checks. But as soon as the function adds more functionality or if there is a very explicit specification that says something about idx that argument turns around.
As a rule of thumb an exception should be thrown when a well defined condition is broken and that condition is relevant at the current level. If the condition belongs to a lower level, then let that level handle it.
I would only do parameter verification where it would lead to some improvement in code behavior. Since you know, in this case, that the check will be performed by the List itself, then your own check is redundant and provides no extra value, so I wouldn't bother.
It's true that possibly you duplicated work that's already been done in the API, but it's there now. If your error handling framework works and is solid, and isn't causing performance issues (profiling IYF) then I reckon leave it, and gradually phase it out if you have time. It doesn't sound like a top priority!