How to reduce number of hierarchical 'if statements'

I have hierarchical the statements like this

<% @descriptions.each_with_index do |description, i| %>
  <% description.tale2.each do |tax_ref| %>            
    <% if condition %>              
      <% if condition %>
        <% if condition %>                  
          <%= $text_first_describe%> <%= $paren_author_yr %>
             <% ref_sp_uniq.each_with_index do |ref, i| %>
               <% if ref == tax_ref.ref_wo_brace%>
                  <% execution %>                      
               <% elsif i == (ref_sp_uniq.size - 1)%>
                  <%# @ref_desc = "#{@ref_desc_numb}. #{tax_ref.ref_wo_brace}" %>
               <% end %>
             <% end %>
          <% if condition %>
                  <% execution %>                      
          <% elsif condition %>
            <% execution %>
          <% elsif taxon_name.emend_author_year %>                    
             <%= print %>
          <% else %>                    
             <%= print %>                    
          <% end %>
        <% end %>
      <% else %>
        <% if condition %>
          <%= print %>
          <% ref_开发者_JS百科sp_uniq.each_with_index do |ref, i| %>
             <% if condition %>
                <% execution %>                      
             <% elsif condition %>
                  <% execution %>                      
             <% end %>
          <% end %>
          <% if condition %>
            <% execution %>                      
          <% elsif condition %>
            <% execution %>                      
          <% elsif condition %>
            <% execution %>                      
          <% else %>
            <% execution %>                      
          <% end %>
        <% end %>
      <% end %>
    <% end %>
  <% end %>        
<% end %>

Kindly suggest me possible way to reduce this kind of junk "if statements".

If your nested IFs are becoming very complex, you might consider describing the entire structure with a state machine and processing it like that. That way you get the documentation of the formal state diagram and your code will be much simpler.

Edit:

Here is a better attempt to describe the process. The nice thing about this is that once you have your initial state diagram and the code to process it, adding new states is very easy to do. (Expecially if you build a little tool to read your diagram and generate your table for you).

Most people just use these in the context of regular expressions and leave them alone otherwise, but it is a nice powerful tool to have in your toolbox. A common example is implementing a full ftp server this way is trivially easy.

Ok, to my better example, hope this helps.

Consider this IF psuedo code:

if (a < 5)
  do_b
  do_c
  if (a < 3)
    do_d
  else
    do_e
  end-if
end-if

The state transition table to process this might look like:

State   Transition  Action   Next state  
-----   ----------  ------   -----   
1       a < 5                2          
1                            7
2                   do_b     3
3                   do_c     4
4       a < 3                5
4                            6
5                   do_d     7
6                   do_e     7
7                   exit 

The code to process it would look like this:

currentState = 1
foreach table entry
  if table_state == currentState 
    && table_transition is true or blank
       call table_action
       currentState = table_next_state

Take a look at http://en.wikipedia.org/wiki/State_transition_table for a more formal description.

first of all I would put this code in a helper, so you get rid of all the tags and you clean the view, then look if you can apply the case statement and latter remember maybe you can include line_of_code if condition or condition ? code_a : code_b.

Hard to do something without conditions (I suppose the condition change each if), why not to address the question to https://codereview.stackexchange.com/ ?

Ruby's case syntax would probably be a good starting point for cleaning that up, but like others have mentioned you probably need to rethink whats going on in there. Ultimately you probably want to be moving as much of that logic into the model as you can.

My two cents.