What is Reddit's opinion of Code Climate?

From 3.5 billion Reddit comments

Hello! Founder of Code Climate here. A few random thoughts:

• Code Climate does need source code access, so using our hosted service does increase surface area there. The risk associated with that is correlated with the risk overall that source code poses to your infrastructure.
• Best practices for source code security would be to not store any credentials/secrets in your code, and also not roll your own crypto.
• Code Climate has security related checks that can help ensure its net positive for security. For example, we can detect of secrets are checked into the codebase, or you are depending on vulnerable versions of packages. We are regularly used to pass compliance audits.
• We focus and invest heavily in security. We have a statement about select security procedures we follow here: https://codeclimate.com/security
• For organizations with specialized security needs, we have a product that you can deploy behind your firewall.

In short, it's an important issue to consider. For most organizations using GitHub.com or BitBucket, CodeClimate.com is a good fit. For organizations using GitHub Enterprise or Atlassian Stash behind the firewall, our Code Climate Enterprise product can be deployed along side it, behind the firewall also.

If you'd like to discuss security further, or learn more about Code Climate Enterprise, feel free to contact me at anytime. My email is bryan@ our domain name.

I started professionally developing more than 20 years ago; I've also taught many classes, and hired a lot of people for development roles, including in Rails. When I'm hiring someone, I care a lot more about whether they're a good developer than what language or framework they know.

Unless I'm hiring for a serious senior position, the most I expect of a developer is to have a basic understanding of how Rails works, and how it can be refactored. Basically, what I care about is whether they can come up with solutions to programming problems (which are pretty much the same in any language) more than what language they can do it in.

For example, I might ask a few questions about how the backend cycle works in Rails (request to response), building a controller from scratch, refactoring a messy model into better patterns given a few hints, etc.

As far as "MUST HAVE 3 YEARS" - writing job descriptions is hard even when you know exactly what you're looking for - and businesses almost never know what they really want for an employee. Even early in my career, I never paid much attention to the job description. I'm self taught, and most of them absolutely must have a degree in CS - but most of the time they didn't care about my education if we were a good fit.

I wouldn't put too much stock in it - if you like a position and the company, by all means send in a resume, even if they don't have open positions! I've gotten several jobs simply by saying "hey I'm looking for what to do next and your company seems really great, do you have any open positions? Here's my resume."

Long story short - be confident, bold, and don't eliminate yourself from the running before you start.

https://codeclimate.com/quality/ is what first comes to mind. They grade code based on maintainability and churn.

There's also plenty of language-specific open source tools, reek is a decent one for Ruby.

Others have answered the question of how to simplify one method. It seemed to me like the question was how to fix the duplication, or in other words, not have four similar methods with so much code duplicated from one to the next. Edit: It looks like /u/zoso might have been going for something similar.

Go here and click on the Source tab to see what I mean.

Here's one way to do that, following /u/tomthecool's basic approach:

def dblookup(key, match_value, return_key) return '' if match_value.nil?

line = db.find {|line| line[key].eql?(match_value) } line ? line[return_key] : '' end

def mac_to_ip(mac) dblookup(:mac, mac_flatten(mac), :ip) end def ip_to_mac(ip) dblookup(:ip, ip, :mac) end def locate_mac(mac) dblookup(:mac, mac_flatten(mac), :location) end def locate_ip(ip) dblookup(:ip, ip, :location) end

This is a question I have never seen an answer to. People are always talking about best practices but are never able to point to an example open source project. Seeing and, more importantly, working with better code is a great way to get better.

You might check out GitLab. It is reasonably well tested and the code climate rating isn't bad, but you'll run across some bad habits as well.

You may also be interested in services that provide a similar function like Scrutinizer or Code Climate - both have free options if your project is open source.

Oh hey, as discussed here previously

You write that you found a good practise: "We started to track and fix code duplication". We've been thinking about doing that too using https://codeclimate.com/ . Could you share a bit of detail about how you implemented this and what the benefits were?

