• 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 :)

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

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.

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

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