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?]
Yeah; coding styles are a bit like religion to some. I remember a long 
thread about making the 'override' keyword mandatory (to help with 
maintenance), but some folks griped miserably about having to type a few 
extra characters ...

There's no pleasing everyone, I guess.


"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message 
news:dljqcr$d63$1@digitaldaemon.com...
> 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
In article <dllivh$21r4$1@digitaldaemon.com>, Munch says...
>
>In article <dlkmou$1882$1@digitaldaemon.com>, JT says...
>
>>Sorry I didnt mean to be rude or anything, and I can understand why some people
>>would find this usefull. I simply cannot understand wanting to impose this on
>>everyone, because, to me, its actually a style issue more than anything.... 
>
>Don't worry, no offense taken =) I can understand that you can't understand it,
>but that doesn't mean it's not a good idea of course, it probably just means we
>have different experience of coding.
>
>I guess a lot of this comes down to the kind of software you write. I'm used to
>working in teams - each new project I work on I'll be working with at least some
>people who I've never worked with before. Some projects, I'm so removed from the
>coding team that I hardly actually get to see the source code, othertimes I'm in
>there coding with everybody else. It makes a big difference if a language has
>something built in - which is one of the reasons I'm so keen on D. Loads of the
>good stuff I try to encourage - fully fledged use of contracts (never managed
>it), basic asserts, unit tests automatically run as part of the build process
>(just managed it for the first time on my current project) etc. is part of the
>language in D. The bracketing issue is another such thing.
>
>I can understand that if for example somebody spends most of their time working
>on code that they've written themselves, this kind of thing won't bother them
>too much. Working on large code bases and/or in teams you come across a huge
>variety of bugs - the worst ones always have multiple causes. Any cause that we
>can rule out as part of the language has got to be a good thing.
>
>To take a meta view on this problem, what you have here are two groups of
>people: one whose experience identifies a problem that can easily be fixed,
>another whose experience hasn't found this to be a problem.
>
>The population of D users is made up of these two groups. The population can
>also be split into people who think that the overhead of having to use braces is
>a bad thing and those who don't.
>
>What we need to weigh up is how much the population as a whole would be affected
>1. by lack of brace enforcement and 2. by brace enforcement.
>
>In my experience (which I'll admit is not the same as everybody elses), people
>who wish to have the option of no braces are never that bothered about giving up
>that option once they start doing it, but extra bugs bother everybody.
>
>To summarise my argument:
>- One of D's main strands is robustness (great - gets my vote)
>- One of D's main principals is including features in the core language (great -
>gets my vote)
>- Another of D's main principals is to keep the compiler in mind (great - gets
>my vote)
>- This suggestion fits in with all three of these goals, and doesn't conflict
>with any of D's aims.
>- Some people can see the benefit of this, others not, but just because you
>personally have no experience of this being a problem, doesn't mean it isn't.
>- We need the language to be the best fit for the population as a whole, not any
>particular subgroup. Assuming the target population is identified by the
>language aims/goals as expressed above then it is logical to include this
>change.
>
>I will try not to add any more to this - these arguments do tend to ramble on!
>It would be nice if somebody neutral could summarise the two sides of the
>argument as I have probably been biased by my own experience. Perhaps the
>anti-brace-enforcement guys could summarise their position and we coudl cut and
>paste the two summaries? I was thinking it's worth putting this in the Wiki:
>(http://www.prowiki.org/wiki4d/wiki.cgi?IdeaDiscussion) to avoid the same ground
>being covered over and over.
>
>Cheers
>
>Munch
>
>

I cant believe you actually felt the need to spoon feed us all of that. I know
exactly why you want it, just because I dont find the need to have the compiler
hold my hand doesnt mean I lack the experience to comprehend this oh so complex
issue. I have encountered that before, then I learned, now I dont have those
problems. Personally, I find it almost insulting that you would even suggest
forcing this upon people. But I guess thats me.....
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
In article <1u7tsrb0a3rql$.k8phrfnxfudx$.dlg@40tude.net>, Derek Parnell says...
>
>On Fri, 18 Nov 2005 09:53:12 -0500, clayasaurus wrote:
>> It appears forcing to use {} is dangerously close to having a 'religion' 
>> or 'overriding philosophy,' and yet if it produces more maintainable 
>> code it might be worth it. I'm more on the ledge leaning away from it 
>> however, simply because I couldn't do my favorite 'debug writef' lines 
>> anymore.
>
>That is why I'm saying allow the coder to omit braces but if they do so,
>they also have to tell the compiler that they choosing to do so. This also
>acts as a warning sign to future maintainers.

We should definitely include this in any summary we produce! Good idea. I guess
the objection would be that we could end up with a language *full* of options if
we take this solution as a precedent. Also I guess making it optional increases
compiler complexity. Still, this solution would definitely suit me personally.

Cheers

Munch
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
On Fri, 18 Nov 2005 22:16:29 +0000 (UTC), JT wrote:

> Personally, I find it almost insulting that you would even suggest
> forcing this upon people. But I guess thats me.....

Hang on ... The language already 'forces' a whole lot of stuff on us. 

For example, if I'm coding a function that has no return value, why am I
forced to write 'void' as the return type? If I have an empty /while/
block, why am I forced to write '{};' instead of just ';'? There are plenty
of other examples too. 

The omission of braces is certain statements is just another situation in
which the language designer could have 'forced' a syntax requirement. The
fact that it doesn't is most likely so that people can copy code from C/C++
without having to 'convert' it to D.

-- 
Derek Parnell
Melbourne, Australia
19/11/2005 9:23:35 AM
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
"Derek Parnell" <derek@psych.ward> wrote ...
> On Fri, 18 Nov 2005 22:16:29 +0000 (UTC), JT wrote:
>
>> Personally, I find it almost insulting that you would even suggest
>> forcing this upon people. But I guess thats me.....
>
> Hang on ... The language already 'forces' a whole lot of stuff on us.
>
> For example, if I'm coding a function that has no return value, why am I
> forced to write 'void' as the return type? If I have an empty /while/
> block, why am I forced to write '{};' instead of just ';'? There are 
> plenty
> of other examples too.


Yes: if you forget a return statement, you get a nasty runtime error!

I do wish that would throw an exception instead, with a file and line number 
:-(


> The omission of braces is certain statements is just another situation in
> which the language designer could have 'forced' a syntax requirement. The
> fact that it doesn't is most likely so that people can copy code from 
> C/C++
> without having to 'convert' it to D.

I think you nailed it.
November 19, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
In article <dlljrs$22hs$1@digitaldaemon.com>, JT says...
>I cant believe you actually felt the need to spoon feed us all of that. I know
>exactly why you want it, just because I dont find the need to have the compiler
>hold my hand doesnt mean I lack the experience to comprehend this oh so complex
>issue. I have encountered that before, then I learned, now I dont have those
>problems. Personally, I find it almost insulting that you would even suggest
>forcing this upon people. But I guess thats me.....
>

Well I certainly agree that we've got a high calibre group here - which is nice!
I do apologise if you felt you were being spoon fed, I was merely aiming to be
clear in the presentation of my argument in order to give a useful final summary
of my thoughts.

Again I'm sorry you feel almost insulted at my suggestion, it's intended to help
people rather than restrict freedom. This kind of defensive reaction is reallyh
common though:

In the past I've been responsible for writing coding tips for project coding
teams (yes spoon feeding if you like). What I've found is that most people are
very resistant to the guidelines that I give when I first present them, and
become defensive even before they're presented.... but people come back to me
later (maybe years later) and say "wow you were so right about those coding
tips". The sad thing is that some people just stay defensive and cheat
themselves out of the benefit they could have had. If they find bugs in their
own code which could be avoided by these sorts of rules, they become resentful
and start to want to prove the guidlines wrong. It's seems really wierd to me -
but I'm no psychologist!

What concerns me here: there is a danger of people getting defensive and dug in
and denying a benefit _to_other_users_ as well as themselves. Perhaps this is
because they're not used to dealing with other people's code and so aren't aware
of the impact. If people are faced with debugging something which shows these
sorts of bugs up in _somebody_else's_ code, they tend to become convinced.
That's what I've found anyway =)

I think some people get defensive because they are insecure about their own
ability as a coder, and feel they can't admit that something like
consistently-using-braces will help them. Of course some people are genuinely
brilliant coders, never make any mistakes even when tired and under pressure.
Hopefully such people might have keen enough perception to see that we're not
all like that and perhaps be gracious enough to allow the rest of us mortals the
benefit of the help that they don't need?

Here's hoping =)

Munch
November 19, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
In article <vu98s9vt79vw$.ey82ts0amb11.dlg@40tude.net>, Derek Parnell says...
>The omission of braces is certain statements is just another situation in
>which the language designer could have 'forced' a syntax requirement. The
>fact that it doesn't is most likely so that people can copy code from C/C++
>without having to 'convert' it to D.

Ah yes, now that's an interesting argument. But people aren't gonig to be able
to copy code without running it through a converter first are they? (e.g. due to
the new semantics of "int *i, j;", or const, or switch statements with fall
though clauses, or complicated pointer type declarations etc. to cite a few
examples that spring to mind). Therefore it's just an extra thing to add to the
converter.

In fact given that some of the changes have identical syntax but different
semantics, it would be very dangerous to promote direct copying from C. The
copier could easily end up with some compilable D code which had different
meaning to that intended in the orginal C. Far better then to have features in
the D syntax which allow the compiler to spot sections of copied C and alert the
coder to run them through a converter.

Oh my goodness it's 1 o'clock again.

How does this group suck the time away like that?

Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code

=)
November 19, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
"Munchgreeble" <Munchgreeble_member@pathlink.com> wrote in message

