Coding style for Verilog question

Here at work I have been taught to use this coding style in Verilog...

Whenever possible, exclusively define combinational logic in combinational always blocks and use only one sequential always block that only thing it does is pass the outputs from the combinational logic in the output flip-flops.

Let me take an example to clarify what I am trying to say.
Rather than writing:

always @(posedge clk)
...if (x == 1'b1)
...begin
......out1 = a & b;
......out2 = c | d;
...end
...else
...begin
......out1 = a + b;
......out2 = c - d;
...end

write like this
// this always only controls out1_input and nothing else
always @(a or b)
...if (x == 1'b1)
......out1_input = a & b;
...else
......out1_input = a + b;

// always only controls out2_input and nothing else
always @(c or d)
...if (x == 1'b1)
......out2_input = c | d;
...else
......out2_input = c - d;

// no combinational logic here, only load outputs
// from combinational logic in output flip-flops
always @(posedge clk)
begin
...out1 = out1_input;
...out2 = out2_input;
end

Now my question: Is this style efficient? I haven't seen Verilog code that respects this and I wonder if it isn't too restrictive from the synthesis point of view.

Edit: I have replaced dots with spaces for readability because the forum strips spaces

You needn't define seperate combinational block and sequential block of the generation of one signal. i.e, you can describe the generation of out_1 in one always block and describe out_1 in another sequential always block,eliminating two combinational blocks. This style is also a good style.

You can define the combinational logic in one block,
or two. It makes no difference in simulation point of
view, but the former one may cause mismatch between pre-and post synthesis.

by the way, it is better to use non-blocking assignments in sequential block.

Thanks for the replies, but my question was referring more to the sequential-only always block. I mean, not mixing combinational logic in a sequential always block.
Maybe I need to clarify even more.
When possible, modules are viewed as FSM's. That is combinational logic that gets its inpus from the outside world and from outputs of the sequential part, and a sequential part that is only flip-flops that load the outputs of the combinational logic, get them at the outputs, and feed them back to the combinational part. The coding rule in the company I work for is: the combinational part is defined in one ore more always blocks (preferrably one block for each independent combinational output), and the sequential part (the output FF's) is defined in its own always that has zero combinational logic in it, that is
always @(posedge clk)
begin
...out1 = out_in1;
...out2 = out_in2;
.
.
.
...outn = out_inn;
end
Zero combinational logic here, nada, niente, only a register is synthethised suposedly.

This style is rigurous and forces you to write well organized code, but I wonder if it isn't too restrictive sometimes, if it doesn't prevent synthesis tools from optimizing efficiently. I mean, it's TOO rigurous I think, and that rigour turns into rigidness sometimes.

a rule of thumb is that whenever you use sequential always statement, the non-blocking assignment is preferred and when you use combinational always statement, blocking statement is preferred.

may be to clarify it better, its advised to use non-bloking when there is a mix of sequential and combinational logic in an always block or sequential only logic in an always block, otherwise go ahead with blocking styles.

Sorry guys, but do you have a fixation with that blocking/non-blocking thing?
I know that, it's completely another thing that I'm asking.

Z80 said:

This style is rigurous and forces you to write well organized code, but I wonder if it isn't too restrictive sometimes, if it doesn't prevent synthesis tools from optimizing efficiently. I mean, it's TOO rigurous I think, and that rigour turns into rigidness sometimes.

Click to expand...

I think this style is only hard for reading, synthesis tools will be happy to compile this code. Macrocells of CPLDs i know are always made up of some combinatorical logic and a register of some kind at the output.
(the same as your code is organized)