Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Style: Declaration in if/while-condition - good or bad?

Reply
Thread Tools

Style: Declaration in if/while-condition - good or bad?

 
 
Martin Ba
Guest
Posts: n/a
 
      02-27-2013
C(++) allows for a simple variable declaration+init in the condition of
an if or while:

while (T t = x) {
}

if (int x = f()) {
}

I find this rather useful for things like:

if (const T* pThing = GetThing()) {
...
} else {
// Handle No-Thing case
}


However, I have been told by a colleague that this is little used and
would surprise and confuse a lot of developers and therefore it's better
to use the form:

const T* pThing = GetThing();
if (pThing) {
...
} else {
// Handle No-Thing case
}


Opinions?

cheers,
Martin
 
Reply With Quote
 
 
 
 
Pavel Volkovskiy
Guest
Posts: n/a
 
      02-27-2013
Fine.

a) for (int i = 0; i < 10; ++i) { //...
b) void func(T t);
etc.
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      02-27-2013
On 2/27/2013 7:41 AM, Martin Ba wrote:
> C(++) allows for a simple variable declaration+init in the condition of
> an if or while:
>
> while (T t = x) {
> }
>
> if (int x = f()) {
> }
>
> I find this rather useful for things like:
>
> if (const T* pThing = GetThing()) {
> ...
> } else {
> // Handle No-Thing case
> }
>
>
> However, I have been told by a colleague that this is little used and
> would surprise and confuse a lot of developers and therefore it's better
> to use the form:
>
> const T* pThing = GetThing();
> if (pThing) {
> ...
> } else {
> // Handle No-Thing case
> }
>
>
> Opinions?


Your colleague's opinion seems rather unfounded. AFAICT it is quite a
commonplace to have a pointer declared in the 'if' condition to be used
only when it evaluates in non-null expression. Unless there is a need
to use 'pThing' after the 'if' statement, there is no reason for
'pThing' to be declared in the scope outside of the 'if' it has been
evaluated for. Does this help? I hope so.

V
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
Alain Ketterlin
Guest
Posts: n/a
 
      02-27-2013
Martin Ba <(E-Mail Removed)> writes:
[...]
> while (T t = x) {
> }
>
> if (int x = f()) {
> }


[instead of]

> const T* pThing = GetThing();
> if (pThing) {
> ...
> } else {
> // Handle No-Thing case
> }


They are not equivalent, because the former restricts the scope of the
declaration (you would need a pair of braces around the second piece of
code to get the same effect).

I find myself using this more and more, often changing my code to make
these patterns usable. I think you should not worry about potential
"surprise and confusion", because the code looks to me completely
unambiguous, and therefore it takes almost no time to get used to.

-- Alain.
 
Reply With Quote
 
Tobias Müller
Guest
Posts: n/a
 
      02-27-2013
Martin Ba <(E-Mail Removed)> wrote:
> C(++) allows for a simple variable declaration+init in the condition of an if or while:
>
> while (T t = x) {
> }
>
> if (int x = f()) {
> }
>
> I find this rather useful for things like:
>
> if (const T* pThing = GetThing()) {
> ...
> } else {
> // Handle No-Thing case
> }
>
>
> However, I have been told by a colleague that this is little used and
> would surprise and confuse a lot of developers and therefore it's better to use the form:
>
> const T* pThing = GetThing();
> if (pThing) {
> ...
> } else {
> // Handle No-Thing case
> }
>
>
> Opinions?


Regardless whether someone is actually using it or not, it should at least
be clear what it does. I don't understand how this is confusing. Everyone
uses it with 'for' loops.

Personally, I use it from time to time but it has also some drawbacks.

Pro:
- Keeps the outer scope clean.
- Declaration is very close to the point where it is used, especially in
'else if' conditions.
Con:
- Only possible with implicit conversion to bool instead if explicit
condition (e.g. pThing != NULL).
- Complex conditions are not possible. E.g: if (pThing &&
pThing->IsValid())

Because of that limitations, one can argue that if the condition changes in
the future, you have to move it to the outer scope anyway. And those
changes are potentially dangerous (because you increase the scope of a
variable) and more difficult to review than just changing the condition.

Tobi
 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      02-27-2013
