Web Dynpro Code Wizard - code patterns

Question

Hello,
the code patterns that are generated by the very helpful Web Dynpro Code wizard seem to be a little inconsistent in their syntax structuring.
If I were to ask the wizard to read me a context node - I would get something like (some bits removed for brevity):
data lo_nd_result type ref to if_wd_context_node.
  data lo_el_result type ref to if_wd_context_element.
  data ls_result type wd_this->element_result.
* navigate from <CONTEXT> to <RESULT> via lead selection
  lo_nd_result = wd_context->get_child_node( name = wd_this->wdctx_result ).
* get element via lead selection
  lo_el_emp_search_result = lo_nd_emp_search_result->get_element( ).
* get all declared attributes
  lo_el_emp_search_result->get_static_attributes(
    importing
      static_attributes = ls_emp_search_result ).
Yet if I were to ask the wizard to generate a message I would get:
*  get message manager
data lo_api_controller     type ref to if_wd_controller.
data lo_message_manager    type ref to if_wd_message_manager.
lo_api_controller ?= wd_this->wd_get_api( ).
call method lo_api_controller->get_message_manager
   receiving
     message_manager = lo_message_manager
*  report message
call method lo_message_manager->report_t100_message
   exporting
     msgid                     =
     msgno                     =
     msgty                     =
*     p1                        =
*     p2                        =
*     p3                        =
*     p4                        =
*     msg_user_data             =
*     is_permanent              = ABAP_FALSE
*     scope_permanent_msg       = CO_MSG_SCOPE_CONTROLLER
*     view                      =
*     show_as_popup             =
*     controller_permanent_msg  =
*     msg_index                 =
*     cancel_navigation         =
*     enable_message_navigation =
   receiving
     message_id                =
Edited by: Thomas Jung on Apr 27, 2010 8:56 AM

Answer 1

post  split to avoid silly size/formatting limits
Ok - both work - but one is using the:     
result = class_ref->methodname( parameters = paramvalue )
and one is using 
call method class_ref->methodname
                                  exporting parameters = paramvalue
                                receiving result = result.
As I often have to review code written by others, I encourage them to use these wizards - it helps speed code and prevents simple mistakes.  But code that contains multiple different syntax structure approaches is harder to read (albeit only slightly), moreover - it looks sloppy.
But why are they not consistent in their syntax structure? (one could also argue why do we have multiple syntax structures for the same operation - but that's a different discussion).
Is there some way customers can update these structures to match with their own internal coding standards - or something we can change so that they go one way or another?
I look forward to other's thoughts on the same topic.
Cheers,
Chris