June 25, 2006
On Sat, 24 Jun 2006 18:39:54 +0800, Boris Wang <nano.kago@hotmail.com> wrote:
> What you said is that, i can't has a good feeling about reading your
> program, just because i has not such  a editor?
>
> In other words, you force the other readers to use the editor you use?

How is that any different to you forcing people to code using the forms you prefer?
Even without an editor that collapses : and {} I find Dereks example easier to read.

Regan

> "Derek Parnell" <derek@psych.ward> дÈëÏûÏ¢ÐÂÎÅ:op.tbml4bwn6b8z09@ginger.vic.bigpond.net.au...
>> On Sat, 24 Jun 2006 10:22:00 +1000, Boris Wang <nano.kago@hotmail.com>
>> wrote:
>>
>>> And this is what ?
>>>
>>>>
>>>>       // six pages
>>>>      ...
>>>>
>>>>        int func3(...)
>>>>        {
>>>>        }
>>>>        int func4(...)
>>>>        {
>>>>        }
>>>>        int func5(...)
>>>>        {
>>>>        }
>>>>        int func6(...)
>>>>        {
>>>>        }
>>>>        int func7(...)
>>>>        {
>>>>        }
>>>>        a_type var2;
>>>>     }
>>>>     int func2(...)
>>>>     {
>>>>     }
>>>>     a_type var4;
>>>>     int func5(...)
>>>>     {
>>>>     }
>>>> }
>>
>> Excellent, that is what it is. To find out whether it is
>> public/private/static/version/debug effected, place your cursor on the
>> final "}" and press ctrl-[ to jump to the matching brace. This assumes you
>> are using Crimson Editor of course ;-)
>>
>> The point is, writing organised and predicatable code is less costly in
>> the long run. We also have access to tools (i.e good editors) that can
>> help us.
>>
>> --
>> Derek Parnell
>> Melbourne, Australia
>
>

June 25, 2006
On Sat, 24 Jun 2006 18:52:08 +0800, Boris Wang <nano.kago@hotmail.com> wrote:
> And this is what ?

In Dereks example the protection attribute applied to all 6 pages is the one written above them, that attribute is simple to find, and simple to remember while reading the latter 6 pages. I find it far easier to read than:


 private a_type var1;
 public static a_type var2;
 public static int func1(...)
 {
 }
 private a_type var3;
 public int func2(...)
 {
 }
 private static int func3(...)
 {
 }
 public a_type var4;
 private a_type var5;
 public static int func4(...)
 {
 }
 private static a_type var6;
 private a_type var7;
 public int func5(...)
 {
 }
 private a_type var8;

 private int func6(...)
 {
 }

where I have to filter out all the redundant 'private' etc text in order to see the _actual_ code, the code which actually does something.

> If you can make a good enough solution for this problem, i'll give up.

Dereks example is how _I_ (and Derek perhaps) would write it, the code above is how _you_ would write it. Neither form is _incorrect_ it's simply a matter of personal preference.

>> private int var;
>>
>> public int func( .. )
>> {
>> }
>
> this syntax has no other problem, except that some people don't like it.

This syntax forces the use of redundant 'public' etc text, which _I_ find clutters the view and obscures and obfuscates the important parts of the code.

> The codes of mango project is more beatiful than the others i readed.

Each to their own (which is the point I am trying to make).

Regan