I'm using code climate to help out with code quality in my idle game. Right now my score just tanked when I added in upgrades.

here's the link to the problem

I have a lot of duplicated code in my upgrades because I put the content for the upgrades in my code. I should probably remove the content and shove em into json files.

I want to minify things down and don't want content like the upgrades to have to be fetched in. Any ideas how I can fix this issue?

Note: I work for Code Climate, and I am also a PHP developer. The Code Climate PHP tool is in public beta right now. We've recently added 30 new checks, and we are actively working on new features all the time with our full-time dev team of 12 developers. We also have an on-premise version of our software (so no code is ever sent out to us) that we are currently testing with several of our clients. Let me know if you'd like more information on that.

Some differences between us and the other two programs you mentioned:

SensioInsight: Cheaper, but only checks PHP (which may be all you need). Very Symfony 2 focused, so unless you are following Symfony 2 development practices, you may find many of the checks unnecessary.

Scrutinizer: Checks PHP, Python, and Ruby. Scrutinizer has built a nice gui admin panel on top of several open source tools (PHP Code Sniffer, PHP Code Similarity Analyzer, PHP Change Tracking Analyzer, PHP CS Fixer, PHP Mess Detector, PHP PDepend, PHP Analyzer, and Security Advisory Checker). If you are concerned about cost, you could just implement all of these open source tools yourself for about the same benefit. Also, because it runs all of these separate tools for the analysis, the analysis is significantly slower to run than Code Climate, which is a single integrated analysis tool.

If you are interested in trying Code Climate, it is free for open source repositories. If you would like to try it on a private repo, you can get a two week free trial on our website, but feel free to email us through our support page: https://codeclimate.com/help Tell them Beth sent you, and we'll get you a code for a 60-day free trial.

Thanks for asking this. It's not always like this. Yes: more and more, companies are trying to figure out remote engineer productivity. Some are big brother-ey about it. Know this: you matter more than Gitprime and your manager is probably just trying to help... It's an issue I've dealt with both as a manager and as a direct report. Try helping him or her by asking what she needs. Try being transparent and seeing if the suggestion helps! Timeboxing may help. Consider asking if there are concerns about your productivity. Be honest.

And, look, these kinds of analytics don't have to be bad! My experience with Velocity (Code Climate's) approach, it was similar to what they show here with Tangoe: https://codeclimate.com/customers/tangoe/

It's an issue specific to Pluralsight and if you're on a team that's considering it, tell them the problem is it assumes what a good pattern of work is instead of letting the team bring context to conversations: the data needs to be treated as a starting point for 1:1s and stand-ups the way Tangoe used where they just treat it as material rather than as fact of who's doing "good" or "bad."

It's a subtle but really important difference. Ask if they're still evaluating Pluralsight and whether they might check out Velocity instead.

And, assume best intentions with your manager. Be direct with understanding and asking about the reasons for tracking certain metrics.

We’re using Code Climate and I think it’s working pretty well for code smells, linting etc. Integrates well with Github PRs, and can handle code coverage reporting as well.

The author is just venting on how they hate being held to professional standards of software craftsmanship and are looking for community justification on a case where they think it is "just fine" to be sloppy and lazy.

Fact is, the only time you can write crap code and be semi-professional about it is when it's YOUR OWN non-employer code that you're NOT being paid for. Look at my github repos https://github.com/hopeseekr and you'll see several projects that take shortcuts over the decade or so: https://github.com/hopeseekr/MyMirror but then you also see truly professional code when I release it on Packagist: https://codeclimate.com/github/phpexpertsinc/RESTSpeaker

DO NOT give non-professional hackers much slack! When we hold each other to accountability, all of our lives are better and the script kiddies eventually get "fed up" with being held accountable to higher standards and go find more... in trouble businesses to wreck further.

