I've always felt that most good programmers go through 3 stages.
Stage 1: Write very simple, naive code, no fancy design patterns, just kind of brute force everything.
Stage 2: Discover design pattens, and fancy obscure programming constructs. Use them everywhere regardless of whether it makes sense or makes the code easier to understand and maintain.
Stage 3: Realize the folly of stage 2, and enter a zen like state where one writes deceptively simple, clean code. Rarely, if ever, use any fancy constructs or design patterns (except where it actually makes sense to use them.)
For the novice programmer looking at someone else's code it's very very easy to confuse stages 1 and 3.
There is a similar trajectory in what you choose to build. In stage 1 you write programs that are conspicuously missing features; in stage 2 you write programs that have too many features (and yet may still be missing some important ones); in stage 3 you write programs that do exactly what's needed.
My experience suggests that one good way to speed the transition to stage 3 is to try to make your programs short. When I was writing On Lisp I spent a lot of time working on programs that had to be short enough to be reproduced in the book, and this cured me of the tendency to pile on features.
Rtm's example probably helped too. His source code is as laconic as he is in person.
Stage 1: Learning, perfecting skills with simpler music.
Stage 2: Discovering new techniques and musical ideas, stretching their skills, attempting to pull off dense and complex ornamentation as fast as possible.
Stage 3: Realizing that stage 2 may make for a good show, but can impede great music. Enter a zen like state where one plays deceptively simple but tasteful, clear, and highly effective expressions of fundamental musical ideas. (EDIT: Which enhance a given tune as a coherent whole.)
For the novice player, it's possible to mistake stage 3 for stage 1 and common to conclude the progression stops at stage 2.
I think there is a stage between 2 and 3 where people become obsessed with coding standards that say thing like "don't use the ternary operator because it can be confusing".
I never use them, and typically enforce coding standards preventing their use as well. Good code should be easy to read, and if/else blocks are easy to read.
Lets better hope we never end up on the same team then. I have no patience for dumbing down shit to people who have no business writing code.
The ternary operator is a standard and it is in the language for a good reason - it can make certain statements smaller and involve simpler code (that is, less places to screw up).
Yes it can be abused, but so can everything else. The solution is not to cut out features but to cut out those who are not fit to program.
The use of ternary operators is a standard idiom, at least in C, and reduces the visual noise of if..then..else used to implement code like your example.
Enforcing coding standards to ban the use of standard idiom is exactly the sort of reason that I refuse to work for bone-headed cubicle farm-type companies.
The use of the ternary operator for such things as:
String a = (b == null) ? "" : b;
is okay with me, at least, when I'm working in languages other than C#, where it's just:
string a = b ?? "";
I also use it within other operations, like:
var output = string.Format("Something {0} something {1}",
string1.Length > 0 ? string1 : "N/A",
string2.Length > 0 ? string2 : "whoops");
My general rule of thumb is, if breaking the ternary operation into multiple lines will make it more readable, then you're going too far with the ternary operator.
To be honest, this surprises me a lot. I'm not a professional programmer, for some definition of same; but I do write a great deal of code and make my living from using and maintaining it.
Even stage 2 programmer confuse stage 3 for stage 1, this makes very difficult to help stage 2 programmer grow. I suppose this is the difference between knowing the path and walking the path ;)
I find my way through TDD, but all my tentatives to help others failed. I can understand why because all tentatives to help me before I see the light on my own failed equality. I can remember some conversations with more experienced programmers where I tried to convince them about the benefits of more design as they were trying to explain me the vertues of simplicity...
This applies to every domain which has experts. Somehow, the learning curve takes you places you later abandon.
If there is a lesson to take from this is that one might be able to get a feeling for what the extra fluff in second stage looks like. The hype, the enjoyment of doing things for the wrong reasons etc.
A rather insidious side effect is that most people who teach / talk about the process are in second stage. The experts usually went beyond examining the process, and have little interest in discussing it.
Stage 1: Write very simple, naive code, no fancy design patterns, just kind of brute force everything.
Stage 2: Discover design pattens, and fancy obscure programming constructs. Use them everywhere regardless of whether it makes sense or makes the code easier to understand and maintain.
Stage 3: Realize the folly of stage 2, and enter a zen like state where one writes deceptively simple, clean code. Rarely, if ever, use any fancy constructs or design patterns (except where it actually makes sense to use them.)
For the novice programmer looking at someone else's code it's very very easy to confuse stages 1 and 3.