Show HN: Code Climate for JavaScript

http://blog.codeclimate.com/blog/2013/10/24/code-climate-for-javascript/

by brynary • 13 years ago

63 31 13 years ago

blog.codeclimate.com

We use Code Climate for Ruby and were in on the alpha for JavaScript. It is an amazing product, the support is great, and I can't recommend it enough!!

qwertyboy• 13 years ago

Well, before I open an account, can you please explain how this is better than using jslint?

brynary9• 13 years ago

Founder of Code Climate here. I can give you my take on it.

We do a lot more than linting. Code Climate finds complexity and duplication issues as well, and turns that into clear, timely feedback for the developers. For example, if you introduce some new duplication (perhaps you intended to refactor but got sidetracked), Code Climate can let you know as soon as the code reaches GitHub, so you can resolve it right away (or not -- depending on the situation).

Linting is a very small part of what we do. If you're already using JSHint locally as a pre-commit hook, it's probably not better than that. (We'll pickup and automatically use your JSHint config in that case.) We added linting because in our experience a lot of projects with JS (especially Rails apps) don't use linting, and we wanted to expose the value of linting to those people in a zero-effort way.

bergie2• 13 years ago

Looks interesting, but is unfortunately not that useful for projects that include either build artifacts or external dependencies in their repositories. It would be awesome if it utilized some sort of ignore syntax for those.

brynary9• 13 years ago

We do have an "Exclude Patterns" setting that accepts a dir globs in the repo settings area.\

Edit: We also automatically ignore minified files. If you need a hand with anything please shoot us an email and we can help you out (hello@codeclimate.com)

bergie2• 13 years ago

Thanks for the response! It seems exclude patterns are only available for paying customers, not for open source projects.

scrabble2• 13 years ago

Looking at the Code Climate page it has taken me a while to figure out what Code Climate actually is, and I'm still not terribly sure.

It's also given me the thought that a site where people can sign up to submit code for review and have their code reviewed by someone, which might work well for single developers or very small teams.

brynary9• 13 years ago

Founder of Code Climate here. We help developers improve the quality of their code by providing automated code reviews using static analysis. There are no manual (human) code reviews involved at present.

You add a Git repo, we analyze it (Ruby and now JS) and then track how it's changing over time. There's a heavy focus on providing clear, timely information rather than just spraying out a bunch of metrics.

If you have any questions, please let me know!

scrabble2• 13 years ago

Thanks for the explanation. I'll keep an eye on it and test it out if any of my JS projects grow well enough to justify it.

Segmentation• 13 years ago

I see jQuery in the example. Since jQuery is open source, can we see the jQuery Code Climate page? Or is it private? (and why?) Maybe I'm just misunderstanding.

Edit - I think I found it, once realizing the URL matched Github. https://codeclimate.com/github/jquery/jquery

nonchalance2• 13 years ago

There are some issues which make me question the usefulness for a javascript project:

For browser-based scripts, usually a minified and an unminified version are made available. That unminified version is usually the product of a script that concatenates other, smaller scripts. This leads to a perceived high level of duplication (because, after all, they are the same functions and code). For whatever reason, even in private mode, the exclude patterns are not followed.

Also, the linter is much more aggressive than jshint/jslint (in many cases, for no good reason). For example, in a function whose sole purpose is to do bit twiddling (interpreting a set of bytes as an IEEE 754 double), the linter complains `Unexpected use of '&'`. (the original line was `c3 = (e3 & 3) << 6 | e4;`). Akin to JSHint flags, there should be flags to control the linter.

brynary9• 13 years ago

Minified files (auto-detected by long line length) are automatically ignored. If you're having issues with exclude patterns, please email us and hello@codeclimate.com and we can take care of it. We have lots of customers using it.

The linting is JSHint under the hood and is configurable. If you checkin a .jshintrc file it will be used automatically.

richthegeek2• 13 years ago

This would be great to try out, but unfortunately it doesn't seem to work on my code structure!

Most of my projects are CoffeeScript residing in /src, compiling into an identical structure in /lib.

I tried it with a small project, and it only picks up the index.js (which is an example script):

https://bitbucket.org/bithiive/authio-js-client/

Any ideas on what is going on here? Perhaps the "avoiding minified files" is getting in the way?

richthegeek2• 13 years ago

Also given it a shot on some more friendly code (no concatenation, no root index.js) and it completely fails:

https://bitbucket.org/bithiive/delayed-ping

brynary9• 13 years ago

I'll take a look at this and figure out what's going on for you guys. lib/ is not handled in a special way. (It's a blacklist that tries to exclude minified and vendor JS, not a whitelist.) Will reach out via email.

cocoflunchy• 13 years ago

Looks nice, but I'm not sure what to make of this when underscore.js has a 0.0 score (https://codeclimate.com/github/jashkenas/underscore/trends).

brynary9• 13 years ago

The GPA is calculated based on the ratings of the JS files in the repo. Underscore has only one file, which is an F, leading to the 0.0.

Here's the report for the underscore.js file with the specific issues that were identified: https://codeclimate.com/github/jashkenas/underscore/undersco...

nonchalance2• 13 years ago

Many of the complaints are due to the opinion that the braceless if is bad:

    if(foo) bar();

I understand why you may think

    if(foo) { bar(); }

is better, but it's unnatural for most people

brynary9• 13 years ago

I should add: When you have a ton of code in a single file, Code Climate will start to assess penalties. The idea is to try to approximate how maintainable and approachable a given piece of code would feel to a developer who is looking at it. It's not perfect, but very large files tend to be harder to maintain in general.

So Underscore's choice to be single file effectively dooms it from the start. Ember.js, on the other hand, is larger but more decomposed and scores fairly well.

fpp• 13 years ago

and the underscore.js page at Travis-ci:

https://travis-ci.org/jashkenas/underscore

(funnily enough also been produced on a bluebox.net machine)

nevertheless overall this looks very promising - great UI design

moondowner• 13 years ago

How does it compare to using Sonar with the JavaScript plugin? (not in a Sonar vs Code Climate way, but specifically for JS)

http://www.sonarsource.com/products/plugins/languages/javasc...

elwell• 13 years ago

Want CoffeeScript

ianstormtaylor• 13 years ago

Love the idea for the tool, and happy to see it support Javascript. Some feedback:

- Let open-source projects still live under an account, instead of being weirdly separated. Just oauth with Github and automatically lint all of my repos. I definitely wouldn't mind getting an email for all of them. You're making way more work for yourself by splitting open-source vs. private, when I don't think you gain much. Companies will still have to use the private system. Look at Travis for a better example of how to do this. This is critical to me using the product, I don't want to have to remember the link to these things every time.

- Call it "open-source" not "OSS". Unnecessary abbreviations are confusing. I don't ever refer to it as "OSS", but I'm sure the people who do still understand "open-source".

- The other benefit to letting me actually have an account for open-source things is that I don't have to see the annoying marketing bar all the time when visiting my own repo.

- Even though that solves the marketing bar, get rid of the marketing bar. It's by far my most hated "feature" of most sites, and I would feel pretty comfortable saying that since your target audience is developers most of them probably aren't fans.

- The other benefit is that the ignoring patterns don't need to be migrated over, they're just there. (You'll see this pattern a lot, because separating open-source out is a bad abstraction in your app's design, so it will lead to tons of other random problems and extra work. I'm literally doing this right now for Segment.io -- moving from "projects" that exist by themselves to "users" and "organizations" that contain them.)

- Have an option not to lint. The linter options are really strict, I use a very lax version of JSHint in Sublime, but I don't use .jshintrc because I don't want extra bloat files in my repos.

- It seems like every time I want to add a new open-source repo I have to navigate to the pricing page a click a tiny link... (If I'm actually able to have an account for open-source projects, that wasn't clear at all from the landing page, it looks like signing up is only if I want to pay for a private team account.)

- Add a link to your homepage on your blog. (The old classic.)

- Don't make your min-width so wide. I mean I'm a dev with a huge monitor and still I had to open up my window to not feel claustrophobic. No page in your app needs to require that much space. Cutting off source at ~80 characters is perfectly fine. (Actually, lots of your internal pages could benefit from having less space instead.)

- Make your climate badge look nicer. Travis's badges are disgusting, so no need to copy them exactly ;) (Retina would be nice!)

- If the "view on github" button is important (I think it is) then make it look important. I had no idea what it did until clicked it because the icon doesn't communicate much. (Plus that "g" is from their old wordmark.)

- The search by class name, badge and tweet button are all different sizes so they feel very awkward next to each other.

- The site is really slow. It takes ~5 seconds to navigate from the feed page to an individual file by pressing the graph. And around 1 second to "view more" on the snippets of code. Generally this just makes me frustrated and less happy to use the product. (The importance of this is often underrated, I know because our own dashboard has this exact problem.)

- Come up with a layout that doesn't need to have the repo name overflow with ellipsis. That's pretty much one of the most important pieces of text on the page, so it's not okay to truncate it.

- Get a yellow with more orange in it for "C". Then it would be possible to still use a white letter. This way your highcharts graphs don't break since the labels are all white there.

- Be more consistent with your color scheme. The greens and yellows on the tour page aren't the same as the in the grading. And they're also different from the colors in the source view. And they're different from the colors in pricing?

- Heyo! Just found the "Solo Plan", op, nope that doesn't solve my problem nevermind.

- There's probably a more understandable way to organize the table of files by the way they are nested in the codebase. you might want a sort of Github file navigator instead. Or at least files that are in the same folder shouldn't be bisected by files that aren't.

- I have no idea what the complexity numbers mean. Or the duplication numbers (is that lines of code duplicated?) Or the churn numbers. Or what "C/M" means. Or the smell numbers. Or why smell is a category, since aren't all of these code smell? Should it be lint instead?

- Having a file navigator would eliminate the need for paging the files. (Really strongly suggest a file navigator because it will feel very nice to browse the same way as on Github. I don't need to see every single file up front. I can just browser through my repo like normal. And then the bad ones are called out on the feed page.

- The refresh button is also confusing, why is the commit shown? (I know why now, but in its current state it's un-obvious, slash ugly.)

- Don't abbreviate "Complexity per Method" to "Complexity / M" just to then have a tooltip on hover that says "Complexity per Method".

- Lines of code count seems broken. Lines of code per method also just shows exactly the same as LOC, which also seems broken. Same with method count. (for https://codeclimate.com/github/segmentio/analytics.js/lib/in...)

- Breakdown over time graph is probably better visualized as a percentage-based stacked area plot.

- Churn vs. quality seems pretty useless to me. Can't think of why that will help.

- GPA is a really bad metric. My co-founder asked (is a low GPA good? because the connection to school GPA isn't clear) Just give me an overall grade like "D" for the repo instead. You can still plot the real number over time but I don't need to know about it.

Hope some of that helps! The product seems very promising. The actual (non-lint) smells it finds are usually pretty good from what I can tell.

pedalpete• 13 years ago

Wow, that is an amazing amount of feedback. I'll second the OSS vs. Open-source thing, but I have to confess, I didn't even see anything about open-source until I searched OSS on the pricing page. I wonder how many people have missed this.

ethanazir• 13 years ago

bootstrap: 0.51 ??? meteor: 0.85 may need some tweaks.

etler• 13 years ago

I tried it out, but forgot that it wouldn't work with our project because it's all in coffeescript! Oops.

woutr_be• 13 years ago

I would love to give this a try, but I feel the price is a bit steep for a single developer. Will there be smaller plans in the future that only allows 1 user?

Cynddl• 13 years ago

There is a plan for one user at $24/mo.

"We also offer a Solo Plan for 1 user and 1 repo, for $24/month. (Does not include Security Monitor and Trends)"

Show HN: Code Climate for JavaScript

Related Stories