6 ms·

I always work with a few developers that complain about my long variable names and aversion to certain shortcuts like ternary operators. They don't understand

I always work with a few developers that complain about my long variable names and aversion to certain shortcuts like ternary operators. They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. Some of their code is so "clever" that I've refactored the line with 7 method calls just to understand what the hell is going on. Lambdas and fluent syntax make me quiver with fear. In the wrong hands they let you do unspeakable things

kbenson 10y ago
> aversion to certain shortcuts like ternary operators. > They don't understand that unclear code is probably the number one cause of technical debt. At the same time, verbosity can have an obfuscation quality all of its own. For simple assignment, I find a ternary operator very clear and concise, and much preferable to a 5-9 line (depending on style) if/else for a simple assignment. It also might keep you from using the single statement version of if/else if your language supports it, and that's probably justification in itself given how many problems that's caused in the past. Specifically, I think: usefulMetric = wantComplexCalc ? complexCalc(foo) : simpleCalc(foo); is preferable to: if ( wantComplexCalc ) { usefulMetric = complexCalc(foo) } else { usefulMetric = simpleCalc(foo) } even if only because it doesn't obscure intent with what is essentially boilerplate.
- ludicast 10y ago
  Agreed, plus obviously your "if" statement doesn't do the assignment to usefulMetric. One more way the ternary wins (along with functional languages that use "if"s as expressions).
  - kbenson 10y ago
    D'oh! Fixed. Thanks. :)
  - LgWoodenBadger 10y ago
    a "final" declaration (in Java) would have pointed that out through a compilation error ;)
