Use of Correct indentation - Eclipse - Forum - OpenEdge General - Progress Community

Use of Correct indentation - Eclipse

 Forum

Use of Correct indentation - Eclipse

This question is not answered

I am a big fan of using correct case, expand keywords and indentation, but for the Indentation I would love to have it in another way, is that possible?

I get:

  FIND FIRST hendelseRSTO NO-LOCK WHERE hendelseRSTO.ans#    = hendelse.ans#
    AND hendelseRSTO.son_aar = hendelse.son_aar
    AND hendelseRSTO.son_lnr = hendelse.son_lnr
    AND hendelseRSTO.Jour_lnr = hendelse.hend_lnr
    AND NOT hendelse.Slettet NO-ERROR.

I would love:

  FIND FIRST hendelseRSTO NO-LOCK WHERE hendelseRSTO.ans#    = hendelse.ans#
                                                                       AND hendelseRSTO.son_aar = hendelse.son_aar
                                                                       AND hendelseRSTO.son_lnr = hendelse.son_lnr
                                                                      AND hendelseRSTO.Jour_lnr = hendelse.hend_lnr
                                                                      AND NOT hendelse.Slettet

                                                                 NO-ERROR.

Is it possible ?

All Replies
  • You can get hold of an old Progress program called beauty.p and modify it to indent anyway you like.

    Personally I would indent like this:

    FIND FIRST hendelseRSTO  WHERE

       hendelseRSTO.ans#       = hendelse.ans# AND

       hendelseRSTO.son_aar  = hendelse.son_aar AND

       hendelseRSTO.son_lnr   = hendelse.son_lnr AND

       hendelseRSTO.Jour_lnr  = hendelse.hend_lnr AND

      NOT hendelse.Slettet

      NO-LOCK NO-ERROR.

  • religious war time! :-)

    obviously you want:

    FIND FIRST hendelseRSTO

      WHERE hendelseRSTO.ans#    = hendelse.ans#

      AND hendelseRSTO.son_aar = hendelse.son_aar

      AND hendelseRSTO.son_lnr = hendelse.son_lnr

      AND hendelseRSTO.Jour_lnr = hendelse.hend_lnr

      AND NOT hendelse.Slettet

    NO-LOCK NO-ERROR.

    1. an indent should only ever be ONE tab

    2. AND / OR as query predicates determine the query - an AND at the back is like a Borat NOT joke.

  • Stefan, I have to agree with you here :-)  but How to get it like that in eclipse?

  • Hi,
     
    At present we don’t have any option to customize code Indentation from Developer Studio. We are actively picking highest voted ideas from communities to improve Developer Studio experience. Please submit an Idea in communities if you really want to have this feature in Progress Developer Studio.
     
    Hope this helps,
    Sanjeev
     
  • My way is close to Stefan's but with NO-LOCK as early as possible

    I wish it would be possible to align stuff to the right side of the WHERE word and the equal sign like in for an ASSIGN statement

       Perhaps I should revise my standard to dedicate a last line for the NO-ERROR

    FIND FIRST hendelseRSTO NO-LOCK

        WHERE hendelseRSTO.ans#     = hendelse.ans#

        AND   hendelseRSTO.son_aar  = hendelse.son_aar

        AND   hendelseRSTO.son_lnr  = hendelse.son_lnr

        AND   hendelseRSTO.Jour_lnr = hendelse.hend_lnr

        AND   hendelse.Slettet      = FALSE NO-ERROR.

    By the way, the following is bad for performance because progress cannot pickup an index for this:

     AND NOT hendelse.Slettet

    people should do this:

     AND hendelse.Slettet = FALSE

    Kind regards

    /S

  • hendelse.Slettet = FALSE is not the same as NOT hendelse.Slettet

  • Technically you are right, Scott, but anyone who relies on the unknown value of a logical deserves to be shot ;) M Lacroix is correct in saying that using equality is more efficient than using NOT though.

    All examples above are incorrect because of the 'find first' though... ;)

  • @james: correct. Didn't Tom suggest to change 'FIND FIRST' to 'FIND ANY'?

  • I use find first myself but I've forgotten why! I've been using it for nearly 30 years.

    In the back of my head I've a half-notion of it being quicker.

    I couldn't justify it now but it hasn't bitten me on the bum either in all that time.

  • find first is fine if you genuinely couldn't care which record you get if there are multiple. I suppose it's fine if you're searching on a unique index (although that might change in future). The point of find without the first is that if you have multiple results satisfying the where clause you handle that and inform the user that something is wrong rather than making an assumption. I always used find first before, and likewise was never bitten. BUT, having changed my ways to omit the first I have encountered a number of situations where I /could/ have been bitten.

  • OK, but should I use a FOR FIRST instead?

    Sendt fra min iPhone

    15. feb. 2018 kl. 11:03 skrev James Palmer <bounce-jdpjamesp@community.progress.com>:

    Update from Progress Community
    <4U3LU3OEGM9Z-jpg_2D00_70x70x2-jpg>
    James Palmer

    find first is fine if you genuinely couldn't care which record you get if there are multiple. I suppose it's fine if you're searching on a unique index (although that might change in future). The point of find without the first is that if you have multiple results satisfying the where clause you handle that and inform the user that something is wrong rather than making an assumption. I always used find first before, and likewise was never bitten. BUT, having changed my ways to omit the first I have encountered a number of situations where I /could/ have been bitten.

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

  • For first will still mask the fact there are multiple results to a query. And is, in fact, even harder to mitigate against. find customer where... will not have a record available and you can test for ambiguous if none is available. You immediately know either your query is wrong, or your data is wrong.

  • The advantage of FOR FIRST over FIND FIRST is the ability to use the FIELDS phrase.

    But as James says, probably best to omit the FIRST.

  • We probably need a thread devoted to the evils of FIRST.

    999 times out of 10 it is being used without any thought by a programmer who either thinks it is required because they have never seen a FIND without it or because they once thought they heard that it was faster and faster is always better.

    For the record: FIND FIRST is only faster if it is also wrong.  If FIND FIRST makes your code faster it is because you do not have a unique index to go with your WHERE clause.  If you do not also have a loop and some FIND NEXT statements then you are ignoring the rest of the result set.  That means that you are violating 3rd normal form.  Either you are saying that the  FIRST record has a magical attribute that the 2nd, 3rd etc do not or you have redundant data.  If OTOH you do have NEXT statements then one has to wonder why you are not using FOR EACH?

    The overwhelming majority of FIND statements do not need and do not benefit from FIRST.

    Some FIND FIRST statements are subtle bugs that will probably never be tracked down and will intermittently bother users forever.

    A small number of FIND FIRST bugs are catastrophic.  But still very hard to uncover.  Especially when nearly every FIND has a specious FIRST glued onto to it.

    FIND FIRST everywhere is a bad coding habit.  Don't copy bad code.

    --
    Tom Bascom
    tom@wss.com

  • Thanks James, I will then stop using find FIRST &#128522; and it seems like I have to stop using …. NOT table.myLogicalField as well and continue with …. Table.myLogicalField = FALSE
     
    //Geir Otto