Skip to Content
Author's profile photo Jerry Wang

Do you agree to write IF 1 = 0 in your production code

IMHO one purpose to write IF 1 = 0 code is to enable the cross reference of message raised in application code.

I have written several blogs to discuss the tip how to find the source code where the error message in UI is raised.

/wp-content/uploads/2014/03/clipboard1_408695.png

Most of the time you have to debug. ( Of course you can use source code scan approach to search the source code with keyword CRM_MDG_CORE 034 , the trouble is how you specify the package to be scanned, especially you are not familiar with the application and you know nothing about package name at all )

The where used List on message could only identify those occurrence where the MESSAGE keyword appears in code.

/wp-content/uploads/2014/03/clipboard2_408696.png

/wp-content/uploads/2014/03/clipboard3_408697.png

For the use case in line 24 and 25 below, the where used list does not work. That is when IF 1 = 0 plays a part.

/wp-content/uploads/2014/03/clipboard4_408701.png

Recently in our code review meeting there are some arguments about this usage. The pros like this approach since it enable the cross reference on message raising by method call and ease the maintenance. The opposition consider that it is “unreached code” and should not appear in production code.

I just check in the system and find there are plenty of such usage in SAP standard code, also I tested that currently no ATC or extended check profile will complain about this “unreached code”. Would you please kindly share your opinion of using IF 1 = 0 this way? Or do you have any concern about it?

