View mode: basic / threaded / horizontal-split · Log in · Help
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
On Fri, 18 Nov 2005 01:26:24 +0000 (UTC), JT <JT_member@pathlink.com>  
wrote:
> In article <dlj7fm$2rk9$1@digitaldaemon.com>, Munch says...
>>
>> OK so here is my other suggestion. It's very simple to implement from a  
>> compiler
>> perspective - it adds robustness - it just needs a slight rearangement  
>> of the
>> sytnax. I found a thread on it in the archives here:
>> http://www.digitalmars.com/d/archives/1418.html
>>
>> Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like  
>> this:
>>
>> while (i < 9)
>> i++; j++;
>>
>> or this
>>
>> if (cond)
>> <debug statement added to find bug>;
>> <line of code intended to be conditional>;
>>
>> or more generally
>>
>> if (cond)
>> <added code here>;
>> <ORIGINAL conditional line of code>; <and/or more added code>;
>> <and/or more added code>;
>>
>> This is one of those things that when you start out coding you kid  
>> yourself that
>> you save time by skipping out the braces. As the years roll by you  
>> gradually
>> come across bugs that are harder and harder to find, that had part of  
>> their
>> cause in missing curlys. Sooner or later you learn to use braces  
>> everywhere. I
>> occasionally do code reviews and whenever I've come across code which  
>> doesn't
>> have curlys everywhere, I know I'm likely to find a bug somewhere in  
>> the code.
>> This is easy to fix in the language syntax, thus:
>>
>> IfStatement:
>> if ( Expression ) BlockStatement
>> if ( Expression ) BlockStatement else BlockStatement
>> if ( Expression ) BlockStatement else IfStatement
>>
>> Not enough motivation yet? Finally, this also kills one of the most  
>> insidious
>> bugs in C/C++/Java:
>>
>> if (cond);
>> <code intended to be conditional>
>>
>> I've only done this a few times in my programming life, mainly in the  
>> first few
>> years, but boy did some of those bugs take a long time to find. Note  
>> that this
>> one can't be fixed by voluntarily entering braces yourself:
>>
>> if (cond);
>> {
>> <code intended to be conditional>
>> }
>>
>> The above syntax however, makes this a compile time error =)
>>
>> (Obviously the above also applies to "for", "while" etc. )
>>
>> Regards
>>
>> Munch
>
>
> I completely disagree. I enjoy the flexibility and I dont believe it  
> should be
> limited just because someone, somewhere, might screw up. I would suggest  
> using
> some sort of D lint application, such as a modified front end that would  
> catch
> something like that, it would be fairly easy to do.

I'm with JT. D isn't supposed to to enforce one code style over another,  
though you could argue it already does this to a limited degree.

The D compiler front end source is open source (or similarly licensed)  
such that writing a lint checking tool should be fairly easy. Ben Hinkle  
even simplified the process some, search for "dmdfe" in these newsgroups  
if you're interested.

Regan
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
On Fri, 18 Nov 2005 01:26:24 +0000 (UTC), JT wrote:


> I completely disagree. I enjoy the flexibility and I dont believe it should be
> limited just because someone, somewhere, might screw up. 

You, of course, have every right to that opinion. Just as I have to mine,
and that is that I do *not* enjoy maintaining code written with these sort
of embedded 'mine fields'. The 'goto' is another similar problem however
there are extenuating circumstances for its occasional usage, but what
benefit is there to an application by omitting braces?

In general, coding practices that increase the probability of mistakes
should only be allowed when there is a demonstrable benefit, on a per
instance basis, to the application over its lifetime. Failing that, the
language should actively discourage such practices. 

> I would suggest using
> some sort of D lint application, such as a modified front end that would catch
> something like that, it would be fairly easy to do.

Yes, we need more band-aids. ;-)

I would argue the opposite. If a coder wishes to enjoy the flexibility of
omitting braces then a compiler option should be given to allow that
practice. Either a command-line switch or (even better) a pragma in the
source code. In other words, the cost of making mistakes easier to create
should be born by the coder.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/11/2005 1:15:17 PM
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
Honestly, and I mean no disrespect, but I've never understood why people 
make such a big deal out of this one.

I personally value my vertical real estate when programming, and as I 
use so much for train-of-thought comments (unlike many programmers these 
days), I always leave the braces off for single statements.

Indeed, I've seen some who use:

if (condition) expression;

While that goes against my coding standards, and as such is something I 
never do, I don't think the people who prefer that style for short if 
conditionals would like the requirement of braces either.

I strictly follow coding standards, and although I have had problems 
with a semicolon at the end of my ifs, whiles, and fors... I have never 
(nor have any of the programmers under me ever) accidentally screwed up 
a conditional because it didn't have braces.

