few days back, we found our application_helper and few controllers are growing too fast and getting extra fat (lines of code). so we had few refactoring to reduce the extra fat.

now have a look on the code we had with in application_helper.rb taken from tag/v-0.3

this code is not completely visible over the screen snap, this is 340 number of lines. which was the output of our 3 iterations.

though these number of lines are not that much problematic, but we had a scenario which was difficult to make it more concern aware and single concerned.

now have a look on our code which is taken from the current trunk,

Wow, now it is 50 lines only including the header copyright information.
the trick was very simple, we followed the following conventions -

1. find out all related and same concerned functions
2. stick team together in a module
3. include the module to statically import all functions
no integration error, nothing has occurred.
we are happy with this

i think, our ruby learning process is going smooth

i don’t know whether any design pattern or best practice is already exist on this topic.
i came up with something that is really good for me. here is a bit about my task and also the explanation about what i did.

i have a model “category” where i have the following relations -

has_many :category_mappings, :dependent => :destroy
has_many :items, :through => :category_mappings

has_many :categories, :foreign_key => “parent_id”, :dependent => :destroy

has_many :attribute_category_mappings, :dependent => :destroy
has_many :properties, :through => :attribute_category_mappings

belongs_to :category

i was applying :dependent = > :destroy with the mapping model and child categories, which are needs to be removed as a part of the category destroy process.

so i had a messy unit test method to ensure this is working fine. sorry for not keeping my old code snaps otherwise i could show the messy one. anyway here what i wrote later to make it bit cleaner than the previous messy version -

def test_destroy_category_with_dependent
category = Category.find(3)

# prepare for verification
prepare_for_verifying_related_property_mappings(category)
prepare_for_verifying_category_mappings(category)
prepare_for_verifying_child_category(category)

# perform action
category.destroy

# ensure the action
assert_raise(ActiveRecord::RecordNotFound) {
Category.find(category.id)
}

# perform verification
verify_related_property_mappings(category)
verify_related_category_mappings(category)
verify_related_child_category(category)
end

here i just sliced my test method in 2 different roles,

1. preparation stage
2. verification stage

1. preparation stage -
in this stage, i just keep log for current state or other steps which are important for later testing.

2. verification stage -
in this stage, i just verified my new state comparing with the old state (which was kept during preparation stage).
so let’s have a look on the typical code which i wrote in  my preparation and verification stage -

def verify_related_child_category(p_category)
puts “verify related child categories – #{p_category}”
now_category_count = Category.count
assert_equal(true, ((@old_category_count – now_category_count) > 1),
“No category has been removed.”)
end

this seem pretty good for me, as long as i can make my code bunch simple and easy to change.

best wishes,

few of my previously written posts -
usages of “final” keyword in java -

http://www.somewhereinblog.net/blog/hasan/28708715

usages of comment and coding
http://www.somewhereinblog.net/blog/hasan/28704020

let’s check out my recipes -

1. code from your peer developer perspective view.
while you writing your code, always think your code will be reviewed by some other developers, who is not like you,
who is very serious in simple fault and ignorance in writing code. your code will reflect who you are, so better be careful while you exposing yourselves (through writing code).

2. variable convention -
never write short variable name, always write variable which reflects it usages.
for example -

$user = new User() instead of $u = new User(). follow same convention when you have nested “loop”

3. source file naming convention (except java)
set your file name in such a way that will reflect the usages of the file.
for example -

verify_user_authentication.php (or in a packaging manner – user_util_verify_authentication.php). in java you better know how to write package.

4. keep your url domain centric
all urls should be inherited by some specific problem domain for example -

http://abc.com/user/login

http://abc.com/user/register

http://abc.com/user/update

here “user” is problem domain and “login|register|update” are actions or you could say problem.

5. method naming convention -
write method name in such a format that will reflect it usages. or simply make it self describing.
for example -

function verify_user_credentials() {}
def verify_whether_user_profile_is_complete() {}
private void checkUserFlyLimit() {}

6. don’t write query from controller:
build or execute query from DAO or helper or utility or domain itself. don’t put it over controller which limits the reuability and later extendability and interception

7. single concern
while coding, keep your method slim and less concerned about other implementation. for example -

private void isAuthorizedUser(pUser, pAction) {
if (userAlreadyLoggedOn(pUser) && userIsNotBlocked(pUser) && userHasPermission(pUser, pAction)) {
// boooooooooooooooomm…
}
}

8. think from testability
while writing your code always think from testable perspective view. this means, how you could testify your work or module
or bunch of code which your company is paying for.

9. follow coding norms -
i. think before coding

whatever you want to put on your code try to think or imagine before start coding.

ii. dump your think in comment

whatever you thought just write it down over comment or paper or in a common place where you or future developers could have look on. (better place in comment)

iii. write your algorithm in comment.

whatever you planned write in comment before kick start your coding.

iv. set up your unit test case.

find all probable assertion points from use case, put them over your unit test case.

v. write your code
vi. coding routine -

(1) test -> (2) code – go to > (1) [recursively]

10. always put your tag over the source file,
whatever you wrote, that reflects your confident and work efficiency, so better you tag your name over every source code you have written or modified. good for tech lead or project manager, because tagging each file with author name, it creates a hidden responsibility for the author good for both parties.
for example -

/**
* @author someone
*/

handful ruby based tools really helping me to let my smile back. anyway, while i was writing code on rails i am feeling something can be better practice something is not good. from now on, i will try to put them over the my blog.

their is method called “layout” which is used to define the based layout for the controller. this can be used from ApplicationController and other domain specific controller for example : “UserController”.

my team and me was used to define layout over the domain specific controller, but i belief, as we are repeating same “layout ‘template1′” code over and over, it must be better to keep inside the ApplicationController, as because all domain specific controllers are extending application controller, more over it is easy to change.

you may get a question about ajax based response, the better answer is, use render .., layout => false, that will get rid of base layout.

best wishes,