Show HN: Code Climate for JavaScript(blog.codeclimate.com)
blog.codeclimate.com
Show HN: Code Climate for JavaScript
http://blog.codeclimate.com/blog/2013/10/24/code-climate-for-javascript/
31 comments
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.
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).
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...
Here's the report for the underscore.js file with the specific issues that were identified: https://codeclimate.com/github/jashkenas/underscore/undersco...
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.
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.
Many of the complaints are due to the opinion that the braceless if is bad:
if(foo) bar();
if(foo) { bar(); }
Yeah we don't have a strong opinion on the matter. The lack of braces can lead to bugs when attempting to expanding the code in the conditional, as has been the case since the C days IIRC.
The linting is configurable to projects preferences, by checking in a .jshintrc file.
The linting is configurable to projects preferences, by checking in a .jshintrc file.
Speak for yourself, I find the absence of braces to be very unnatural.
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
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
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.
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 ([email protected])
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 ([email protected])
Thanks for the response! It seems exclude patterns are only available for paying customers, not for open source projects.
We are working on the UI for exposing it to OSS. The issue is right now we are not doing GitHub OAuth for OSS repos, so we can't know who should be able to configure the settings for t a repo. This is something we're addressing.
In the mean time, if you email [email protected] we can configure it manually for your OSS repo.
In the mean time, if you email [email protected] we can configure it manually for your OSS repo.
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?
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?
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
https://bitbucket.org/bithiive/delayed-ping
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.
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!!
Well, before I open an account, can you please explain how this is better than using jslint?
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.
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.
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.
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.
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!
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!
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.
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.
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.
Minified files (auto-detected by long line length) are automatically ignored. If you're having issues with exclude patterns, please email us and [email protected] 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.
The linting is JSHint under the hood and is configurable. If you checkin a .jshintrc file it will be used automatically.
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
Edit - I think I found it, once realizing the URL matched Github. https://codeclimate.com/github/jquery/jquery
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...
http://www.sonarsource.com/products/plugins/languages/javasc...
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?
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)"
"We also offer a Solo Plan for 1 user and 1 repo, for $24/month. (Does not include Security Monitor and Trends)"
I tried it out, but forgot that it wouldn't work with our project because it's all in coffeescript! Oops.
bootstrap: 0.51 ???
meteor: 0.85
may need some tweaks.
Want CoffeeScript
- 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.