- pacala 10y ago
  OP is about Scala, where you write directly what you mean, without special operators: val usefulMetric = if (wantComplexCalc) { complexCalc(foo) } else { simpleCalc(foo) }
  - kbenson 10y ago
    Well, that's only "directly what you mean, without special operators" if you come from a C style procedural background and have already internalized all the special operators you've included there, such as parenthesis and braces. Sure, that's most people, but that doesn't mean they aren't operators.
  - amyjess 10y ago
    I'd rather have Python's way of doing it, which plays with the order for the sake of readability: useful_metric = complex_calc(foo) if want_complex_calc else simple_calc(foo)
    - christophilus 10y ago
      Ruby has something similar, and I can't stand it. I think the conditional is the most important item in the phrase, and it's shoved off to the right. If you lead with the conditional, it becomes immediately apparent that the assignment is predicated on the result of a branch.
      - kbenson 10y ago
        Ruby (and Python) likely get that from Perl, which has post conditionals, but with specific qualities to prevent them from too much abuse, and which also prevents them from being used in the way presented here (which is why I didn't trot them out earlier, as much as I was tempted by the "you write what you mean" line). The limitations are that there is no else branch, and it only applies to a single statement, so you can't have a block executed with a post conditional. It leads to usage like so: die "Invalid param: please enter a positive number" unless $param1 > 0; $param2 = 0 unless defined $param2; return undef if $param1 and not $param2; my $foo = 1 if $bar; # This unfortunately creates a closure around $foo and is a big source of bugs. As much flak as Perl gets, quite a lot of thought went into making it flow similar to how people think and talk (which is no surprise if you know Larry Wall is a linguist by training). There were some missteps, but it was very early in this area, so that's expected.
- jiaweihli 10y ago
  Unfortunately, ternary operators eventually end up like this due to refactoring blindness: usefulMetric = wantComplexCalc ? (complexity > 40 ? superComplexCalc(foo) : regularComplexCalc(foo)) : simpleCalc(foo);
  - kbenson 10y ago
    At some point you have to rely on policy and not language constraints. I submit that no language is constrained enough to protect against refactoring stupidity while also being flexible enough to be useful to the average programmer on the average project. If not ternary if, it will be something else. So, do you throw out every alternative method to accomplish the same thing, or do you put policies in place to keep the code sane, such as "no chained ternary operators are allowed" ?
    - jiaweihli 10y ago
      In all honesty, I prefer having rules that have no special-case 'unless' issues. It's too much effort/trouble to remember all the cases where things don't work. I'm a good engineer but a terrible compiler. I believe part of learning a new library/framework/language is to limit yourself to a certain subset of the API offered. After working with Ruby (the language) and Javascript (the ecosystem), I feel like that's the only way to preserve your sanity and productivity. I don't need to know 4 different ways of creating a lambda in Ruby, selecting 1 that can express the other 4 is good enough. --- In this case, the rule would be no ternary operators, since they work well unless you nest them or unless you make them long/complicated. Other examples - You don't need to wrap if conditions unless you have a multi-line body: if (myCondition) x = 42; y = 23; Early returns simplify short circuiting logic unless your function becomes too long: if (myVariableAtBeginningOfFunction) { return true; } ... // 2 screens later ... if (x == 42) { return false; // why am I not getting false?! } Using a variable as a conditional in javascript to test against undefined works well unless the value can be falsy: if (person.isStudent) { showSchool(); } if (person.age) { showBirthCertificate(); // what if age is 0? }
jghn 10y ago
One person's clever is another person's clear and vice versa. These conversations are pointless as there is no objective truth on code clarity
- deleted 10y ago
  [deleted]
- edblarney 10y ago
  I'm not sure if this is true. Scala provides a whole new level of ability for people to write code that can be meaningless to others. It really is quite different.
  - jghn 10y ago
    And that sort of scala code is extremely meaningful to other folks, which captures my point. I see scala code all the time that would give me an instant headache but there are people who would find that more readable. To each their own, the is to work with people who are at least somewhat aligned to your sensibilities.
    - edblarney 10y ago
      Fair enough - but I'll offer this: + Any decent developer can read decent code in Java or whatever normal language and get along just fine. + Only a few people can deal with Scala - and even fewer if there's a log of specific project Scala weirdness used in a particular program. So sure - among a narrower set of 'Scala friendly' developers, and possibly within that even narrower set of people familiar with the 'Scala weirdness' of a particular project - those people can 'get along fine'. The problem is that this can be a pretty narrow set of people. Scala would have to represent a pretty big advantage to propose it's general weirdness as something to bother with. I don't think it does - hence the 'de-adoption' of various entities. My gut tells me it's past the threshold - the 'extra power' offered Scala just isn't quite worth it's weirdness for most things, and so most devs won't learn it ... and so then it becomes less valuable from a business perspective. It's possible we may have it peak Scala. We'll see I guess.
deleted 10y ago
[deleted]
true_religion 10y ago
> They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. True, but once get into the length of variable names in iOS and Android development, you're in a whole new territory. 38 character variables have no place in life. And extreme's like: outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch This is 149 character.
- justicezyx 10y ago
  The thing is that, shorter names do not help in this case either...
ivanhoe 10y ago
IMHO it's a wrong approach. Every programming language, just like the spoken ones, has it's common shortcuts and idioms. The fact that they're commonly accepted and used is what makes them easy to understand. Your brain learns to recognize them quickly, often much quicker then the long version. With newbies and programmers who switched from other languages problem is that their brain is just not yet trained to do that efficiently. Instead of investing some time into getting used to the peculiarities of the language that they use, they then try to avoid them as "complicated". By lowering a bar too low, and avoiding using these patterns all together, you encourage people to never train their brains to recognize them effortlessly. And by definition of common patterns, they're, well, common, and they'll keep running into them all of the time. Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through. I'm not saying that one should go crazy with one-liners or uncommon patterns, but things like ternary operators used with reasonably short expressions in a single line of code are totally valid and should be readable to any average dev out there.
- majkinetor 10y ago
  Great comment. Particularly > Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through. I stopped contributing to one Powershell repository because author thought that ps is hard and he wanted Get-Process. I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful Particulary > Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through.
  - GFK_of_xmaspast 10y ago
    > I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful Not sure I can think of too many situations where it would be otherwise.
    - majkinetor 10y ago

kbenson 10y ago

> aversion to certain shortcuts like ternary operators. > They don't understand that unclear code is probably the number one cause of technical debt. At the same time, verbosity can have an obfuscation quality all of its own. For simple assignment, I find a ternary operator very clear and concise, and much preferable to a 5-9 line (depending on style) if/else for a simple assignment. It also might keep you from using the single statement version of if/else if your language supports it, and that's probably justification in itself given how many problems that's caused in the past. Specifically, I think: usefulMetric = wantComplexCalc ? complexCalc(foo) : simpleCalc(foo); is preferable to: if ( wantComplexCalc ) { usefulMetric = complexCalc(foo) } else { usefulMetric = simpleCalc(foo) } even if only because it doesn't obscure intent with what is essentially boilerplate.

ludicast 10y ago
Agreed, plus obviously your "if" statement doesn't do the assignment to usefulMetric. One more way the ternary wins (along with functional languages that use "if"s as expressions).
- kbenson 10y ago
  D'oh! Fixed. Thanks. :)
- LgWoodenBadger 10y ago
  a "final" declaration (in Java) would have pointed that out through a compilation error ;)
pacala 10y ago
OP is about Scala, where you write directly what you mean, without special operators: val usefulMetric = if (wantComplexCalc) { complexCalc(foo) } else { simpleCalc(foo) }
- kbenson 10y ago
  Well, that's only "directly what you mean, without special operators" if you come from a C style procedural background and have already internalized all the special operators you've included there, such as parenthesis and braces. Sure, that's most people, but that doesn't mean they aren't operators.
