Byebug VS rubocop

Just pry or with byebug? If the latter: https://github.com/deivid-rodriguez/byebug/issues/564

Byebug is not fully compatible with Zeitwerk, I was getting random NameError exceptions failing to load constants in development and tests until I removed this gem.

byebug - this elevates debugging Ruby applications. It allows you to run a program line by line, add breakpoints, and evaluate and track values at runtime. If you still use puts for debugging, it's time you get to know Byebug's features and commands.

Immune from the compatibility issue with Zeitwerk

For debugging purposes, I recommend a few gems that will get you started and allow you to play with ruby code in your terminal and manage ruby gems. Gems like bundler pry and byebug do it good and you can check out the official docs, Pry, Byebug, Bundler, These gems need to be accessed globally.

Byebug is a helpful and easy-to-use debugger made for Ruby. It allows developers to use traditional debugging features to help identify what is happening in a program while it's running. Byebug was created by David Rodriguez in hopes of building a better Ruby debugger.

Others have been suggesting byebug, but for us it started causing random constant loading errors on Ruby 3 in Rails, due to Zeitwerk compatibility issues. So I'm quite happy that the debug gem came in as a replacement. I did like that pry-byebug allows stepping in a normal Pry console, I expect the debug gem will require some getting used to.

As far as debugging tools go, the Byebug and Pry are two of the best gems I have found. They are used in different contexts, but for all intents and purposes, including them in your code will halt an operation and allow you to access whatever point in the code you halted within your terminal with a REPL.

We commonly use byebug for debugging our code which is an easy-to-use, feature-rich ruby debugger. This gem is introduced in Rails 5. It offers features like Stepping, Breaking, Evaluating and Tracking.

Looking forward to this, byebug's Zeitwerk incompatibility is currently causing nondeterministic constant loading errors in our app when used with pry-byebug.

gem "rubocop" - https://github.com/rubocop/rubocop | Set up code guidelines for your dev team, I recommend using whatever Standard recommends.

I believe if you use the `||` operator instead of `or`, then things just work out fine. I agree it is really annoying. But I am pretty sure if you use a tool like RuboCop https://github.com/rubocop/rubocop (a static code analysis tool) then it will catch bugs like this. Note that I am not recommending Ruby. But in my experience if you want to work with a language and it has a community style guide and a linter that enforces it, it will save me some heartache.

Adopt some sort of consistent formatting. Your top-level module starts off indented, seems like wasted space. May I suggest RuboCop?

By default, out of the box, RuboCop comes with a default set of pre-configured rules. The documentation will tell you Rubocop's default rules.

RuboCop is a Ruby static code analyzer (a.k.a. linter) and code formatter. Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide. Apart from reporting the problems discovered in your code, RuboCop can also automatically fix many of them for you.

But I will encourage you to adopt Rubocop to enforce the style you want, so that if others want to contribute, they can write with spaces and then run rubocop -a and end up with the styling you prefer. Tabs indentation support was added a couple of years back: https://github.com/rubocop/rubocop/pull/7867

In my last job I encountered my first Rails codebase ever (mostly REST APIs but a few server-rendered views as well). After the initial chaotic impression of the codebase (it was a startup after all) with all the Rails magic on top, I really fell in love with the framework after a more experienced Rails dev introduced a few key conventions and helpful libraries to the codebase.

Out of those, I’d at least add the RuboCop [1] linter and the BetterSpecs [2] guidelines to this list. Both helped tremendously in eliminating bikeshedding in the team and freeing up brainpower to solve actual problems. The first one helped me learn intricacies of Ruby bit by bit right in my IDE and the latter guided us to write tests in a style that’s easy to maintain and trust.

[1] https://github.com/rubocop/rubocop

[2] https://www.betterspecs.org/

RuboCop had a setting for this but it was removed for Ruby 3 because there are valid reasons to pass a hash into a method, and linting it might break code. Here is the issue referencing the commits where it was removed, if you ever need to do this again you could just find an earlier commit.