My recent programming-related work was quite interesting; at Rebased I’m working with a solar energy company, writing software for monitoring and administration of their solar panel farms, and at my university I’m researching reversible computing, while dabbling a bit in Crystal.
RuboCop becomes more and more a widely-recognized set of standards for writing Ruby syntax, and while I wholeheartedly disagree with some of its rules and can fully understand the frustration it causes in some developers I still think it’s in general a welcome tool in our everyday life.
Reek, while seemingly similar, is totally different: rather than concentrating on the syntax it tries to point out potential architectural problems in a codebase on an OOP level. Reek’s results are much less rules and much more suggestions where to look for potential issues, and can’t really be auto-corrected (but rather require – often quite extensive – refactoring).
I talk about Reek because it taught me *a lot* about OOP, structuring my programs and, in general, moving code closer to where it belongs, even if it’s non-trivial. I got fascinated by the amount of OOP code smells that can be automatically recognized (and, as a result, became one of Reek’s maintainers).
There are relatively few areas covered by both RuboCop and Reek; RuboCop is more of a syntax style enforcer, while Reek is an architectural tool. There are some common areas of interest –e.g., RuboCop tries to eradicate long methods because they’re a readability issue, while Reek points them out as potential code smells that mix the level of abstraction – but in general the best approach is to figure out what are acceptable thresholds for a given project (e.g., maximum number of lines in a method or maximum number of instance variables) and adjust them as necessary.
In general, RuboCop is much more opinionated because it usually deals with much cleaner choices – ‘this kind of syntax should be indented this many spaces’ or ‘single quotes where possible vs double quotes everywhere’ are relatively easily made choices that should indeed be uniformly enforced across the whole codebase if possible. Reek seldom deals in absolutes; there are often cases where a given piece of logic *technically* should live closer to class A, but *in practice* is much more useful when put in class B.
My general rule of thumb for RuboCop is ‘try to please it as much as possible and only reconfigure it on the most blatant disagreements’, while my rule of thumb for Reek is ‘this are fascinating suggestions, let me look at the smells one-at-a-time and I’ll probably whitelist quite a few of them – and that’s perfectly OK’.
😇 It’s surprisingly hard to share technical rumors without heavily coating them with your own superstitions (or hopes), but it’s really interesting what the Ruby world learns and picks up from functional languages like Elixir and Clojure. Also, the dry-rb family of libraries might be worth a closer look. ;) Also, TruffleRuby seems like a super interesting project…
More advances in stability and performance, with wonderful results delivered by TruffleRuby and sustained progress of incremental improvements from the relentless JRuby team. Probably a few new libraries that will show how to do implement Ruby some interesting features of other languages.
I really enjoy photography – nothing fancy, but some of my street shots can be found at http://chastell.net/1/125/
I also like casual city cycling, sadly I have time mostly on my daily 2×10 km commute. 🚲