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.
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.
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 (hello@codeclimate.com)
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 hello@codeclimate.com we can configure it manually for your OSS repo.
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!!
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.
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.
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.
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.
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.
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.
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".
- 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.
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.
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?
