Your snipes might have hurt if we made websites for a living — I honestly slapped the whole site together in about 3 days just to make the tool available.

We gave the site the smoke test on the most popular browsers *current* versions: IE 7, Firefox 1.5 and 2, and Safari 2 and Safari 3, oh and OmniWeb 5 since it’s so pretty. They looked acceptable. I have no idea why anyone would still use IE 6, and I don’t really care. I have queued up some tasks for making it look nice on IE 6 anyway — but it’s kind of low on my list of priorities. Once again, IE 7 has been out for over a year!

Now as to standards compliant HTML, here you have a complaint I appreciate. It’s almost redeeming.

I checked out the HTML validator on the w3c site, Crap4j.org. Incidentally, there’s a tool that needs a rewrite. Here’s what I found. First the garbage stuff, then the valid things

GARBAGE:
* The validator did not recognize the dtd which when I look at the source is < !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
. Looks ok to me.
* Lots of old-style br tags in blog entries. OK, simple enough, nothing any browser doesn’t handle.
* Some complaints about urls with parameter passing, confused as entities by the tool, i.e. the & in an url mistaken as an entity.
* No short tag endings on img tags, aka the old-style html img tags. Rendered correctly by all browsers.
* It says there is no attribute “onload” for the img tag. Yet, here is a link to the onload tag that works for the img tag: Here. Nice.
* Put quotes around border=0 in an img tag.

VALID:

Ooops!

And as to bleeding-edge tags. None. Hmm. If anything, some old-style html tags.

I also checked the CSS, using the w3c validator, some problems with units on padding and margins, but that’s it.

The only thing that is problematic is the transparent pngs –which we already knew. However, they are much nicer to work with than transparent gifs and did I mention IE 7 has been out for a year and supports them.

Have a nice day!

Bob

Or you could actually test. I suggest keep abreast of the latest browser statistics:

http://www.w3schools.com/browsers/browsers_stats.asp

…and testing accordingly.

The irony could not be stronger.

The ant version doesn’t require Eclipse. I had suggested an easy way to get the build.xml was to generate it in Eclipse, but it isn’t necessary at all.

The ant task can be better indeed, and that is a focus for the next release 1.1.6. It does take ANT_HOME as passed in by the environment, and additional libraries the same way. (You can also add additional libraries to the taskdef.)

As for forking, the agitar test runner task already requires forking to run tests, and then the complexity and crap calculation are pretty quick, but you are correct that the running of the whole computation is not currently forkable.

As for passing in jvm args, that is also something useful to do. I am wondering, if it might be better to actually have the crap4j task dependent on some other testrunner task that generates coverage, specified separately in the ant file, and possibly also a component for complexity to be pluggable as well. Then it would just focus on computing the crap score from the work of those two components. How does this sound to you?

Please feel free to file requests and bugs on the bug system at http://trac.crap4j.org/. I look forward to hearing more detail about how you want to use it.

Thanks for trying it,
Bob

We want to run this in an continuous build cycle and not all users will be using Eclipse or possibly even an IDE to do the analysis.

The ant implementation could be done better to allow you to pass in jvm arguments, allow forking, and pass in ant home and additional libraries.

However, this is a great concept and I am looking forward to the refined result.

Check more here
http://venkatreddy.in/2007/10/22/crap4j-for-java-code-quality/