June 25, 2006
"Derek Parnell" <derek@psych.ward> дÈëÏûÏ¢ÐÂÎÅ:op.tbndxng06b8z09@ginger.vic.bigpond.net.au...
> On Sat, 24 Jun 2006 20:52:08 +1000, Boris Wang <nano.kago@hotmail.com> wrote:
>
>> And this is what ?
>>
>>>
>>>       // six pages
>>>      ...
>>>
>>>        int func3(...)
>>>        {
>>>        }
>>>        int func4(...)
>>>        {
>>>        }
>>>        int func5(...)
>>>        {
>>>        }
>>>        int func6(...)
>>>        {
>>>        }
>>>        int func7(...)
>>>        {
>>>        }
>>>        a_type var2;
>>>     }
>>>     int func2(...)
>>>     {
>>>     }
>>>     a_type var4;
>>>     int func5(...)
>>>     {
>>>     }
>>> }
>>
>> If you can make a good enough solution for this problem, i'll give up.
>
> The problem you highlight with this example does not go away with either style of coding, because without seeing the code at the matching open brace, you can't tell what the scope of the contents is. For example, your example could begin with ...
>
>   private void xfunc() {
>
> making all the functions nested and thus sort of private. Without actually looking, you can't tell from just seeing the end of a braced code snippet.
>
>>> private int var;
>>>
>>> public int func( .. )
>>> {
>>> }
>>
>> this syntax has no other problem, except that some people don't like it.
>
> Oh well! Get used to the idea of free choice. Coders have been given the opportunity to code using the style that find helpful or best expresses their frame of mind. And that is not intrinsically a bad thing. I won't force my style on you and I expect that you won't force your style on me, okay?
>

I don't dislike each style syntax, except the problem i talk about.

What we discussed here, is not what you like or i like, if you really love D.


>> The codes of mango project is more beatiful than the others i readed.
>
> Yes, it is lovely code and easy to read. Well done Mango team. A lot of that has got to do with adhering to coding standards regardless of what those standards are.
>

Hmm, you have admit that the syntax without colon and curly braces can produce readable and maintainable codes.

But, the syntax with colon or curly braces,  has the problem of expansibility.




> -- 
> Derek Parnell
> Melbourne, Australia


June 25, 2006
In article <optbof6t0b23k2f5@nrage>, Regan Heath says...
>
>  private a_type var1;
>  public static a_type var2;
>  public static int func1(...)
>  {
>  }
>  private a_type var3;
>  public int func2(...)
>  {
>  }
>  private static int func3(...)
>  {
>  }
>  public a_type var4;
>  private a_type var5;
>  public static int func4(...)
>  {
>  }
>  private static a_type var6;
>  private a_type var7;
>  public int func5(...)
>  {
>  }
>  private a_type var8;
>
>  private int func6(...)
>  {
>  }
>

This is a terribly biased example against individual protection attributes, because that code is organized so poorly. Its illogical to assume that people who put a protection attributes on each field/function just randomly glop their code together like in your example. I use individual protection attributes, yet I still structure my code so the private functions are in one area and the public ones in another.


June 25, 2006
On Sun, 25 Jun 2006 13:07:14 +1000, Ben Phillips <Ben_member@pathlink.com> wrote:

> In article <optbof6t0b23k2f5@nrage>, Regan Heath says...
>>
>>  private a_type var1;
>>  public static a_type var2;
>>  public static int func1(...)
>>  {
>>  }
>>  private a_type var3;
>>  public int func2(...)
>>  {
>>  }
>>  private static int func3(...)
>>  {
>>  }
>>  public a_type var4;
>>  private a_type var5;
>>  public static int func4(...)
>>  {
>>  }
>>  private static a_type var6;
>>  private a_type var7;
>>  public int func5(...)
>>  {
>>  }
>>  private a_type var8;
>>
>>  private int func6(...)
>>  {
>>  }
>>
>
> This is a terribly biased example against individual protection attributes,
> because that code is organized so poorly. Its illogical to assume that people
> who put a protection attributes on each field/function just randomly glop their
> code together like in your example. I use individual protection attributes, yet
> I still structure my code so the private functions are in one area and the
> public ones in another.

Yes, I did purposely exagerate the issue. But is this really any more readable? ...

  private a_type var1;
  private a_type var8;
  private int func6(...)
  {
  }
  private a_type var3;
  private a_type var5;
  private a_type var7;
  private static int func3(...)
  {
  }
  private static a_type var6;
  public int func5(...)
  {
  }
  public int func2(...)
  {
  }
  public a_type var4;
  public static a_type var2;
  public static int func1(...)
  {
  }
  public static int func4(...)
  {
  }


I know its a personal taste question, but to me it has too many 'noise' words in it that makes it harder to read and write.

  private {
    a_type var1;
    a_type var8;
    a_type var3;
    a_type var5;
    a_type var7;
    int func6(...)
    {
    }
    static {
      int func3(...)
      {
      }
      a_type var6;
    }
  }

  public {
    a_type var4;
    int func5(...)
    {
    }
    int func2(...)
    {
    }
    static {
      a_type var2;
      int func1(...)
      {
      }
      int func4(...)
      {
      }
    }
  }

just seems neater and more likely to be correctly read and maintained.

Anyhow, I've finished with this topic. Thanks for indulging my ravings.

-- 
Derek Parnell
Melbourne, Australia
June 25, 2006
On Sun, 25 Jun 2006 12:28:40 +1000, Boris Wang <nano.kago@hotmail.com> wrote:

>>> The codes of mango project is more beatiful than the others i readed.
>>
>> Yes, it is lovely code and easy to read. Well done Mango team. A lot of
>> that has got to do with adhering to coding standards regardless of what
>> those standards are.
>>
>
> Hmm, you have admit that the syntax without colon and curly braces can
> produce readable and maintainable codes.

Yes it can, inspite of being a poorer choice. Just think how much nicer the code could be if they used the alternative coding sytle.

-- 
Derek Parnell
Melbourne, Australia
1 2 3 4
Next ›   Last »