I'd disagree strongly with the recommendation to break expressions after... 
it makes you have to look at the end of the line above to see
if a line is part of another expression.
I think it is much better to simply get used to wrapping things with ( ), 
and editors show you nicely where the beginning of the expression is,
even without a specific Julia mode...

On Sunday, May 31, 2015 at 9:28:56 AM UTC+2, [email protected] wrote:
>
>
>
> On Sunday, May 31, 2015 at 3:13:47 PM UTC+10, Alex Ames wrote:
>>
>> I lost multiple days attempting to pin down this behavior. I had 
>> something along the lines of
>> x = a + b
>>      + c
>> It's not clear to me why the second line is a valid expression. At the 
>> very least, it would be nice for lint to catch these, or an optional `...` 
>> line-continuation operator.
>>
>
> The + operator is a valid unary prefix operator, so +c is a perfectly 
> reasonable expression, see 
> http://julia.readthedocs.org/en/latest/manual/mathematical-operations/#arithmetic-operators
> .
>
> Lint might want to warn about unused expressions, but that won't catch 
> examples like the one Scott showed where the expression result is the 
> function return.
>
> Lint might also want to warn about effect free expressions like +c.
>
> But that will still only find a small subset of this class of possible 
> problems and will likely have a high false positive rate so it will be 
> annoying.
>
> The best is to simply develop the habit of breaking expressions *after* 
> operators:
>
> x = a + b +
>           c
>
> Cheers
> Lex
>  
>
>>
>> On Saturday, May 30, 2015 at 11:21:18 AM UTC-5, Gabriel Mihalache wrote:
>>>
>>> Once you spend a few days tracking down a bug due to this, you never 
>>> forget. The idea would be to find a way to save people from this experience.
>>>
>>> Some lines are naturally long because e.g. the equation is long or 
>>> because you prefer long, informative variable names. You can always use 
>>> variables for parts of the expression but then that just feels like working 
>>> around poor language features/design.
>>>
>>

Reply via email to