5 ms·
There’s nothing more frustrating than debugging some ruby module with 10 different mixins defining functions with generic ungreppable names like “user”. Then it
by wonnage 5y ago
There’s nothing more frustrating than debugging some ruby module with 10 different mixins defining functions with generic ungreppable names like “user”. Then it turns out the mixins have mixins.
The common refrain is well, don’t write shitty code then, but all code starts off looking good to the person who wrote it. I guarantee if you have 400 engineers working on a Rails app it will end up in this state because it (ironically) lacks sane guardrails
- weatherlite 5y agoRubymine's autocomplete got to a state where I barely ever have to grep anything. Look what you're describing can happen, it's just not that often or is the norm. It's usually some crappy legacy project no one wants to upgrade or touch that reaches such a state, there's absolutely no reason why what you described can't be refactored. The fact it isn't being refactored tells you more about the company/teams working on it than about the framework.
- emodendroket 5y agoRubymine's autocomplete is the best available but it's pathetic compared to what IntelliJ platform can offer in most languages.
- weatherlite 5y agoIt's not as good as a typed language but it's pretty good and it will only get better with time.
- emodendroket 5y agoEven compared to what they offer for PHP or JavaScript it's unimpressive.
- hw 5y ago> The common refrain is well, don’t write shitty code then, but all code starts off looking good to the person who wrote it. I guarantee if you have 400 engineers working on a Rails app it will end up in this state because it (ironically) lacks sane guardrails This can be said the same of any other framework or language. It is up to your team to organize the code, write documentation, agree upon linting rules and of course encourage best practices. If you’re leaving those decisions to each engineer writing code - thats the problem