On 2/27/2013 1:41 PM, Martin Ba wrote:
> I find this rather useful for things like:
>
> if (const T* pThing = GetThing()) {
> ...
> } else {
> // Handle No-Thing case
> }
>
>
> However, I have been told by a colleague that this is little used and
> would surprise and confuse a lot of developers and therefore it's better
> to use the form:
>
> const T* pThing = GetThing();
> if (pThing) {
> ...
> } else {
> // Handle No-Thing case
> }


The latter form is way inferior. And developers who actually get
confused by it (after a 5-minute training) are better have their code
checkin right suspended. And a workplace with abundance of such people
is better left ASAP.



 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      02-27-2013
On 2/27/2013 2:40 PM, Tobias Müller wrote:
> Con:
> - Only possible with implicit conversion to bool instead if explicit
> condition (e.g. pThing != NULL).
> - Complex conditions are not possible. E.g: if (pThing &&
> pThing->IsValid())


Yeah, too bad we have restrictions (other one popping up with for that
we need multiple vars, and only one is supported; I'm generally not
happy to use tuple as workaround).

But that is not an argument against use where actually possible.

> Because of that limitations, one can argue that if the condition changes in
> the future, you have to move it to the outer scope anyway. And those
> changes are potentially dangerous (because you increase the scope of a
> variable) and more difficult to review than just changing the condition.


That sounds pretty weird. And as a purely fear-based speculative argument.

Future changes are problems of the future. Covered well by YAGNI, and
was experience on our inability to correctly predict the future. So
better drop all speculation and keep the code simplest and easiest to
read. Now, and ever. For the task that must be done.

And I don't see why review the change later would be more dangerous or
time-consuming than doing it right now.

While leaving variable around will keep an educated reader wondering on
its purpose.
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      02-27-2013
Balog Pal <(E-Mail Removed)> writes:
>The latter form is way inferior. And developers who actually get
>confused by it (after a 5-minute training) are better have their code
>checkin right suspended.


If it helps the OP to get a kind of an idea of the
prevailing/general/average opinion: I agree!

 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      02-28-2013
Balog Pal於 2013年2月28日星期四UTC+8上午3時30分38秒 寫道:
> On 2/27/2013 1:41 PM, Martin Ba wrote:
>
> > I find this rather useful for things like:

>
> >

>
> > if (const T* pThing = GetThing()) {

>
> > ...

>
> > } else {

>
> > // Handle No-Thing case

>
> > }

>
> >

>
> >

>
> > However, I have been told by a colleague that this is little used and

>
> > would surprise and confuse a lot of developers and therefore it's better

>
> > to use the form:

>
> >

>
> > const T* pThing = GetThing();

>
> > if (pThing) {

>
> > ...

>
> > } else {

>
> > // Handle No-Thing case

>
> > }

>
>
>
> The latter form is way inferior. And developers who actually get
>
> confused by it (after a 5-minute training) are better have their code
>
> checkin right suspended. And a workplace with abundance of such people
>
> is better left ASAP.


How about getting 2 to 5 things in different classes to work together
in a safe way if anything went wrong?
 
Reply With Quote
 
Martin Ba
Guest
Posts: n/a
 
      02-28-2013
On 27.02.2013 20:42, Balog Pal wrote:
> On 2/27/2013 2:40 PM, Tobias Müller wrote:
>> ...
>> Because of that limitations, one can argue that if the condition
>> changes in
>> the future, you have to move it to the outer scope anyway. And those
>> changes are potentially dangerous (because you increase the scope of a
>> variable) and more difficult to review than just changing the condition.

>
> That sounds pretty weird. And as a purely fear-based speculative argument.
>


It seems fear-based arguments are "common" when discussing C++. Maybe
because it's such an awe-inspiring language


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can a static function declaration conflict with a non-static declaration? nospam_timur@tabi.org C Programming 4 12-12-2006 10:26 PM
maxplusII error: a deferred constant declaration without a full declaration is not supported Noah VHDL 5 04-07-2006 02:34 PM
"virtual outside class declaration" and "declaration does not declare anything" kelvSYC C++ 6 05-17-2005 08:58 AM
Function declaration in class declaration Ovidesvideo C++ 4 12-10-2004 06:36 PM
Intel C++ 8.0 : declaration hides declaration Alex Vinokur C++ 4 04-05-2004 09:49 PM



Advertisments