Assigned Tags

      27 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi,

      I prefer an alternative approach: Use MESSAGE ... INTO.

      For example:

      MESSAGE e034(crm_mdg_core) INTO lv_message.

      lo_messages->syst_msg_add( ).

      By doing so, we kill two birds with one stone:

      1. Avoid of "unreached code".

      2. Allow debugging of message raise.

      Author's profile photo Jerry Wang
      Jerry Wang
      Blog Post Author

      Hi Shai,

      Thanks and that is a good alternative, except one minor issue: Extended check will complain that no read access is done on the dummy field, however it could be suppressed by pragma anyway šŸ™‚

         MESSAGE e034(crm_mdg_core) INTO DATA(dummy).

      /wp-content/uploads/2014/03/clipboard4_408728.png

      Best regards,

      Jerry

      Author's profile photo Luƭs PƩrez Grau
      Luƭs PƩrez Grau

      IMHO Better a Pragma than a dummy IF šŸ™‚

      Author's profile photo Former Member
      Former Member

      Good approach Shai.

      Author's profile photo Custodio de Oliveira
      Custodio de Oliveira

      Hi Jerry,

      I don't agree, I think it's really stupid. Every time I see something like "IF 1 = 0." I die a little bit inside. Shai's approach is what I usually do. Not only you achieve the 2 points he mentioned, but you also can have a break-point at the keyword MESSAGE.

      Cheers,

      Custodio

      Author's profile photo Jerry Wang
      Jerry Wang
      Blog Post Author

      Hi Custodio,

      thank you for drawing the ability to set breakpoint into my attention, which I neglected below.

      Best regards,

      Jerry

      Author's profile photo Ryan Crosby
      Ryan Crosby

      I couldn't agree more and I abhor this type of code.  It is a wasteful hack when there are other alternatives to the problems you mentioned.  The part that kills me is that it is the most illogical use of a tool that's sole purpose is to function based on logic.  Testing two statically defined conditions for equality that are in fact not equal is absurd. 

      Author's profile photo Paul Hardy
      Paul Hardy

      Just because something is heavily used in standard SAP doesn't make it good. People are only human and there is tons of nonsense in standard code.

      That is bad because sometimes people cut and paste it into their own code thinking this must be a good way to do things.

      In my view of the world using a condition like "IF 1 = 0" is foaming at the mouth, free energy crazy. It's like the craze that was in Syndey in the year 2000 when grown adults were walking around with flowerpots on their heads. I looked at this and thought WHY? They are going to regret this in ten years when they see a photograph of themselves taken at the time.

      Author's profile photo Abdul Hakim
      Abdul Hakim

      Hi Jerry - It does not make sense to use IF 1 = 0 because this condition will never pass. This is a bad programming in my opinion.

      Thanks

      Hakim

      Author's profile photo Former Member
      Former Member

      I sometimes do this in Smartform conditions,  *gasp*.  But I prefer 1 = 2. 

      Author's profile photo Michael Lee
      Michael Lee

      I agree to use 1 = 2 in smartforms.  But I will write "temporarily obsoleted" in the description field.

      Author's profile photo Fabio Pagoti
      Fabio Pagoti

      Sorry for the lack of knowledge but what do smartforms have in special to use this?

      Author's profile photo Michael Lee
      Michael Lee

      Hi,

      It's just a lazy way to comment a smartform node.  I use 1 = 2 when my functional consultant suddenly discards his requirement and I know for sure that he will change his mind again in near future.

      Author's profile photo Former Member
      Former Member

      Just wondering...is there a non-lazy way to do this?

      Author's profile photo Fabio Pagoti
      Fabio Pagoti

      I got it. It might be something worth doing for a fast test but definitely it should be removed before transporting to a quality/production system.

      I'm sure that if smartforms function modules were not regenerated everytime you activate it, things would be simpler as you could control these using version management.

      Thanks for the clarification Michael Lee

      Author's profile photo Paul Hardy
      Paul Hardy

      My functional consultants do the same, the requirement comes and goes, and I know that "whatever it is" wll jump back out of the grave.

      In ABAP I comment out the code in question,and then comment it the week after, then cmment it out again etc.. with comments like the following:-

      01/06/2013 - Mr X no longer wants this

      15/06/2013 - he wants it again

      30/06/2013 - he no longer wants it

      * DO_SOMETHING

      I thought SMARTFORMS were function modules at heart - are you unable to comment things out? You could in SAPSCRIPT! Not that I miss that particular tool.

      Or are you not talking about program code at all but some sort of logical precondition you have to enter in a pop up box just like workflow?

      Going back to ABAP, if the whole point of this 0 = 1 exercise is to find where in the code an error occurs, there surely must be a better way to do it. There could not be a worse way. ASSERT statements that only fire in DEV and QA, writing to the application log, anything, anything, rather than this obvious madness.

      Author's profile photo Former Member
      Former Member

      Or are you not talking about program code at all but some sort of logical precondition you have to enter in a pop up box just like workflow?

      I think "1 = 2" in smartforms is used mainly to stop the printing of some SF element - template, text etc. I too put that condition in the "Conditions" tab with the text "Obsolete" šŸ˜Ž

      BR,

      Suhas

      Author's profile photo Fabio Pagoti
      Fabio Pagoti

      You are all wrong.

      This is actually quantum programming.

      You will never know IF 1 = 0 until you debug it. This is the same concept of Schrödinger's cat.

      šŸ˜›

      Author's profile photo Hai Wang
      Hai Wang

      If seems make no sense in real world, but in the program, anything would make sense, even pig can fly, you are playing as a god in a small world that you created.

      Author's profile photo Former Member
      Former Member

      I think that 1 = 0 was a technique used (to facilitate the "where-used" of the message) when there was no MESSAGE...INTO addition (just my opinion). And since it is widely used in standard BAPIs by SAP many ABAPers think that this is a smart way of doing it, at least i did šŸ™

      But now a days i use the MESSAGE...INTO & then the method IF_RECA_MESSAGE_LIST->ADD_SYMSG( ) to add the message to the application log šŸ˜Ž

      BR,

      Suhas

      Author's profile photo Puneet K. Tripathi
      Puneet K. Tripathi

      Yes , we can !!

      but in SAP -PP programming , we can be use that ..other way ....

      if we use 1=0 and debug it .. it show correct ... but in ABAP ..we have best way to write this logic..

      Regards

      Puneet

      Author's profile photo Eitan Rosenberg
      Eitan Rosenberg

      Hi All .

      May I suggest a more pragmatic considerations.

      I the case of MESSAGE I like Shai Sinai idea .

      But there are other cases the "1 eq 0" (I prefer 1 eq 2....) make sense(IMHO).

      For example:

      Document usage of CONVERSION_EXIT_Yxxx_OUTPUT in ALV LVC_S_FCAT-EDIT_MASK or

      CL_SALV_COLUMN->SET_EDIT_MASK .

      Code:

      DATA: ob_salv_table        TYPE REF TO cl_salv_table .
        DATA: ob_salv_columns      TYPE REF TO cl_salv_columns_table .

        ob_salv_columns = ob_salv_table->get_columns( ) .

        DATA: it_column_ref TYPE salv_t_column_ref .

        FIELD-SYMBOLS: <st_column_ref> LIKE LINE OF it_column_ref .

        it_column_ref = ob_salv_columns->get( ) .

        LOOP AT it_column_ref ASSIGNING <st_column_ref> .

          IF 1 EQ 2 ." for reference
            CALL FUNCTION 'CONVERSION_EXIT_YTS01_OUTPUT'
              EXPORTING
                input = '100'.
          ENDIF.

          IF <st_column_ref>-columnname EQ 'PR100_CALC_1' .
            <st_column_ref>-r_column->set_edit_mask( value = '==YTS01' ) .
          ENDIF .

        ENDLOOP .

      Regards.

      Author's profile photo Former Member
      Former Member

      Hi,

      Interesting case.

      (One other example may be the usage of FM ABAP4_CALL_TRANSACTION, which is widely used. At least before CALL TRANSACTION command was enhanced in NW 7.4).

      However, in such case, I always prefer using appropriate data element instead of setting edit mask/conversion routine manually.

      Author's profile photo Eitan Rosenberg
      Eitan Rosenberg

      Hi,

      Can you follow me ?

      I need to send you a message.

      Regards.

      Or use the phone... Eitan Rosenberg

      Author's profile photo Hai Wang
      Hai Wang

      Hi, Eitan

          IF 1 EQ 2 ." for reference
            CALL FUNCTION 'CONVERSION_EXIT_YTS01_OUTPUT'
              EXPORTING
                input = '100'.
          ENDIF.

      what's the purpose for this block of code?

      Author's profile photo Eitan Rosenberg
      Eitan Rosenberg

      Hi All .

      This is a code fragment from a program that use ALV using cl_salv_table.

      In this case the "1 EQ 2" is used to documet the usage of Function module CONVERSION_EXIT_YTS01_OUTPUT  .

      About using Conversion Exit in cl_gui_alv_grid (The idea is quite similar to cl_salv_table)
      See: http://help.sap.com/saphelp_erp60_sp/helpdata/en/33/206bc8012e11d3b495006094192fe3/content.htm

      About CONVERSION_EXIT_YTS01_OUTPUT (This is a user function):

      /wp-content/uploads/2014/03/2014_03_18_06h38_54_412598.png

      FORM conversion_yts01
        USING
          p_input
        CHANGING
          p_output .

        DATA: buffer_1 TYPE char32 .

        WRITE p_input TO buffer_1 NO-SIGN NO-ZERO RIGHT-JUSTIFIED .

        IF p_input IS INITIAL .
          p_output = space .
          RETURN.
        ENDIF .

        CONDENSE buffer_1 .

        CONCATENATE '+' buffer_1 '%' INTO buffer_1 .

        IF p_input LT 0 .
          WRITE '-' TO buffer_1+0(1) .
        ENDIF .

        CONDENSE buffer_1 .

        p_output = buffer_1 .

      ENDFORM.                    " CONVERSION_YTS01

      The result:

      /wp-content/uploads/2014/03/2014_03_18_06h41_20_412599.png

      Author's profile photo Joachim Rees
      Joachim Rees

      In the past I had a use case for IF 1 = 2 :
      -> make code unreachable. Unless you jump to it in the debugger.
      This works towards the person actually execution the code 1. Has authorization 2. (hopefully) has knowledge.
      (There should be no need for such a thing - but sometime, there is!

      Example:

      ZZ_TEMP_REPORT_CORRECT_XY
      
      "Know what you are doing!!
      IF 1 = 2.
      "jump the wall!
      
      perform HARD_UPDATE_DATA_TO_FIX_THINGS.
      write: "done!".
      else.
      write: "Nothing was done.".
      ENDIF.