November 18, 2005
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
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
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
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
> 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
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
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
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
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
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