On 08/05/2008, Janice Caron <caron800@googlemail.com> wrote:
>         magna aliqua
>
>  It sounds like it ought to be feasible.

Except of course that the last line should have been

        magna(aliqua)

But hopefully I conveyed the idea.

terranium wrote:
> Michael Neumann Wrote:
>
>> Another example which leads to hard to read code and potential
>> bugs is (ignoring compiler warnings):
>>
>>      class A
>>      {
>>        int i;
>>
>>        //
>>        // add some 25 lines of code here
>>        //
>>
>>        void foo(int i)
>>        {
>>          // what is "i" here?
>>        }
>>      }
>>
>> This is solved in Ruby by using a separate namespace for instance
>> variables ("@i" for instance variable "i", and "i" for local variable
>> "i").
>
> In C family languages this is ruled out by naming convention.

Which in the case of using a m_ prefix leads to hard(er) to read code.
And then there is no standard naming convention, and who actually uses
such a naming convention? Without that, you can't easily distinguish a
local variable from an instance variable from a global variable.

Regards,

  Michael

Nick Sabalausky wrote:
> "Michael Neumann" <mneumann@ntecs.de> wrote in message
> news:48231B20.1080009@ntecs.de...
>> Actually, IMHO any C-style syntax has much more sever problems leading
>> to hard to find bugs:
>>
>>     if (a)
>>       s1;
>>     s2;
>>
>
> I can't say I've ever found that to be a problem. But maybe that's just me.

Me neither. But it's annoying to have at least 3 different style guidelines for C-style syntaxes.

  if (a) b;

  if (a)
    b;

  if (a) {
    b;
  }

  if (a)
  {
    b;
  }

  if (a)
    {
    b;
    }

  if (a)
    {
      b;
    }

And so on :).

Compare that with how many choices you have when using "if ... end"!

Regards,

  Michael

> Really. You are telling me that is ugly to have a '\' in 0.6% lines of
> code
> but is pretty to have ';' in 100% of them??? It doesn't makes any sense to
> me...
>

I think we're starting to get more into an issue of preferences here, but:

Aside from the fact that ";" is only used on statements that don't end in a "{}" code block, I would have to say: yes, definitely. Personally, I find the rule "A statement is ended by either a semicolon or a curly-brace code block (where applicable)" to be cleaner and more consistent than "Statements end with a newline unless a "\" is used or the compiler is able to infer the statement shouldn't end", plus it allows me to rearrange portions of a long statement for readability without messing with adding/removing/moving "\" operators. Of course, in some cases, I can omit the "\", but that means I have to worry about "Do I need it here, or not?". Which first of all violates "don't make me think", and secondly leads to:

FormatString("This ({}) is a number, and this is a very," \
             "very, very long string. Yes it is, yes it is.",
             thisIsA + (rather() * longComputation) + orAtLeast \
             IAmTrying(toMakeItSo) - (yesIam * 2))

The use of multiple lines in that is very ugly. Of course, this can be solved by either trying to arrange parentheses in a way that side-steps the need for "\" (ie, very kludgey), or by saying "screw it, I'm using '\' on all the lines" (ie, effectively eliminating the "don't need it on parameter lists" feature), or by doing "FormatString(preComputedStr, preComputedValue)" (but why should I have to?)

Also, I've seen a lot of ECMAScript code that has semicolons on some lines and lacks it on others, just on the whim of the coder - that strikes me as very messy. Consistency is pretty.

Regarding remembering the semicolon, I haven't found that to be a problem. I find I do it naturally without even thinking about it, at least whenever I haven't been spending a lot of time in a language like VB which outright forbids semicolons. But even then, the compiler will tell me exactly where I went wrong until I can get the VB out of my head, so no big deal.

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.556.1210267230.2351.digitalmars-d@puremagic.com...
> I wonder if it's possible to write a standalone tool that doesn't know or care about language grammar (except maybe some general rules about what constitutes a quote or a comment), that can freely convert between
>
>    Lorem ipsum (dolor sit amet)
>    {
>        consectetur!(adipisicing)(elit, sed);
(snipped)
>        magna(aliqua);
>    }
>
> and
>
>    Lorem ipsum (dolor sit amet):
>        consectetur!(adipisicing)(elit, sed)
(snipped)
>        magna aliqua
>

I actually like that idea a lot. Although I'd do it like this:

The first line of the source file is something that specifies the style that the file "officially" uses (or, there's just one style that's always the "official" one for the given language). Then, in the development environment, you have a user setting for your style preference. Whenever the "official" style and "user" style don't match, a conversion is performed (via the compiler, or another universally standard command-line tool) on every save and load. Or, better yet, a normal save just saves the "user" version in a separate file, and the "official" version is only generated when you want to compile.

The only potential drawbacks I see is that the converter MUST be very, very reliable. Any bugs in the converter would destroy the whole point of using whichever style you felt aided productivity. It would also have to be fast, much faster than an actual compile.

