Refactored object.find in before_filters

[dragosmiron]

No description provided.

[coveralls]

Coverage remained the same when pulling 4c87d3c on dragosmiron:filter-refactorings into 9d43a2c on mezis:master.

[mezis]

While I appreciate the effort, it's a pattern used in HT's application I positively dislike.
IMO state variables should only ever be used in a single method, or at least in very close methods.

With you new code, I read the code for a #create method for instance, and my brain is like

• wait, where does this @user come from?
• oh wait, might be a before_filter ... scroll up the file
• ok here it is ... scroll down the file.

Yes, it's less DRY, but it's much less readable, too!

What do you think?

[dragosmiron]

I just followed the convention that you have in the other controllers where this happens. This means that it's either-or, i just thought it would look nicer if all are the same. It's up to you off course

[dragosmiron]

regarding your scrolling concern, I got quite lost in all the modules that are everywhere :)

[mezis]

Fair enough; internal consistency trumps my above comment. Thanks @dragosmiron, merging!

[mezis]

Also, which module got you lost?

[dragosmiron]

such as Idea::History::Comment::IsSubject, Notification::Base::CanBeSubject, etc
For me it looks like bunny hopping from one file to the other.
My main approach in this would at least be to put them in some files, cause at some points i keep forgetting where exactly they are written.
At least good old RubyMine finds them :)

[mezis]

For me it looks like bunny hopping from one file to the other.

For me it looks like separation of concerns 😄

My main approach in this would at least be to put them in some files

Specific example? I'm not too sure what you mean.