Eager initialization of instance variables with nil about fallen HOT 3 CLOSED

First and foremost: thank you for the time reviewing this! 😸

In fallen.rb, lines 3-6 you're initializing the instance variables with nil. Why is that? Isn't their value nil when first accessed anyway? I'm curious, maybe I don't see some edge cases where this is necessary.

Great question! At the time I wrote this, I didn't have much experience with Ruby, so I would say that I did it like that due to inexperience. I'm planning on going back to this work in early 2015 and I'll have this comment in mind!

By the way, you're initializing @pidfile but only @pid_file is used later on.

Oooh, that's a great catch! I'll see to fix this sooner than any refactoring. Pull requests are also welcome 😉 😉

Thank you again!!!

from fallen.

You're welcome — and thank you for this nice little gem! Actually I already forked your repo and am working on some things, so I'll add a pull request soon. What is your preferred way for a few commits? Squashing them together?

PS: Feel free to close this issue at any time.

from fallen.

You're welcome — and thank you for this nice little gem!

Glad you like it!!!

Actually I already forked your repo and am working on some things, so I'll add a pull request soon.

Early Christmas present! Yay!

What is your preferred way for a few commits? Squashing them together?

I've no issue with plenty of commits, I don't see a large history of commits as a bad sign. Having said that, I prefer commits that are atomic in their changes, that is, they only affect one part of the gem (or app, for that matter, as I've the same philosophy at work.) I've hundreds of commits where I've only changed one line, and few commits where the change was in a thousand lines but all part of the same change. Squashing them together make it hard to revert a feature/bug fix in case it's ever needed.

Thank you again for the time!

from fallen.