flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: [FlexJS] trace statements in SDK code
Date Tue, 23 May 2017 20:05:20 GMT
+1 for that

Am 23.05.17, 18:36 schrieb "Alex Harui" <aharui@adobe.com.INVALID>:

    It might be as simple as not setting @export on Language.utils.trace.  The
    optimizer might then figure it out without having to add DEBUG defines.
    Maybe something to investigate and discuss further after we get this
    release out?
    On 5/23/17, 8:03 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:
    >As far as I understood it, right now debug is the only option as all
    >working on larger applications can’t use the release build.
    >I think trace statements should eventually be wrapped by a “DEBUG” define
    >to allow including them and have them excluded by default.
    >We are talking about efficiency of produced code … for me the traces are
    >an equally anti-pattern as are the System.out.printline statelents in the
    >I wouldn’t call it a blocker for the next release, but definitely one for
    >Am 23.05.17, 16:55 schrieb "Alex Harui" <aharui@adobe.com.INVALID>:
    >    Interesting topic.  Is this something that folks think is important
    >    this release?
    >    I would not want to have a "no trace statements" policy.  IMO trace
    >    statements are a useful tool when used appropriately.  As long as the
    >    chain can remove trace statements in production code, that should be
    >    we need.  But I think it is too late to be dealing with this for this
    >    release.
    >    I use trace statements when I'm not sure about some code condition and
    >    when there is some tricky thing that can be debugged by examining a
    >log of
    >    output.  Throwing an exception stops execution and it cannot be easily
    >    restarted.  A trace statement says "hey, I think the code didn't
    >    this condition" but allows execution to continue.
    >    The only "rule" we had in regular Flex was that trace statements
    >    pollute your output with tons of stuff.  The checkintests checked for
    >    unexpected trace output in the main code paths of the components.
    >    trace statements were commented out or behind logic that kept them off
    >    until you needed them.
    >    My 2 cents,
    >    -Alex
    >    On 5/23/17, 1:46 AM, "Justin Mclean" <justin@classsoftware.com> wrote:
    >    >Hi,
    >    >
    >    >I’ve noticed in a few places there are some unnecessary trace
    >    >in the SDK. Like for instance here [1].
    >    >
    >    >I’m thinking we probably shouldn’t have trace statements in
    >    >code. Sonar cube flags it as an issue. [2] Anyone think otherwise?
    >    >
    >    >On the JS side these are only omitted when goog.DEBUG is defined but
    >    >still be a little expensive at it calls slice before doing that.
    >    >
    >    >Thanks,
    >    >Justin
    >    >
    >    >1. 
    >    >24%3D&reserved=0
    >    >2. 
    >    >8&sdata=agE57nLohxBpNqBMz9pVKKNTOeB6qRxWnu%2FMBM4bpaw%3D&reserved=0

View raw message