digitalmars.D - Re: why ; ?
- terranium <spam here.lot> May 09 2008
- "Nick Sabalausky" <a a.a> May 09 2008
- "Janice Caron" <caron800 googlemail.com> May 09 2008
- Matti Niemenmaa <see_signature for.real.address> May 09 2008
- "Nick Sabalausky" <a a.a> May 09 2008
Michael Neumann Wrote:if (a) { b; } if (a) { b; }
and this is called a coding style :)
May 09 2008
"terranium" <spam here.lot> wrote in message news:g01okr$1r0c$1 digitalmars.com...Michael Neumann Wrote:if (a) { b; } if (a) { b; }
and this is called a coding style :)
My preferred coding style has been:if (a) { b; }
...just because the curley braces line up. But, lately, I've been tempted by the compactness of:if (a) { b; }
However, (after Michael Neumann convinced me in another post) I would much prefer to not have to even deal with that particular coding style issue in the first place (Ie, Don't make me make insignificant choices. It doesn't matter if you put the receipt in the bag, or hand it to me: don't make me choose.) This eliminates the entire reason to make a decision (and keeps everyone using one consistent style *without* forcing anyone to "do curley braces THIS way"): if (a) b; c; end Plus, that then opens up the ability to do something like this: while (a) if (b) c; d; fi // Or _if, or something else wend // or _while, or something else (but please, not "end while"...way too long) I used to dislike that, but the benefit is I no longer have giant unreadable chunks of: } } } } // Etc.. LISCB (lost in stupid curley braces), anyone? ;) I once saw someone that had a style of commenting the ending braces with what the block was. I tried to adopt that, but found that I rarely ended up doing it unless the language forced me to.
May 09 2008
On 09/05/2008, Nick Sabalausky <a a.a> wrote:Plus, that then opens up the ability to do something like this: while (a) if (b) c; d; fi // Or _if, or something else wend // or _while, or something else
But my text editor can do bracket matching. With one keystroke, I can jump from an opening brace to the matching closing brace, or vice versa, and /know/ that all is correctly matched (or easily fix the problem if not). My text editor, however, cannot do if-to-fi matching. Under your scheme, I'd be giving up a valuable piece of functionality.
May 09 2008
Matti Niemenmaa <see_signature for.real.address> Janice Caron wrote:On 09/05/2008, Nick Sabalausky <a a.a> wrote:Plus, that then opens up the ability to do something like this: while (a) if (b) c; d; fi // Or _if, or something else wend // or _while, or something else
But my text editor can do bracket matching. With one keystroke, I can jump from an opening brace to the matching closing brace, or vice versa, and /know/ that all is correctly matched (or easily fix the problem if not). My text editor, however, cannot do if-to-fi matching. Under your scheme, I'd be giving up a valuable piece of functionality.
That's a flaw in the text editor, not his scheme. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
May 09 2008
"Janice Caron" <caron800 googlemail.com> wrote in message news:mailman.569.1210359943.2351.digitalmars-d puremagic.com...On 09/05/2008, Nick Sabalausky <a a.a> wrote:Plus, that then opens up the ability to do something like this: while (a) if (b) c; d; fi // Or _if, or something else wend // or _while, or something else
But my text editor can do bracket matching. With one keystroke, I can jump from an opening brace to the matching closing brace, or vice versa, and /know/ that all is correctly matched (or easily fix the problem if not).
True, but under my proposal, you usually wouldn't need to do even that . You would just see them there (albiet, with less detail). Also, that only works for one block at a time. Example scenario: Suppose I have a function that iterates over a collection, and does it over and over until some condition is met. Then, I want to add one last bit of processing to be done as the final action on each element of the collection. If the last few lines of my function look like this: _func // (ie, an anonymous closure) _if _foreach _if _while _if _func I know at a glance to put my code right before "_foreach". But if it looks like this: } } } } } } } Then I have to jump to find the right place. And depending on the function, I might have to try a few braces before I get the right one. Or, I could scroll to the start of the desired loop, and jump down from there. But still, why do that, when I could just know at a mere glance where to put the code? You could argue that a scenario like that is the result of an overly-large function that should be broken into smaller parts, and you'd probably be right. But, at least in my experience, it's typical for a function to start small, then later on, grow large and *then* get broken up as necessary. Plus it might not even be your function anyway. I'm not saying that this could effectively replace bracket matching in a text editor. But I do think "fi"/"wend" *plus* bracket matching would be better than "a bunch of }'s" plus bracket matching. I think they'd compliment each other nicely (And the "fi"/"wend" would also be better when someone's not using bracket-matching).My text editor, however, cannot do if-to-fi matching. Under your scheme, I'd be giving up a valuable piece of functionality.
I'd classify that as a limitation in the editor. Most editors let you manually define a list of language keywords. I can't imagine it would be significantly more difficult for an editor that already handles both user-defined keywords and non-configurable bracket matching (or collapsable regions), to expose the tokens it uses for bracket matching as configurable. Ie, "(",")" as well as "{", "}", and "[","]" would already be set by default, and you could either remove those and/or add pairs like "if","fi", or "spoogystart","spoogyend".
May 09 2008