> Oh my goodness it's 1 o'clock again.
>
> How does this group suck the time away like that?

Because it's so much warmer near the computer!

Guessing you're somewhere near Scotland/Ireland/Wales/England ~ it's /cold/ 
there at this time of year.
November 19, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
In article <dllj29$21st$1@digitaldaemon.com>, Kris says...
>
>Yeah; coding styles are a bit like religion to some. I remember a long 
>thread about making the 'override' keyword mandatory (to help with 
>maintenance), but some folks griped miserably about having to type a few 
>extra characters ...
>
>There's no pleasing everyone, I guess.

You're right there! It seems sad that these sorts of complaints wrecked good
ideas like that. Surely we want to make a top level decision of prefering
freedom of expression, or prefering robustness, which everybody can contribute
to, but once the decision is made that can flavour the whole language. Each time
an issue like this comes up you go with the "robustness" or "freedom of
expression" choice as previously decided (unless the default choice has a
separate counter argument, other than the general ones associated with the
"robustness" or "freedom"). Otherwise, you are in danger of ending up with a
designed-by-committee hotch potch which has no clear direction.

Maybe that's putting it a bit too strongly, but it would be nice if all the
language features were pulling in the same direction.

Just my tuppence.

Now I really really must go to bed =)

Night all

Munchgreeble
November 19, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
In article <dllt4i$2akj$1@digitaldaemon.com>, Munchgreeble says...
>I think some people get defensive because they are insecure about their own
>ability as a coder, and feel they can't admit that something like
>consistently-using-braces will help them. Of course some people are genuinely
>brilliant coders, never make any mistakes even when tired and under pressure.
>Hopefully such people might have keen enough perception to see that we're not
>all like that and perhaps be gracious enough to allow the rest of us mortals the
>benefit of the help that they don't need?

How long have you been reading this newsgroup? Have you been lurking at all or
have you actually just arrived?

I'm just suggesting that it's good to listen as well as speak. You've been doing
quite a bit of speaking. You might want to spend some time getting to know the
group dynamic -- before you manage to offend everyone. ;)

I'm not a professional programmer, but I write some code. And I can't remember
ever getting an error by leaving off braces on what I meant to be a block if
statement. I'm not saying it never happened. I've probably been stung by this,
too. I just remember other problems I've had a lot more clearly (such as
forgetting to put breaks in my switch cases). But I really doubt Walter would
change something like this at this point -- especially if it's going to require
him to add brackets all over Phobos sources. And Walter's the one who has to be
sold on it.

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