Search

@yogthos when the CSS file is missing

Nah, this is yanderedev

@tetris11 @Aedis More like:

    
isEven() {    case "$1" in        *[02468]) return 0;;        *) return 1;;    esac;}

  

(If all the line breaks are gone from this code snippet, blame Lemmy. It looks fine here.)

The difference is that (( is a "compound command", similar to [[ (evaluate conditional expression), while $(( )) is "aritmetic expansion". They behave in almost exactly the same way but are used in different contexts - the former uses "exit codes" while the latter returns a string, so the former would be used where you would expect a command, while the latter would be used where you expect an expression. A function definition expects a compound command, so that's what we use. If we used $(( )) directly, it wouldn't parse:

    
$ even() $((($1+1)&1))
bash: syntax error near unexpected token `$((($1+1)&1))'

  

We would have to do something like

    
even() { return $(($1&1)); }

  

(notice how this is inverted from the (( case - (( actually inverts 0 -> exit code 1 and any other result to exit code 0, so that it matches bash semantics of exit code 0 being "true" and any other exit code being "false" when used in a conditional)

But this is a bit easier to understand and as such wouldn't cut it, as any seasoned bash expert will tell you. Can't be irreplaceable if anyone on your team can read your code, right?

I can't think of many use-cases for ((. I guess if you wanted to do some arithmetic in a conditional?

 bash

    
if (( $1&1 )); then echo "odd!"; else echo "even!"; fi

  

But this is pretty contrived. This is probably the reason you've never heard of it.

This (( vs. $(( )) thing is similar to how there is ( compound command (run in a subshell), and $( ) (command substitution). You can actually use the former to define a function too (as it's a compound command):

 bash

    
real_exit() { exit 1; }
fake_exit() ( exit 1 )

  

Calling real_exit will exit from the shell, while calling fake_exit will do nothing as the exit 1 command is executed in a separate subshell. Notice how you can also do the same in a command substition (because it runs in a subshell too):

 bash

    
echo $(echo foo; exit 1)

  

Will run successfully and output foo.

(( being paired with $((, and ( with $(, is mostly just a syntactic rhyme rather than anything consistent. E.g. { and ${ do very different things, and $[[ just doesn't exist.

Bash is awful. It's funny but also sad that we're stuck with it.

    
def even(n: int) -> bool:
    code = ""
    for i in range(0, n+1, 2):
        code += f"if {n} == {i}:\n out = True\n"
        j = i+1
        code += f"if {n} == {j}:\n out = False\n"
    local_vars = {}
    exec(code, {}, local_vars)
    return local_vars["out"]


  

scalable version

@sirico@feddit.uk

    
private bool isEven(int number){
        bool result = true;
        while (number > 0){
            number = number - 1;
            if (result == true)
                result = false;
            else
                result = true;
        }
        return result;
    }

  

(P.S.: Only works for positive numbers)

I'll join in

    
const isEven = (n) 
  => !["1","3","5","7","9"]
    .includes(Math.round(n).toString().slice(-1)) 

  

you'd end up using modulus and move on quickly.

But where's the fun in that?

There are so many better for obfuscation ways of checking for oddness!

    
(a & 1) > 0
a.toString()[a.toString().length()-1] - '1' == 0
iseven(a)?(1==0):(1!=0)


  

@tetris11 @Aedis

Never touch my codebase please

I prefer good ole regex test of a binary num

 bash

    
function isEven(number){
   binary=$(echo "obase=2; $number" | bc)
   if [ "${binary:-1}" = "1" ]; then
         return 255
   fi
   return 0
}

  

I prefer to ride my seals into battle

In a world where this needs to be solved with TDD there are a few approaches.

If you were pair programming, your pair could always create a new failing test with the current implementation.

Realistically I would want tests for the interesting cases like zero, positive even, negative even, and the odds.

Another approach would be property based testing. One could create sequence generators that randomly generate even or odd numbers and tests the function with those known sequences. I don't typically use this approach, but it would be a good fit here.

Really in pair programming, your pair would get sick of your crap if you were writing code like this, remind you of all the work you need to get done this week, and you'd end up using modulus and move on quickly.

The Daily WTF

Wait?

Kinda touches on the psychological aspect of this

Still have stuff on Jdk 7 :D

[ in walks fully-released-bug-driven developer ]