"Michael Neumann" <mneumann@ntecs.de> wrote in message news:fvvd7r$882$1@digitalmars.com...
> Me neither. But it's annoying to have at least 3 different style guidelines for C-style syntaxes.
>
>   if (a) b;
>
>   if (a)
>     b;
>
>   if (a) {
>     b;
>   }
>
>   if (a)
>   {
>     b;
>   }
>
(snipped)
> And so on :).
>
> Compare that with how many choices you have when using "if ... end"!
>

That's a very good point, I hadn't really thought about that (Personaly, I would want to keep the first two and just merge the rest of them into an "if...end"). Although that is more of a "{}" vs. "end" issue, and not directly related to "with or without semicolon".

"Michael Neumann" <mneumann@ntecs.de> wrote in message news:fvvd1a$7p3$1@digitalmars.com...
> terranium wrote:
> > Michael Neumann Wrote:
> >
> >> Another example which leads to hard to read code and potential
> >> bugs is (ignoring compiler warnings):
> >>
> >>      class A
> >>      {
> >>        int i;
> >>
> >>        //
> >>        // add some 25 lines of code here
> >>        //
> >>
> >>        void foo(int i)
> >>        {
> >>          // what is "i" here?
> >>        }
> >>      }
> >>
> >> This is solved in Ruby by using a separate namespace for instance variables ("@i" for instance variable "i", and "i" for local variable "i").
> >
> > In C family languages this is ruled out by naming convention.
>
> Which in the case of using a m_ prefix leads to hard(er) to read code. And then there is no standard naming convention, and who actually uses such a naming convention? Without that, you can't easily distinguish a local variable from an instance variable from a global variable.
>

In "good" C family languages, the instance variable is referred to by prefixing it with something like "this.". I think there are some that do it differently (ECMAScript, IIRC), but I'd argue those ones are making a big mistake.

However, that does bring up an inconsistancy inherent to the C-style. Following your example, if I do this:

class A{
int i;
void foo(int i) {}
void foo() {}
void bar() {}
}

In that case, "i" means one thing if you're in "foo(int)", and another thing if you're in "foo()" or "bar()". Of course, you could decide to *always* use "this." when referring to an instance variable, but that's kinda long, and you still end up with a hidden bug if you decide to use a local var named "i" and forget to declare it.

There are things about Ruby I don't like, but the @instanceVar syntax is one of the things I think it got spot-on. I would be totally in favor of adopting that.

"Michael Neumann" <mneumann@ntecs.de> wrote in message news:fvv6a4$2sb3$1@digitalmars.com...
> I am sure every C program includes more errors than the worst Ruby/Python program you can ever write. Not so sure about other scripting language... :)
>

C/C++ are probably not good examples. There are plently of other things wrong with C and C++. But, as I like to say, "There's a reason most VB code uses option explicit" (Not that I'm advocating VB).

Michael Neumann Wrote:

> > In C family languages this is ruled out by naming convention.
> 
> Which in the case of using a m_ prefix leads to hard(er) to read code.

Yes, Hungarian prefixes are considered a bad practice in modern C family languages. It was good in old times.

> And then there is no standard naming convention

As to java and .net standard naming convention is provided by standard library.

> and who actually uses such a naming convention?

Those, who care about good programming pactices.

> Without that, you can't easily distinguish a
> local variable from an instance variable from a global variable.

Who is keeping you from using a naming convention?

Janice Caron wrote:
>> Programmer, who got used to one language finds it difficult to switch to another language, because different languages require different styles of thinking. Thus for C programmer it's difficult to understand block statement without braces :) and for basic programmer it's difficult to delimit block statement with braces.
> 
> Ah yes - that's probably true.
> 
> I wonder if it's possible to write a standalone tool that doesn't know
> or care about language grammar (except maybe some general rules about
> what constitutes a quote or a comment), that can freely convert
> between
> 
>     Lorem ipsum (dolor sit amet)
>     {
>         consectetur!(adipisicing)(elit, sed);
>         do
>         {
>             eiusmod tempor incididunt;
>             ut labore;
>             et dolore;
>         }
>         magna(aliqua);
>     }
> 
> and
> 
>     Lorem ipsum (dolor sit amet):
>         consectetur!(adipisicing)(elit, sed)
>         do:
>             eiusmod tempor incididunt
>             ut labore
>             et dolore
>         magna aliqua
> 
> If so, we can have not only D-in-Python-style (which I'd never use),
> but also Python-in-D-style (which I actually might). It sounds like it
> ought to be feasible.

I have translated the passages above from Cicero's Latin and it says:

"It is a pleasure to read everybody's views about language coding
conventions but it is painful to realize that some people believe that
they know the one perfect way of using syntax and indentation."

That 'do' in there was causing a problem, since I could not find the
Latin equivalent, but I took it as Cicero's singing the beginning of "do
re mi..." in his Roman bath while he was composing his learned treatises
on computer language morality.