- amyjess 10y ago
  I'd rather have Python's way of doing it, which plays with the order for the sake of readability: useful_metric = complex_calc(foo) if want_complex_calc else simple_calc(foo)
  - christophilus 10y ago
    Ruby has something similar, and I can't stand it. I think the conditional is the most important item in the phrase, and it's shoved off to the right. If you lead with the conditional, it becomes immediately apparent that the assignment is predicated on the result of a branch.
    - kbenson 10y ago
      Ruby (and Python) likely get that from Perl, which has post conditionals, but with specific qualities to prevent them from too much abuse, and which also prevents them from being used in the way presented here (which is why I didn't trot them out earlier, as much as I was tempted by the "you write what you mean" line). The limitations are that there is no else branch, and it only applies to a single statement, so you can't have a block executed with a post conditional. It leads to usage like so: die "Invalid param: please enter a positive number" unless $param1 > 0; $param2 = 0 unless defined $param2; return undef if $param1 and not $param2; my $foo = 1 if $bar; # This unfortunately creates a closure around $foo and is a big source of bugs. As much flak as Perl gets, quite a lot of thought went into making it flow similar to how people think and talk (which is no surprise if you know Larry Wall is a linguist by training). There were some missteps, but it was very early in this area, so that's expected.
jiaweihli 10y ago
Unfortunately, ternary operators eventually end up like this due to refactoring blindness: usefulMetric = wantComplexCalc ? (complexity > 40 ? superComplexCalc(foo) : regularComplexCalc(foo)) : simpleCalc(foo);
- kbenson 10y ago
  At some point you have to rely on policy and not language constraints. I submit that no language is constrained enough to protect against refactoring stupidity while also being flexible enough to be useful to the average programmer on the average project. If not ternary if, it will be something else. So, do you throw out every alternative method to accomplish the same thing, or do you put policies in place to keep the code sane, such as "no chained ternary operators are allowed" ?
  - jiaweihli 10y ago
    In all honesty, I prefer having rules that have no special-case 'unless' issues. It's too much effort/trouble to remember all the cases where things don't work. I'm a good engineer but a terrible compiler. I believe part of learning a new library/framework/language is to limit yourself to a certain subset of the API offered. After working with Ruby (the language) and Javascript (the ecosystem), I feel like that's the only way to preserve your sanity and productivity. I don't need to know 4 different ways of creating a lambda in Ruby, selecting 1 that can express the other 4 is good enough. --- In this case, the rule would be no ternary operators, since they work well unless you nest them or unless you make them long/complicated. Other examples - You don't need to wrap if conditions unless you have a multi-line body: if (myCondition) x = 42; y = 23; Early returns simplify short circuiting logic unless your function becomes too long: if (myVariableAtBeginningOfFunction) { return true; } ... // 2 screens later ... if (x == 42) { return false; // why am I not getting false?! } Using a variable as a conditional in javascript to test against undefined works well unless the value can be falsy: if (person.isStudent) { showSchool(); } if (person.age) { showBirthCertificate(); // what if age is 0? }

jghn 10y ago

One person's clever is another person's clear and vice versa. These conversations are pointless as there is no objective truth on code clarity

deleted 10y ago
[deleted]
edblarney 10y ago
I'm not sure if this is true. Scala provides a whole new level of ability for people to write code that can be meaningless to others. It really is quite different.
- jghn 10y ago
  And that sort of scala code is extremely meaningful to other folks, which captures my point. I see scala code all the time that would give me an instant headache but there are people who would find that more readable. To each their own, the is to work with people who are at least somewhat aligned to your sensibilities.
  - edblarney 10y ago
    Fair enough - but I'll offer this: + Any decent developer can read decent code in Java or whatever normal language and get along just fine. + Only a few people can deal with Scala - and even fewer if there's a log of specific project Scala weirdness used in a particular program. So sure - among a narrower set of 'Scala friendly' developers, and possibly within that even narrower set of people familiar with the 'Scala weirdness' of a particular project - those people can 'get along fine'. The problem is that this can be a pretty narrow set of people. Scala would have to represent a pretty big advantage to propose it's general weirdness as something to bother with. I don't think it does - hence the 'de-adoption' of various entities. My gut tells me it's past the threshold - the 'extra power' offered Scala just isn't quite worth it's weirdness for most things, and so most devs won't learn it ... and so then it becomes less valuable from a business perspective. It's possible we may have it peak Scala. We'll see I guess.

deleted 10y ago

[deleted]

true_religion 10y ago

> They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. True, but once get into the length of variable names in iOS and Android development, you're in a whole new territory. 38 character variables have no place in life. And extreme's like: outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch This is 149 character.

justicezyx 10y ago
The thing is that, shorter names do not help in this case either...

ivanhoe 10y ago

IMHO it's a wrong approach. Every programming language, just like the spoken ones, has it's common shortcuts and idioms. The fact that they're commonly accepted and used is what makes them easy to understand. Your brain learns to recognize them quickly, often much quicker then the long version. With newbies and programmers who switched from other languages problem is that their brain is just not yet trained to do that efficiently. Instead of investing some time into getting used to the peculiarities of the language that they use, they then try to avoid them as "complicated". By lowering a bar too low, and avoiding using these patterns all together, you encourage people to never train their brains to recognize them effortlessly. And by definition of common patterns, they're, well, common, and they'll keep running into them all of the time. Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through. I'm not saying that one should go crazy with one-liners or uncommon patterns, but things like ternary operators used with reasonably short expressions in a single line of code are totally valid and should be readable to any average dev out there.

majkinetor 10y ago
Great comment. Particularly > Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through. I stopped contributing to one Powershell repository because author thought that ps is hard and he wanted Get-Process. I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful Particulary > Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through.
- GFK_of_xmaspast 10y ago
  > I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful Not sure I can think of too many situations where it would be otherwise.
  - majkinetor 10y ago