5 ms·

A nice example of this is yoda expressions in, say Java. The initial reasoning for them was to prevent accidental assignment, since a C/C++ compiler will compl

A nice example of this is yoda expressions in, say Java. The initial reasoning for them was to prevent accidental assignment, since a C/C++ compiler will complain on this: if (null = x) but not on this: if (x = null) In Java, neither is allowed, so the whole yoda construct is almost pointless. The exception is boolean assignment which does benefit from this idiom, but the loss in readability is a trade off to consider. In any case, I suspect most uses of this construct in languages like Java fall into the "superstition" category, where the people using it aren't really considering why.

Peaker 12y ago
A lot of us find Yoda conditions easier to read: if(0 == very_long_function_name_here(param1, param2)) { Tells me a lot after I've read a little of the line, whereas: if(very_long_function_name_here(param1, param2) == 0) { Makes the == 0 part easy to miss, and buried behind a lot of clutter.
- mrspeaker 12y ago
  eh, you just end up having to parse if (VERY_LONG_AND_SPECIFIC_ENUM_NAME_HERE == func(param1)) { } Makes the function called easy to miss and buried behind a lot of clutter ;)
  - Peaker 12y ago
    That's why my rule is shorter first :-)
- depsypher 12y ago
  Re: "buried behind a lot of clutter" If your code has a lot of clutter it's usually telling you something about your design. For readability a better way of handling it might be for the function could return a boolean instead of an int: if (is_valid(param1, param2)) { self documenting code and all that.
  - Peaker 12y ago
    You're assuming the information being returned is a boolean. As a static typing fanatic, I would not return an int to indicate a boolean result. if (0 == number_of_students(context, classroom))
- klibertp 12y ago
  Why would you ever have a function with a name that long in the first place? Also, there are many more ways of dealing with readability: try different formatting and indentation rules, wrap lines manually where you think it makes sense and so on. As for your example, even the lowly C let's you do something like this: int (*short_name)(int) = &veeeeery_long_and_ugly_and_unnecessary_function; if(short_name(1) == 2) { printf("\n\nYay, it worked!"); } which completely solves the problem, no matter the order of compared objects. I'm not sure, but I suspect things like this are being optimized away by the compiler anyway, which would mean that you can use it anywhere you want without worrying about costs of indirection. In higher level, modern languages you have even more, much more sophisticated tools for doing this kind of things.
  - ericb 12y ago
    Explicit function naming requires slightly longer function names, but you can actually read a program and get a sense of what is happening. Give me long function names over short ones any day. In my book, 5 words is a little long, but not out of bounds.
    - klibertp 12y ago
      If you take a closer look at my example you'll see that the long name is there of course, it's still very close to the point where it's used. It's only aliased for a moment in this single section of code and because of lexical scoping there's no danger of name collision. Of course, doing this in a global namespace makes no sense. How long identifiers are acceptable depends on a language. With languages without namespacing or modules you obviously have to use some naming convention so that there are no name conflicts and this makes your names longer. I'd say 5 words is ok in this case. But I'm not arguing against long names of things: on the contrary, I like having names as descriptive as possible. OTOH, too long names are also bad, because they make the code less readable and harder to work with. Like almost always it's a matter of balance: you need to know when to stop adding words to a name. I think that "name is too long when it starts making other names in the same line much harder to spot" is a good heuristic for this.
Lewton 12y ago
Yoda expressions are still useful in Java when we're talking strings. someString.equals("someString") vs "someString".equals(someString)

Peaker 12y ago

A lot of us find Yoda conditions easier to read: if(0 == very_long_function_name_here(param1, param2)) { Tells me a lot after I've read a little of the line, whereas: if(very_long_function_name_here(param1, param2) == 0) { Makes the == 0 part easy to miss, and buried behind a lot of clutter.

mrspeaker 12y ago
eh, you just end up having to parse if (VERY_LONG_AND_SPECIFIC_ENUM_NAME_HERE == func(param1)) { } Makes the function called easy to miss and buried behind a lot of clutter ;)
- Peaker 12y ago
  That's why my rule is shorter first :-)
depsypher 12y ago
Re: "buried behind a lot of clutter" If your code has a lot of clutter it's usually telling you something about your design. For readability a better way of handling it might be for the function could return a boolean instead of an int: if (is_valid(param1, param2)) { self documenting code and all that.
- Peaker 12y ago
  You're assuming the information being returned is a boolean. As a static typing fanatic, I would not return an int to indicate a boolean result. if (0 == number_of_students(context, classroom))
klibertp 12y ago
Why would you ever have a function with a name that long in the first place? Also, there are many more ways of dealing with readability: try different formatting and indentation rules, wrap lines manually where you think it makes sense and so on. As for your example, even the lowly C let's you do something like this: int (*short_name)(int) = &veeeeery_long_and_ugly_and_unnecessary_function; if(short_name(1) == 2) { printf("\n\nYay, it worked!"); } which completely solves the problem, no matter the order of compared objects. I'm not sure, but I suspect things like this are being optimized away by the compiler anyway, which would mean that you can use it anywhere you want without worrying about costs of indirection. In higher level, modern languages you have even more, much more sophisticated tools for doing this kind of things.
- ericb 12y ago
  Explicit function naming requires slightly longer function names, but you can actually read a program and get a sense of what is happening. Give me long function names over short ones any day. In my book, 5 words is a little long, but not out of bounds.
  - klibertp 12y ago
    If you take a closer look at my example you'll see that the long name is there of course, it's still very close to the point where it's used. It's only aliased for a moment in this single section of code and because of lexical scoping there's no danger of name collision. Of course, doing this in a global namespace makes no sense. How long identifiers are acceptable depends on a language. With languages without namespacing or modules you obviously have to use some naming convention so that there are no name conflicts and this makes your names longer. I'd say 5 words is ok in this case. But I'm not arguing against long names of things: on the contrary, I like having names as descriptive as possible. OTOH, too long names are also bad, because they make the code less readable and harder to work with. Like almost always it's a matter of balance: you need to know when to stop adding words to a name. I think that "name is too long when it starts making other names in the same line much harder to spot" is a good heuristic for this.

Lewton 12y ago

Yoda expressions are still useful in Java when we're talking strings. someString.equals("someString") vs "someString".equals(someString)