4 ms·

On the nulls bit, in a context where nil is a legitimate value, my team's policy is to use the ampersand operator. To be honest this is preferable because it cl

by tomc1985 6y ago

On the nulls bit, in a context where nil is a legitimate value, my team's policy is to use the ampersand operator. To be honest this is preferable because it clutters up code the least. I don't think we use a single try() anywhere, even before I used ampersands it was always `blah_blah unless x.nil?` etc etc

berkes 6y ago
There are legitimate cases for `nil`, but far less than most people allow. What does "user.last_login_at == nil" mean? `NoMethodError `to_human_date` for `nil` in email.erb. "Quick! lets fix that with a `try(:last_login_at, "Never")`: if nil, it means the user never logged in. You now, without proper thought, you introduced a business meaning to a missing value. Adding tight coupling, slowly painting yourself in a corner. How does this translate to "Could you give me a CSV with all users that never logged in"? Maybe you did mean to assign such domain-meaning to "last_login_at == nil", but then it is far better to explicitely do this. E.g. a `NeverLoggedInUser` subclass, a method on the model `never_logged_in?` an explicit flag in the database, or maybe even a special table "inactive_users" that holds these. All depending on domain-meanings, discussions, use-cases and thought. This is always a lot more work than just throwing another `try` at the bug. Rails "rewards" the bad choice, and somewhat opposes the proper solution. Rails makes it easy to prototype and rapidly move forward: those are good features. But often you should, instead, be forced to halt for a second. To push you towards the whiteboard. Being able to throw in a quick `try` here, or a `sort(last_logged_in: :desc)` with another `where.not(last_logged_in: nil)` there, and so on, are a blessing when quickly moving forward. But they will haunt you in the future. Balancing that is hard, regardless of framework, but Rails' features balance towards the "moving fast" a bit too often in my liking. Esp. because it rewards that team-member who "Gets stuff done" by abusing those "quickfixes", while leaving the project with ever more technical debt etc.

berkes 6y ago

There are legitimate cases for `nil`, but far less than most people allow. What does "user.last_login_at == nil" mean? `NoMethodError `to_human_date` for `nil` in email.erb. "Quick! lets fix that with a `try(:last_login_at, "Never")`: if nil, it means the user never logged in. You now, without proper thought, you introduced a business meaning to a missing value. Adding tight coupling, slowly painting yourself in a corner. How does this translate to "Could you give me a CSV with all users that never logged in"? Maybe you did mean to assign such domain-meaning to "last_login_at == nil", but then it is far better to explicitely do this. E.g. a `NeverLoggedInUser` subclass, a method on the model `never_logged_in?` an explicit flag in the database, or maybe even a special table "inactive_users" that holds these. All depending on domain-meanings, discussions, use-cases and thought. This is always a lot more work than just throwing another `try` at the bug. Rails "rewards" the bad choice, and somewhat opposes the proper solution. Rails makes it easy to prototype and rapidly move forward: those are good features. But often you should, instead, be forced to halt for a second. To push you towards the whiteboard. Being able to throw in a quick `try` here, or a `sort(last_logged_in: :desc)` with another `where.not(last_logged_in: nil)` there, and so on, are a blessing when quickly moving forward. But they will haunt you in the future. Balancing that is hard, regardless of framework, but Rails' features balance towards the "moving fast" a bit too often in my liking. Esp. because it rewards that team-member who "Gets stuff done" by abusing those "quickfixes", while leaving the project with ever more technical debt etc.