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
>> 

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.....

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

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

"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.

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

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

=)

"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.

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

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