I have this horrible habit of typing the below and not catching it until well into testing:
int i = 1;
int j = 2;
i =+ j; //i equals 2, not 3 as intended; assign only, + is unary and works on the j
The correct version, of course, would be
int i = 1;
int j = 2;
i += j; //i equals 3, as intended with additive & assignment compound operator
I have made this mistake a zillion times. It would not surprise me of there is some code out there with a bug in it that escaped a test case. There has just got to be a way to prevent this systematically. Any ideas?
Regularly use tools like PMD and/or Checkstyle. Ideally as part of your build process/continuous integration.
You might have to define a custom rule for this, because I don't know if any of those tools recognizes this as a problem by default.
This will not only catch this problem, but also hint at a lot of other potential problems as well.
Depending on what IDE you use, if it does syntax highlighting, I would modify the highlighting so that it looks for the pattern =+ and makes it some awful-to-look-at color.
Use standard text utilities, such as
find . -name \*.java -exec grep -H "=+" {} \;
As balpha commented, an easy way to find this would be to grep for the "=+" in code. It is probably never intentional.
I think you have to be rigorous in your unit testing. At the moment you're worried about one particular issue, but good unit tests will capture most issues (ignoring threading/loading etc.).
You have to decompose your classes/methods such that you can test each chunk of functionality and ensure complete (or as near as you can) coverage.
Clover (commercial) or Emma (open source) will manage code coverage for you.
Related
I want to write a program which is able to search in source code files for specific patterns ... in other words: the input is a piece of code for example:
int fib (int i) {
int pred, result, temp;
pred = 1;
result = 0;
while (i > 0) {
temp = pred + result;
result = pred;
pred = temp;
i = i-1;
}
return(result);
}
The output are files that contain this piece of code or similar code.
In the Open Source World code is reused in other projects. Especially libraries are often copied into projects. To make bug fixing easier I need to be able to know in which projects specific libraries or code is used.
Therefore I want to try to use apache solr. I don't know if its a good idea (I am would be happy about everything that could help me)
My plan is to index my source code files ... therefore I need some tools? to tokenize source code files. Like give me all names of functions, variables etc. The output I can use to feed the solr index. But I am not sure maybe there are already tokenizer or dataimporthandler in apache solr that do the trick?
I am not sure if this can be done using solr, since different projects may use different naming conventions.
Have a look at the link below if it helps:
Tools for Code Seacrh
Apache Solr is probably not the best option here. You have more like tree/graph comparison problem than string comparison here. I'd recommend using specialized tools for that.
If you do want to do it by hand, you basically need a parser with tree traversal API or some other way to get the stream/tree of tokens. This would very much depend on the language you are parsing. Something like ANTLR might be one way to go if it has the grammar for your language.
Alternatively, you could extract the information from the compiled code, if it is structured enough. For Java, something like ASM may do the job.
But you would still have to figure out the representation. Answering - to yourself - the question of how do I know these two pieces of code are similar should be the right first step.
I recently started using the findbugs static analysis tool in a java build I was doing. The first report came back with loads of High Priority warnings. Being the obsessive type of person, I was ready to go knock them all out. However, I must be missing something. I get most of the warnings when comparing things. Such as the following code:
public void setSpacesPerLevel(int value)
{
if( value >= 0)
{
spacesPerLevel = value;
}
else
{
spacesPerLevel = 0;
}
}
produces a high priority warning at the if statement that reads.
File: Indenter.java, Line: 60, Type:
BIT_AND_ZZ, Priority: High, Category:
CORRECTNESS Check to see if ((...) &
0) == 0 in
sample.Indenter.setSpacesPerLevel(int)
I am comparing an int to an int, seems like a common thing. I get quite a few of that type of error with similar simple comparisons.
I have alot of other high priority warnings on what appears to be simple code blocks. Am I missing something here? I realize that static analysis can produce false positives, but the errors I am seeing seem too trivial of a case to be a false positive.
This one has me scratching my head as well.
for(int spaces = 0;spaces < spacesPerLevel;spaces++)
{
result = result.concat(" ");
}
Which gives the following findbugs warning:
File: Indenter.java, Line: 160, Type: IL_INFINITE_LOOP, Priority: High, Category: CORRECTNESS
There is an apparent infinite loop in sample.Indenter.indent()
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
Any ideas?
So basically I have a handful of files and 50-60 high priority warnings similar to the ones above. I am using findbugs 1.3.9 and calling it from the findbugs ant task
UPDATE:
I have this build being executed by a hudson server and had the code being instrumented by Clover for code coverage. When I turned that off, all of my high priority warnings disappeared. That makes sense now. Thanks for the feedback.
UPDATE: I have this build being executed by a hudson server and had the code being instrumented by Clover for code coverage. When I turned that off, all of my high priority warnings disappeared. That makes sense now. Thanks for the feedback.
A side note:
for(int spaces = 0;spaces < spacesPerLevel;spaces++)
{
result = result.concat(" ");
}
If result is a java.lang.String, this may be inefficient, as you do the following steps for each space character:
create a new char[] to hold the result of the concatenation
create a new java.lang.String instance that is wrapped around the character array
If you do this repeatedly, especially when result is already long, this takes a lot of time.
If performance (both time and memory) is important for that method, you should consider using a StringBuilder (not thread-safe) or a StringBuffer (thread-safe).
Are you running Findbugs thru Eclipse plugin, ant or gui? is it possible that the code hasn't recompiled since you ran it (before making changes)?
if setSpacesPerLevel isn't too long, post the output of
javap -v TheClassThatContainssetSpacerPerLevel
As for the second bug, you'd have to show the whole loop before one could say if it was a problem.
I download the last Java build b96- Feature Complete for testing the new JDK features
but I can't figure out which syntax using for testing closures!
Can I test it?
Which syntax has been approved in the final release?
I can't be certain, but I think this syntax:
// function expressions
#(int i, String s) {
System.println.out(s);
return i + s.length();
}
// function expressions
#(int i, String s) (i + s.length())
// function types
#int(int, String)
Is going to make it through as per http://docs.google.com/Doc?id=ddhp95vd_0f7mcns
To answer your question, no final syntax has been approved and, despite M8 being listed as the feature-complete milestone, it doesn't have all the proposed features. You can read here about the feature in its current form, but much discussion is going on now and it has quite a ways to go. Additionally, the syntax is going to be revisited and likely changed (at least some) later, once more pressing issues are worked out.
Also, project-lambda code is being worked on in a fork of the main line JDK7 (I believe), so I don't think any of it would be in the build you downloaded.
I could actually see a use for the Google Annotations Gallery in real code:
Stumble across code that somehow works
beyond all reason? Life's short. Mark
it with #Magic and move on:
#Magic
public static int negate(int n) {
return new Byte((byte) 0xFF).hashCode()
/ (int) (short) '\uFFFF' * ~0
* Character.digit ('0', 0) * n
* (Integer.MAX_VALUE * 2 + 1)
/ (Byte.MIN_VALUE >> 7) * (~1 | 1);
}
This is a serious question. Could this be used in an actual code review?
Quite. Well, not all of them, but many could be substitutes for longer comments.
That holds true for not too many of these annotations, but some (as in your example) could be handy.
It may be said that these annotations present the most common comments in a shorter and perhaps more readable way.
You can later process them, and add tresholds for, say, the number of #Magic annotations. If a project becomes too "magic", measures should be taken.
It would be easier to use comments with a key such as "MAGIC", then work with those. Hudson and Eclipse and other tools can count or mark those occurrences.
I can definitely see how the #CarbonFootprint would fit into several client's CSR policies, and the #WTF("comment") annotation would be really handy when you're working on a new project where you're not sure whether a certain piece of code actually is needed to work around some crazy bug/corner-condition or if it's just random, left-over crap that no one knew how to write better at the time.
FYI, Sonar seems to now include a better revision plugin.
Anyway, were you not to guess, i think the short project name is clear enough about this project's intentions : gag the annotations for what they can become when left free : an equivalent to the oh-so-y2k XML hell.
I guess some people may have missed the acronym and the date of the that Google Annotation Gallery (GAG) on April 1st... or maybe in some countries it's not a national day for jokes, or gags...
I'm trying to use this formula in JAVA : (-ln(1-L))/L
I'm not sure how to use ln in java.
Math.log(d) returns the natural logarithm (base e) of a double value.
So the java code will be,
double result = (-Math.log(1-L))/L;
(but note that it's better to have variable names in lower-case - i.e. l instead of L)
I also had no idea, but since it's a common math function, I checked the Math class in the API.
Here you go: the log method
EDIT: Sorry for broken link, Markdown is fixed now. Also I realized right after I posted this answer that it sounds snarky, which was not my intent; re-wordings just make it seems snarky AND sarcastic, though. I just wanted to make the point that the API really is useful for methods that could be reasonably expected to come up a lot.