I was just wandering why is the prefix XXX ?
As far as I know its used for notes/reminders (or at least this is what I use it for and that is what the people on most of the links I googled use it for).
So does anyone know where the XXX prefix come from ?
From Sun/Oracle's Java code conventions, section 10.5.4:
Use XXX in a comment to flag something that is bogus but works. Use FIXME to flag something that is bogus and broken.
From the Hacker's Dictionary entry for "XXX":
A marker that attention is needed.
Commonly used in program comments to
indicate areas that are kluged up or
need to be. Some hackers liken `XXX'
to the notional heavy-porn movie
rating. Compare FIXME.
XXX, along with FIXME and TODO, is known in Eclipse as a task tag, and is indexed by the IDE to let you find the spots marked with those tags easily. You can edit such tags in the Eclipse Preferences -> Java -> Compiler -> Task Tags.
As to where it comes from: it probably emerged form the "tags" that programmers spontaneously wrote in their code to quickly mark a given line. While FIXME and TODO are explicit enough, the reason XXX was used could be a combination of these reasons:
The string "XXX" does not usually occur in regular source code and is easy to look for with tools such as grep or a simple text search in an editor;
Traditionally, "X marks the spot" which needs attention; triple X even more so;
The X key is very close to the Command/Alt/Windows keys and is easy to reach, being on the lower row of the keyboard.
I can't think of anything else...
Various reasons:
It's easy to search for.
No collision, as no sane person would use it as a variable.
It can used to mark code that needs e*X*tra special attention, dangerous code, not to be seen by underaged, etc.
I've worked with a team where XXX was used to point out a "bug or task that was not yet entered in Trac.". After it was entered in Trac the comment would be changed to TODO with the ID appended.
To Eclipse though, it's just a marker like TODO and FIXME. I imagine that it's originally used as a strong form of TODO. You usually see comments like this:
// TODO: Need to optimize this once n becomes greater than 1000.
But sometimes you'll have a comment like:
// TODO: Fix SQL injection bug before production release!
Unfortunately a quick grep wont make that SQL injection bug stand out among the 1000s of other TODOs. Using XXX here would help mark things that must be done before a milestone/release etc.
There's also a reference to it on Wikipedia:
XXX to warn other programmers of problematic or misguiding code.
It bugs me too, because XXX may also be used for masking input or format numbers,
Thus creating multi markers warning when you describe amount format:
/**
* #param amount (XXX or XXX.XX)
*/
public doSomething(String amount) {
Multiple markers at this line
-XXX or
-XXX.XX)
As #Jean-PhilippePellet suggested, you can remove it from
Preferences -> Java -> Compiler -> Task Tags
Related
I have a requirement, I want to put in-line/in-code comment to describe a line of code.
e.g Using single liner comment
private foo(List myNameList){
for(String name : myNameList){
//This prints each element of list
System.out.println(name);
}
}
But many GREEN comments all over the code don't looks pretty.
I am just looking for an annotation or a solution to replace each comment with annotation
e.g
private foo(List myNameList){
for(String name : myNameList){
#Comment(n)
System.out.println(name);
}
}
And just hovering over this #Comment should display my comment.
Note: In Comment(n) , n is an index of my messages/comments in some text file.
Don't use either.
If you think you need to write a comment explaining what a piece of code does, don't write a comment at all. Refactor the code. Extract out small, well-named methods that break the logic down into understandable pieces.
Inline comments in code should be rare, and provide information that cannot be gleaned by reading the code: for example, why something happens.
See: What is self-documenting code and can it replace well documented code?
Assuming you're an Eclipse user (hence green comments) I think what you actually should do is to change syntax coloring instead of developing an annotation.
In Preferences go to Java -> Editor -> Syntax Coloring, unfold Comments in the box on the right and choose whatever color you want (I suggest gray) for each type of the comments.
Additionally in Java -> Editor -> Folding make sure to have Comments selected.
Alternatively you could just remove all the comments. But it won't do unless you write self explanatory code. Start from the useless one. Refactor where they explain hard to comprehend code.
Hy,
Lets say you have Varchar-Database values in a column that are cAmeLCaSe and you always want to display them UPPERCASE in a view.
Is it now better to select those entrys using the (for example) UPPER-Function of Oracle
or to loop the results and call the .toUpperCase() Method from within the Java Code after the selection has been made?
I know its a bit of a general question and i will of corse comment after having made performance messurments of the above two possibilitys. But i am more after a good source of information that addresses such questions in general (like for example "is it better do run sorting db- side or in programm-code?" and questions like this for common Solutions like .Net/Java and Oracle/ MSSQL Server.
Many thanks you took the time to read this questions, i appreciate any input and wish you a great day.
Regards
Jan
It depends on where and how the uppercased value is used.
If this is only used in the frontend (I assume with "view" you did not mean a database view) then I'd go for a toUpperCase() ideally using the user's locale.
If you are using the uppercase value for comparison I'd use the Oracle function to ensure that the you have a consistent behaviour. I'm think of e.g. a condition where you compare the column value to a string constant: WHERE upper(foobar) = upper('SomeValue') If you used Java's toUpperCase() that might apply different (locale dependent) rules than Oracle would use.
I believe always my code should be database independent.
String upper = string.toUpperCase();
Because,it's database independent.If I shift my database to some other,I need not to change my code.
In a nutshell your specific requirements should take in to consideration.
Are there any Java API(s) which will provide plural form of English words (e.g. cacti for cactus)?
Check Evo Inflector which implements English pluralization algorithm based on Damian Conway paper "An Algorithmic Approach to English Pluralization".
The library is tested against data from Wiktionary and reports 100% success rate for 1000 most used English words and 70% success rate for all the words listed in Wiktionary.
If you want even more accuracy you can take Wiktionary dump and parse it to create the database of singular to plural mappings. Take into account that due to the open nature of Wiktionary some data there might by incorrect.
Example Usage:
English.plural("Facility", 1)); // == "Facility"
English.plural("Facility", 2)); // == "Facilities"
jibx-tools provides a convenient pluralizer/depluralizer.
Groovy test:
NameConverter nameTools = new DefaultNameConverter();
assert nameTools.depluralize("apples") == "apple"
nameTools.pluralize("apple") == "apples"
I know there is simple pluralize() function in Ruby on Rails, maybe you could get that through JRuby. The problem really isn't easy, I saw pages of rules on how to pluralize and it wasn't even complete. Some rules are not algorithmic - they depend on stem origin etc. which isn't easily obtained. So you have to decide how perfect you want to be.
considering java, have a look at modeshapes Inflector-Class as member of the package org.modeshape.common.text. Or google for "inflector" and "randall hauch".
Its hard to find this kind of API. rather you need to find out some websservice which can serve your purpose. Check this. I am not sure if this can help you..
(I tried to put word cacti and got cactus somewhere in the response).
If you can harness javascript, I created a lightweight (7.19 KB) javascript for this. Or you could port my script over to Java. Very easy to use:
pluralizer.run('goose') --> 'geese'
pluralizer.run('deer') --> 'deer'
pluralizer.run('can') --> 'cans'
https://github.com/rhroyston/pluralizer-js
BTW: It looks like cacti to cactus is a super special conversion (most ppl are going to say '1 cactus' anyway). Easy to add that if you want to. The source code is easy to read / update.
Wolfram|Alpha return a list of inflection forms for a given word.
See this as an example:
http://www.wolframalpha.com/input/?i=word+cactus+inflected+forms
And here is their API:
http://products.wolframalpha.com/api/
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 have a question which is described below:
What problems would arise for testing a Java class which counts number of words in a file?
The function's signature is below:
public int wordCount(String filename)
Well, this is a junit testing question.
If you know the problem, what is the solution of that?
So your question is what to test for? If yes, I'd say you should check if the definition of "word" is implemented correctly (e.g. is "stack-overflow" one word or two), are new lines handled correctly, are numbers counted as words (e.g. difference between "8" and "eight"), are (groups of special) characters (e.g. a hyphen) counted correctly.
Additionally, you should test whether the method returns the expected value (or exception) if the file does not exist.
This should be a good starting point.
To sfussenegger's list, I'd add the file handling checks: does the method respond correctly to files not found (including null filename), or lacking read permission?
Also, to sfussenegger's correctness list, I'd add whether duplicates count and case sensitivity rules, as well.
Of course, all of this requires that you know how the method is supposed to behave for all of these specifics. It's easy to tell someone to "go count words", but there are subtleties to that assignment.
Which is one of the big benefits of writing a good set of unit tests.
This really sounds like a task for FIT: Framework for Integrated Test. It's an acceptance testing framework that works with ant and JUnit.
One docent of mine did such a task and used this framework. It allows you to write a whole bunch of test cases within one html/wiki table. FIT will interpret each line as a parameter set for the function under test and checks the output.
For example:
This table displays the result of three test cases. Two passed, one failed.
You can use fit if you write sentences and define the number of words in your table. With FIT, they're executed and the result is displayed in a new table.
For further information, please read Introduction to FIT.