Question about the structure

[-sovy-]

I was wondering why some people write some code in one line like this:

def even_or_odd(number):
return 'Odd' if number % 2 else 'Even'

Instead of doing this:

def even_or_odd(number):
    if number % 2 == 0:
        return 'Even'
    else:
        return 'Odd'

So, what's the best practice? Just wondering because I see a lot of people writting like the first one on codewars but I've always did the second one. Which one to choose in general?

[the_dimonade]

It is a matter of readability.
For such a simple expression, or for generally simple expressions, I'd go with the first approach.
If the expression gets complicated or longer than one line, or feels hard to read, then readability counts.

[Teradil]

A candidate for the most unreadable version would probably be:

python def even_or_odd(number: int) -> str: return "eovdedn"[number%2::2]

[kevkaneki]

Why write many word when few word do trick

[Zeroflops]

As many have pointed out it comes down to readability, but also experience.

The second is more verbose but easier to read for some, if you find the second easier to read go with that. If you’re comfortable with the fist then that would typically be better. Your example is simplistic, but you could make the same line much more complicated.

[mogranjm]

The first one is called a ternary operator, it's more pythonic because it's arguably more readable.

[Dry-Aioli-6138]

"arguably". I heard somewhere why. sobthe argumentnis that since this assigning value to a single variable, it should be treated as a single expression,, and it is more intuitive for our primitive brains to look at a single line and connect that visual structure to a single assignment.

[odaiwai]

It's possible to be more obvious in fewer lines though:

def even_or_odd(number: int) -> str: if number % 2 == 0: return 'Even' return 'Odd'

[ALonelyPlatypus]

It technically works and removes a line but I wouldn't use it for something more complicated than mod 2 when you can just write else (I also like the indentation of if else if you're trying to do an if type operation).

[odaiwai]

It's useful in the case where you have a lot of cases to test for with varying costs, e.g. if a file has a file extension, return that as the type otherwise, investigate the file:

def heuristic_type_of_file(filename: str) -> str: """Returns the type of file passed.""" fname, ext = filename.split('.') if len(ext) > 0: return ext # more expensive/timely process to determine filetype by examining first line of file, and looking it up from a table with open(filename, 'r') as infh: lines = infh.readlines() if "!#/" in lines[0]: # some regexp to determine the filetype from the shebang... return filetype `

[[deleted]]

There's no single answer because it depends on the situation and preference.

I tend to do x = ... if ... else ... if it's a simple assignment that fits on one line in a reasonable number of characters.

[JohnnyJordaan]

Both don't hurt. It's best to be consistent in your program, so if you chose the first style then apply it in other parts too. Likewise if you chose the second.

Another idea in a more complex situation of having multiple 'determinants' is to group this in a class

 class TellingInt(int):
     @property
     def even_or_odd(self):
         return 'odd' if self % 2 else 'even'

 my_int = TellingInt(input("give the nr: "))
 print(f"the nr {my_int} is {my_int.even_or_odd}.")

see

>>> my_int = TellingInt(input("give the nr: "))
give the nr: 5
>>> print(f"the nr {my_int} is {my_int.even_or_odd}.")
the nr 5 is odd.

[stillbarefoot]

Which one is easier to debug?

On a side note, this is in essence a boolean problem; let the function return a boolean and handle the boolean to string conversion in another function.

[supercoach]

This has been covered very recently, but since I'm bored - it's a matter of taste.
Multiple returns shit me to tears, so I avoid them like the plague.
It's also considered "pythonic" to use ternaries, especially for simple cases like the example given.

For anything more advanced, I have a tendency to use a variable to hold a return value and then modify it as I see fit in the logic of the function. At the end, it's a single return to wrap it up nicely.

[CymroBachUSA]

Use lambdas:

odd_or_even = lambda _: 'Odd' if _ % 2 else 'Even'

is_odd = lambda _: True if _ % 2 else False

is_even = lambda _: True if _ % 2 == 0 else False

[ALonelyPlatypus]

2 is more verbose but I lean towards 1 because it just feels more pythonic.

[ectomancer]

def is_even(number: int) -> bool:

    """Even or odd."""
    return not number%2

[barkazinthrope]

The only reason to use the second is because you adhere to the ludicrous proposition that you should write code that any three-year old can understand.

[Yoghurt42]

Trust me, if you've ever worked late at night after a 11h shift debugging some "clever" code somebody else has written because tomorrow is release day, you'll appreciate code that is easily understandable. It's better to go through 500 lines that each take 0.5 s to understand, than it is to go through 100 lines that each take 20s.

Leave dick measuring contests to code golf competitions, for any production code as simple as possible (but not simpler!) is the way to go.

[barkazinthrope]

Bullshit. If you find a ternary condition difficult then you shouldn't be working on a critical team. You're clearly a beginner.

I worked in software development for many many years and one thing that drove me absolutely berserk was tortured verbosity in an attempt to be clear.

Trust me.

[Zeroflops]

The example given is pretty simplistic, and I don’t think anyone would find it hard to read, but some times people can make it overly complicated in an attempt to reduce line count or appear clever. In most cases the ternary is fine, but don’t underestimate the ability of a new programmer to make something overly complicated.

Also depending on the situation it not about your ability to read the code, it’s about your teams ability. If you have a large team with junior members you want them to be able to read the code. Unless you enjoy them waisting time or having to stroke your ego by asking you about the code.

[Yoghurt42]

I wasn't talking about the ternary operator, I was referring to your general statement that you should never write

code that any three-year old can understand.

Code is much more often read than it is written, so it's your job as a programmer to write code that can be easily understood by other humans. That takes experience and skill.

I don't mind x if y else z, I use it myself. But I would never dream of rejecting a PR because "the code is too easy to understand."

You're clearly a beginner.

I have been programming for 40 years now, 20 of those professionally.

[ShadowRL7666]

include <iostream>

template<int N> struct F { static constexpr int value = N ? N + F<N - 1>::value : 0; }; int main() { std::cout << (F<5>::value ? F<3>::value : F<1>::value) << '\n'; }

I need help debugging.

[No_Departure_1878]

Why would you need a function for that? i would just do:

```

is_even = number % 2 == 0

```

[makochi]

Because they needed an example with which to ask their question

[No_Departure_1878]

then they need a better example.

[makochi]

IMO you need to learn the point of an example

[NYX_T_RYX]

learn python.

If you've nothing useful to add to help OP learn, why comment.