Don't get me wrong; I understand that if you were used to braces always 
being there, you might make the mistake.  We're all only human.  But... 
and again, with all due respect... it seems to me such a weird mistake 
to make.  If I ever employed a programmer who seriously had this 
problem, I would worry that requiring braces wouldn't help much.  But 
this is only me, and again I am not in any way judging you or anyone who 
does have the problem, just explaining my own worries.

That said, I personally would like a compiler that could (optionally, 
e.g. with a "plugin") check code against coding standards: no multiple 
statements on one line, no lack of spaces around operators, no braces on 
ifs and other conditionals.  But, there'd have to be a way to ensure 
that only developers use these conditions; not people compiling code for 
their system.

-[Unknown]


> OK so here is my other suggestion. It's very simple to implement from a compiler
> perspective - it adds robustness - it just needs a slight rearangement of the
> sytnax. I found a thread on it in the archives here:
> http://www.digitalmars.com/d/archives/1418.html
> 
> Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
> 
> while (i < 9)
> i++; j++;
> 
> or this
> 
> if (cond)
> <debug statement added to find bug>;
> <line of code intended to be conditional>;
> 
> or more generally
> 
> if (cond)
> <added code here>;
> <ORIGINAL conditional line of code>; <and/or more added code>;
> <and/or more added code>;
> 
> This is one of those things that when you start out coding you kid yourself that
> you save time by skipping out the braces. As the years roll by you gradually
> come across bugs that are harder and harder to find, that had part of their
> cause in missing curlys. Sooner or later you learn to use braces everywhere. I
> occasionally do code reviews and whenever I've come across code which doesn't
> have curlys everywhere, I know I'm likely to find a bug somewhere in the code.
> This is easy to fix in the language syntax, thus:
> 
> IfStatement:
> if ( Expression ) BlockStatement
> if ( Expression ) BlockStatement else BlockStatement
> if ( Expression ) BlockStatement else IfStatement
> 
> Not enough motivation yet? Finally, this also kills one of the most insidious
> bugs in C/C++/Java:
> 
> if (cond);
> <code intended to be conditional>
> 
> I've only done this a few times in my programming life, mainly in the first few
> years, but boy did some of those bugs take a long time to find. Note that this
> one can't be fixed by voluntarily entering braces yourself:
> 
> if (cond);
> {
> <code intended to be conditional>
> }
> 
> The above syntax however, makes this a compile time error =)
> 
> (Obviously the above also applies to "for", "while" etc. )
> 
> Regards
> 
> Munch
> 
>
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
On Thu, 17 Nov 2005 21:55:56 -0800, Unknown W. Brackets  
<unknown@simplemachines.org> wrote:
> That said, I personally would like a compiler that could (optionally,  
> e.g. with a "plugin") check code against coding standards: no multiple  
> statements on one line, no lack of spaces around operators, no braces on  
> ifs and other conditionals.  But, there'd have to be a way to ensure  
> that only developers use these conditions; not people compiling code for  
> their system.

I think this is a great idea "Optional pluggable compiler modules".

Regan
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
> I completely disagree. I enjoy the flexibility and I dont believe it should be
> limited just because someone, somewhere, might screw up. I would suggest using
> some sort of D lint application, such as a modified front end that would catch
> something like that, it would be fairly easy to do.

i will never understand why people allways fight for their right to make 
coding errors which can be handle totaly by an good snytax (or paradigm) 
change.

and i still don't understand why people use arguments like

"this could handle a tool" - what codeing-help-tool have ever worked in 
the right (and standartrized) way for us?

"programmers should/could do it the right way" - mistakes are mostly 
made under bad conditions like stress or something

or "i never had this problem" ;-]


just a tip:

though of an

  big-1-to-x-Mio-lines,
  10-years-rotten,
  and 100-programmers with-different-experince,

sized project and you will understand why small changes can be gain an 
very huge benefit

ciao dennis
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
In article <dlk018$hcv$1@digitaldaemon.com>, dennis luehring says...
>
>> I completely disagree. I enjoy the flexibility and I dont believe it should be
>> limited just because someone, somewhere, might screw up. I would suggest using
>> some sort of D lint application, such as a modified front end that would catch
>> something like that, it would be fairly easy to do.
>
>i will never understand why people allways fight for their right to make 
>coding errors which can be handle totaly by an good snytax (or paradigm) 
>change.
>
>and i still don't understand why people use arguments like
>
>"this could handle a tool" - what codeing-help-tool have ever worked in 
>the right (and standartrized) way for us?
>
>"programmers should/could do it the right way" - mistakes are mostly 
>made under bad conditions like stress or something
>
>or "i never had this problem" ;-]
>
>
>just a tip:
>
>though of an
>
>   big-1-to-x-Mio-lines,
>   10-years-rotten,
>   and 100-programmers with-different-experince,
>
>sized project and you will understand why small changes can be gain an 
>very huge benefit
>
>ciao dennis
>
>
>
>
>

