4 ms·

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

by 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.
    - Peaker 12y ago
      The alias is just adding confusion. If I see such an alias in code, I would wonder where else that function is used in the function, and be confused that it isn't. Not to mention it becomes more verbose once you make that alias a const ptr (which we do on all of our local variables).
      - klibertp 12y ago
        > The alias is just adding confusion. If I see such an alias in code, I would wonder where else that function is used in the function, and be confused that it isn't You'd be confused once or twice, then you'd learn the technique and you'd stop being confused. Every code pattern was unfamiliar to you at first. And confusing, until you internalized it. It's unrealistic to assume that you can ever stop learning new patterns - try switching to another language and you immediately have dozens of unfamiliar, confusing patterns to learn. (it gets better after a certain amount of languages known (like https://klibert.pl/articles/programming_langs.html https://klibert.pl/articles/programming_langs.html) because you start noticing meta-patterns) My C is rather rusty nowadays and using function pointer here may not be the best option, but as someone else said, there are other language tools for doing this kind of aliasing, like #define. I'd go for function pointer probably, because it reveals not only a name, but also a type of function and it's guaranteed not to escape the current scope (unless explicitly returned) while #define has no knowledge of scopes at all. In languages which support real macros, and preferably lexically scoped macros (like Racket) I'd use those. In languages with closures and first-class functions I'd probably do it in yet another way. But in general, if I find myself working with a name so long that it makes it hard to spot other names on the same line I will alias it locally. Have you read http://shop.oreilly.com/product/9780596802301.do http://shop.oreilly.com/product/9780596802301.do ? It's a good, short book on the topic and it discusses exactly this issue at length in one of the chapters.

by Peaker 12y ago

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.
  - Peaker 12y ago
    The alias is just adding confusion. If I see such an alias in code, I would wonder where else that function is used in the function, and be confused that it isn't. Not to mention it becomes more verbose once you make that alias a const ptr (which we do on all of our local variables).
    - klibertp 12y ago
      > The alias is just adding confusion. If I see such an alias in code, I would wonder where else that function is used in the function, and be confused that it isn't You'd be confused once or twice, then you'd learn the technique and you'd stop being confused. Every code pattern was unfamiliar to you at first. And confusing, until you internalized it. It's unrealistic to assume that you can ever stop learning new patterns - try switching to another language and you immediately have dozens of unfamiliar, confusing patterns to learn. (it gets better after a certain amount of languages known (like https://klibert.pl/articles/programming_langs.html https://klibert.pl/articles/programming_langs.html) because you start noticing meta-patterns) My C is rather rusty nowadays and using function pointer here may not be the best option, but as someone else said, there are other language tools for doing this kind of aliasing, like #define. I'd go for function pointer probably, because it reveals not only a name, but also a type of function and it's guaranteed not to escape the current scope (unless explicitly returned) while #define has no knowledge of scopes at all. In languages which support real macros, and preferably lexically scoped macros (like Racket) I'd use those. In languages with closures and first-class functions I'd probably do it in yet another way. But in general, if I find myself working with a name so long that it makes it hard to spot other names on the same line I will alias it locally. Have you read http://shop.oreilly.com/product/9780596802301.do http://shop.oreilly.com/product/9780596802301.do ? It's a good, short book on the topic and it discusses exactly this issue at length in one of the chapters.