So here is an example.
Been hanging around this forum for a while and came to a conclusion / opinion that majority of newcomers are challenged by language syntax.
It is common to see jewels likes
if( input = HIGH)....
if( input Low, temperature HIGH);
C / c++ is a high level language so is obfuscating it with poorly documented gems such as “if(Serial)” really helping?
Fire retardant liberally applied.
On the other hand, reading thru the Reference pages and looking at some examples is not that difficult, so overcoming syntax issues shouldn't be that diffucult. I treat them more as typo's to be overcome.
I think it's one of those "clever" constructs that, while short and convenient, would be much better implemented as:
if (Serial.connected())
I'm a big, big fan of clear, obvious code. I don't want to guess, or wade through object definitions, or even APIs, to figure out what a simple statement is supposed to mean.
However... my opinion is tainted somewhat by the fact that I don't really speak C++, so if there's established convention for the class object itself to return a value in boolean context, then... well, so be it. I can kind of see this, in the sense that "if (Serial)" Is kind of like saying "if the Serial object has been initialized", and by nature of the simple protocol, if the object was initialized, then it's connected. However, this is the implementation:
class HardwareSerial : public Stream {
public:
operator bool();
};
...
HardwareSerial::operator bool() {
return true;
}
So it all seems rather pointless to me, but I'm sure there are subtleties that I'm not picking up on.
SirNickity:
However, this is the implementation.
Correction...
However, this is the one implementation.
SirNickity:
I think it's one of those "clever" constructs that, while short and convenient, would be much better implemented as:
Agree.
One of the foundations of the "Arduino Language" is to use the smallest possible subset of C++ to reduce the pain inflicted on newcomers. Your version aligns with that foundation and established practice.
As far as I can tell all of the other operators are meant to make the "Arduino Language" more like normal algebraic expressions (like comparing two IP addresses) which should have the effect of reducing the amount of crap newcomers have to learn.
It is unfortunate the person who coded Serial/bool deviated.
Oh, and given the fact that Serial/bool is nearly always wrapped in a busy loop this would probably be a good addition...
Serial.waitForConnection();
I don't find .connected and .waitForConnection to be all that clear.
.available is more clear to me, lets you know that data is ready to be read.
Maybe .received might have been a better name.
The other 2 imply in my mind that some kind of back & forth has occurred and a positive datapath has been established, when many times it's a dumb one-way connection and all you can do is wait data to come in, or it's a dumb one-way out with no feedback from the recipient.
That occurred to me as well. I'm not really sure under what circumstances (bool)Serial is supposed to return anything other than TRUE. Seems it would be an undefined symbol if the object wasn't created, so that's no good.
Coding Badly says this is but one implementation, so maybe it has changed in later releases? Or it's overloaded? I don't know. All I have on-hand is the core library that I keep on this computer as a code reference -- not even the full install.
Curiouser and curiouser.
Ah! OK, thanks. So, yeah... connected() would have been better. 
I see - the Serial discussion seems to be a mix if the Hardware UART (Serial, me) and USB interface (everyone else).
Vaclav:
C / c++ is a high level language so is obfuscating it with poorly documented gems such as “if(Serial)” really helping?
I'd dispute that.
APL is a high-level language, and so probably is Python or a myriad other scripting language.
C was designed as way of facilitating porting systems programs and operating systems (specifically Unix) and was designed to be an intermediate-level language, close to the hardware, but capable of expressing higher-level constructs (abeit clumsily)
Opinion expressed.
Waiting.
C or c was developed as a low level language for systems development. (about as close to assembly as one could get without using assembly) Then some folks decided that to use anything else was evidence that the programmer was really a moron and beneath contempt. And so they formed a COMMITTEE and it became this gross, unwieldly thing called C++ with more rules and everything got redefined (methods???) and became much harder to use and the programs became more bloated to support all the new stuff developed by the COMMITTEE.
And meanwhile there are other languages that make applications very easy to write, but anyone that would use one of them is less than worthless because they didn't us c/C++...
Most of the Arduino is based on c. Considering the ram size, many of the constructs of C++ are not really practical and can easily be memory hogs.
(Think this will start an argument?)
We'd not have this problem if atmel decided to write a pascal compiler!
If (thevar=1) {}
Would simply not be allowed...
If (thevar:=1) begin end;
is illegal syntax.
If (thevar=1 )
Valid syntax
But the masses have spoken and it seems we're stuck with c style syntax... java, php..
C++ has some useful features that don't necessarily consume resources willy-nilly. E.g., function overloading. Things like that make it potentially worthwhile to compile your C code with a C++ compiler.
Of course you can use C++'s features to exhaust the meager resources of a microcontroller, but you do this using C (or any language) as well. Living within constraints is the job of any engineer -- software, hardware, whatever.