Its a fundamental issue that has nothing actually to do with coding. Some people
wish to force a style upon another group of people 'for their own good'

All I can say is I am delighted that Walter is the one making these kinds of
decisions :D
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
Munch wrote:
> OK so here is my other suggestion. It's very simple to implement from a compiler
> perspective - it adds robustness - it just needs a slight rearangement of the
> sytnax. I found a thread on it in the archives here:
> http://www.digitalmars.com/d/archives/1418.html
> 
> Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
> 
> while (i < 9)
> i++; j++;
> 
> or this
> 
> if (cond)
> <debug statement added to find bug>;
> <line of code intended to be conditional>;
> 
> or more generally
> 
> if (cond)
> <added code here>;
> <ORIGINAL conditional line of code>; <and/or more added code>;
> <and/or more added code>;
> 
> This is one of those things that when you start out coding you kid yourself that
> you save time by skipping out the braces. As the years roll by you gradually
> come across bugs that are harder and harder to find, that had part of their
> cause in missing curlys. Sooner or later you learn to use braces everywhere. I
> occasionally do code reviews and whenever I've come across code which doesn't
> have curlys everywhere, I know I'm likely to find a bug somewhere in the code.
> This is easy to fix in the language syntax, thus:
> 
> IfStatement:
> if ( Expression ) BlockStatement
> if ( Expression ) BlockStatement else BlockStatement
> if ( Expression ) BlockStatement else IfStatement
> 
> Not enough motivation yet? Finally, this also kills one of the most insidious
> bugs in C/C++/Java:
> 
> if (cond);
> <code intended to be conditional>
> 
> I've only done this a few times in my programming life, mainly in the first few
> years, but boy did some of those bugs take a long time to find. Note that this
> one can't be fixed by voluntarily entering braces yourself:
> 
> if (cond);
> {
> <code intended to be conditional>
> }
> 
> The above syntax however, makes this a compile time error =)
> 
> (Obviously the above also applies to "for", "while" etc. )
> 
> Regards
> 
> Munch
> 
> 

Such error is quite uncommon with nowadays modern IDEs, specifically, 
those with auto-indentation.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
Derek Parnell wrote:
>>Not enough motivation yet? Finally, this also kills one of the most insidious
>>bugs in C/C++/Java:
>>
>>if (cond);
>><code intended to be conditional>
> 
> 
> The DMD compiler already catches this one. If you try it you get this
> message ...
> 
>    use '{ }' for an empty statement, not a ';'
> 
> It is not well documented and it might not even be a part of the D-Language
> (as opposed to a compiler implementation). There is a small comment in the
> 'for' statement documentation that says ...
> 
>    Function bodies cannot be empty: 
> 
>      for (int i = 0; i < 10; i++)
>         ; // illegal
> 
>    Use instead: 
> 
>      for (int i = 0; i < 10; i++)
>      {
>      }
> 
> But it seems to apply to other statements as well.
> 

Great - thanks =) That's good news, but like you say it would be nice to 
have braces forced anyway.

Munch
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
JT wrote:
> Its a fundamental issue that has nothing actually to do with coding. Some people
> wish to force a style upon another group of people 'for their own good'
> 
> All I can say is I am delighted that Walter is the one making these kinds of
> decisions :D

Personally, I use

if (cond) return val;

and

if (cond) break;

frequently. This has no risk of the coding error mentioned, and is much 
clearer than the brace alternative.

However, I agree that using an 'else' clause without braces between 'if' 
and 'else' is asking for trouble. Ditto for while and for. And 
definitely for do-while.

If you look in phobos you'll find plenty of examples of "if" statements 
with no braces. I think the request is in vain.
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
Unknown W. Brackets wrote:
> Don't get me wrong; I understand that if you were used to braces always 
> being there, you might make the mistake.  We're all only human.  But... 
> and again, with all due respect... it seems to me such a weird mistake 
> to make.

Actually in my experience this mistake is more often made by newer 
programmers who haven't got used to using brackets yet. Since I work 
with a wide range of programmers, from "just graduated" to 35 years on 
the job, if we're going to move our teams over to using D in the future 
(and I'd like us to) I'm looking for a language that is suitable for all 
 programmers. As an aside though, like you say, we are all human. When 
it's late and you're tired and haven't eaten and the deadlines looming 
and you also know your family is wanting you home etc. etc. it's very 
easy to add a line of debug and forget to add the braces. It's not so 
much about the kind of mistake - sure it's fairly rare - but given the 
ease of fixing it -why not?

I can appreciate the "vertical real estate" argument, but in that case
how about:

   if (cond) {
      blah; }

Or even:

   if (cond) { blah; }

I hear Bruno's point about auto indent, and the lint ideas, compiler 
warning flags etc. but surely the whole spirit of D is to include this 
stuff _in_the_language_ otherwise people end up not using it.

Cheers

Munch
1 2 3 4 5
Top | Discussion index | About this forum | D home