1. Various types of objects, including service objects.
2. All rules, including the one you mention here, are break-able. There's a such thing as necessary complexity. Its ideal to try and keep complex logic out of your controller, but occasionally its not avoidable without trading one problem for another (premature abstraction, complexity of a different type, maintenance issues, etc).

> Single Table Inheritance

IMO, don't use this regularly. Only use it in very specific cases. It causes maintenance issues over time.

> What are some other concepts or best practices do you recommend?

Generally speaking, understand Rails best practices. You don't necessarily need to treat each one as gospel, but at least know where the industry is moving in general. So, read up on stuff like (Sandy Metz's rules)[https://robots.thoughtbot.com/sandi-metz-rules-for-developers] and (Service/Query/etc Objects)[https://codeclimate.com/blog/7-ways-to-decompose-fat-activerecord-models/].

And then also, start to understand how the rest of the stack works. How does a database work? Knowing this will help you build more effective models and data structures. Knowing SQL well even though you have ActiveRecord will help you identify things like N+1 queries, issues where you're missing an index, issues where you do actually need to break out of AR, or just generally prep you for larger scale projects. Learn about how web servers operate - what's a load balancer, for example? Background/async jobs. What's a crontab? Etc etc..

Sandi couldn't think of any open source projects off the top of her head, most were behind firewalls.

But she recommended check out projects with high scores at codeclimete: https://codeclimate.com/oss.

Code analyzers tell you when to remove this stuff after it yells at you enough you don't really need the code analyzer. I use https://codeclimate.com/ for personal projects. I don't even really need it anymore for cyclomatic complexity. It's kinda like when your browser yells at you enough for misspelling a word, eventually, you just learn through error.

I like the 2nd option, learned that from the code analyzers yelling at me. Minor gripes though.

I'm doing refactoring because I've faced difficulties on extending this class and classes that inherited from it. I've deferred this refactoring long time and live with "F" on only this file https://codeclimate.com/github/skyderby/skyderby/app/models/tracks/base_presenter.rb

And as I needed to change it once again I decided to make it extendable in the future.

Link is very useful. Thank you.

I'd start off with working my way through your automated feedback, in particular the static accesses (unless they are proxy classes?). The feedback about removing else clauses is rather odd though - not heard that one before.

I've had a good experience of Scrutiziner, which does much the same thing - maybe that's worth a go.

Can you get your build badges to reveal your coverage percentage? How much of the code is covered at present?

Whenever I run into this (and I always do, TDD is great, but there's always something I write a bunch of code for first, then test it), I pick the most used or important (or even most recently developed on, since it's fresh in my head) and start a trail of tests. Unit tests up to integration tests. Eventually this will bring you to other features that hook into it that need to be tested.

Also, check out Code Climate (https://codeclimate.com). They show you some great metrics about your code and test coverage, so it'll help you find blind spots.

Here are the few things we've encountered while building our website:

• Don't store user data in un-secure cookies. Always use signed cookies if making cookies via the controller
• Sanitize params. Don't use params.permit!. Use proper require/permit blocks before using the form data to update or create records
• Use https

We ran a security check via Tinfoil Security which gave us good overview of the problems. Also, setting up Code Climate helped catch early code smells.

CodeClimate is free for open source projects, so before I was ready to make the repo public, I used the free trial (twice, somehow) to help me get the bulk of my upgrade done. Once I was ready to go public, I duped the project into a clean repo (with no history of my naughty hard-coded API keys of yesteryear) and added it back into CC and was good to go.

I'm sure everyone has their opinions on how useful it is, but I've found it very useful, at least as a learning tool. Having a bot that can look through every file in your repo at once and point out potential issues line-by-line is much easier than opening each file one at a time and physically looking for issues.

I also use Rubocop with Guard(/ guard-rubocop), so after my specs run (and pass), Rubocop runs too and helps me clean what I just wrote. Then my specs run again to make sure they still pass, and then Rubocop runs again, just because. Then I commit and CodeClimate does its business. It's all very helpful.