(A) Like this:
validates :network_id, :numericality => true
validates :direct_url, :presence => true
validates :domain_name, :presence => true
validates :merchant_id, :numericality => true
validates :is_paid_merchant, :presence => true
validates :is_top_merchant, :presence => true
validates :last_months_revenue, :presence => true,
:numericality => true
validates :name, :presence => true,
:length => { :maximum => 50 }
validates :primary_category_id, :numericality => true
validates :url, :presence => true
validates :url_tag, :presence => true,
:length => { :maximum => 45 }
-OR-
(B) like this:
validates :network_id,
:merchant_id,
:last_months_revenue,
:primary_category_id, :numericality => true
validates :direct_url,
:domain_name,
:is_paid_merchant,
:is_top_merchant,
:last_months_revenue,
:name,
:url,
:url_tag, :presence => true
validates :name, :length => { :maximum => 50 }
validates :url_tag, :length => { :maximum => 45 }
In the first case each field has it’s own validates clause and in the second it’s based on what is being validated (fields that have multiple validations appear multiple times). The first case is also in alphabetical order so is a little more helpful to jump right to a specific field.
-OR-
(C) Am I just too anal retentive about how my code reads and looks?
I think the first style is better for the following reason:
It’s most likely that you have a specific field name ‘in mind’ when working on a validation – or editing one – or adding a new validation for that field. So a system that lists each field and then all the validations for each one works well to read.
The other style – group validations together tends to lead to seeing a field in one spot but then having to search and scroll around for other validations for that field – and there’s a good chance that you will not see or know about the other validations for that field which may be ‘off-screen’ and thus missed.
This also may not be that big a deal when initially building the application (when the first style might actually seem easier) but going forward when you are adding or removing or changing fields and validations (i.e. ‘application building in the real world!’) it will be easier and less error-prone if all the validations for a given field are together.
Another example of why B) is bad…
Imagine this:
See how field are repeated all over the place?
Now imagine removing network_id – yuch!
Now imagine adding another _id field that needs numericality, uniqueness and presence – yuch!
Another example – one might think (ok, I’ve done long ago), i’ll group all the ‘required’s together and then put a nice comment for them and then all the uniquesness of’s, with a comment header label for all of them, etc. So there is a ‘standard’ for developers to follow. The problem with an approach like this (apart from the previous comments) is that this is a ‘local’ standard that other programmers (both current and future) will need to understand and then… hopefully… follow. Much as I love them myself, personal standards like this often contribute to technical debt unless clearly thought out.