www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - appeal again: discard the syntax of private:, public: static: private{}, public{}, static{}.

reply "Boris Wang" <nano.kago hotmail.com> writes:
the harm of these is more than the benefit.

all these syntax produce non-readable, non-maintainable codes, and even more 
in large project with many developers.
Jun 23 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago hotmail.com>  
wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and even  
 more in large project with many developers.


My vote is against removing these. I use them and prefer the : syntax for  
private etc within class/struct declarations.

Regan
Jun 23 2006
parent reply xs0 <xs0 xs0.com> writes:
Regan Heath wrote:

 On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago hotmail.com> 
 wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and 
 even more in large project with many developers.


 
 My vote is against removing these. I use them and prefer the : syntax 
 for private etc within class/struct declarations.


My vote is against having either public: or public {} :)

With both you can't see what applies to a declaration from the 
declaration alone, but have to scan backwards for an arbitrary amount of 
lines..


xs0
Jun 23 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 23 Jun 2006 11:48:57 +0200, xs0 <xs0 xs0.com> wrote:

 Regan Heath wrote:

 On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago hotmail.com>  
 wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and  
 even more in large project with many developers.


  My vote is against removing these. I use them and prefer the : syntax  
 for private etc within class/struct declarations.


 My vote is against having either public: or public {} :)

 With both you can't see what applies to a declaration from the  
 declaration alone, but have to scan backwards for an arbitrary amount of  
 lines..


That doesn't bother me in the slightest (which is why I don't want them  
removed). I simply group all the public, protected and private methods  
together and use the : syntax. I can mostly tell from method name and  
context which access specifier any given function has (or should have) and  
the syntax is mostly for the compiler benefit, not mine. I definately do  
not want to have to put private etc in front of every single function  
declaration.

Regan
Jun 23 2006
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 24 Jun 2006 11:25:19 +1200, Regan Heath <regan netwin.co.nz> wrote:

 On Fri, 23 Jun 2006 11:48:57 +0200, xs0 <xs0 xs0.com> wrote:

 Regan Heath wrote:

 On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago hotmail.com>  
 wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and  
 even more in large project with many developers.


  My vote is against removing these. I use them and prefer the : syntax  
 for private etc within class/struct declarations.


 My vote is against having either public: or public {} :)

 With both you can't see what applies to a declaration from the  
 declaration alone, but have to scan backwards for an arbitrary amount  
 of lines..


 That doesn't bother me in the slightest (which is why I don't want them  
 removed). I simply group all the public, protected and private methods  
 together and use the : syntax. I can mostly tell from method name and  
 context which access specifier any given function has (or should have)  
 and the syntax is mostly for the compiler benefit, not mine. I  
 definately do not want to have to put private etc in front of every  
 single function declaration.


Here I am talking about within class declarations, for module scope I  
either use the {} form or if I only have 1 thing or several which are not  
'conceptually' grouped I apply protection individually (much like Daniel  
Keep suggested in his reply to this thread)

Regan
Jun 23 2006
prev sibling parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"Regan Heath" <regan netwin.co.nz> ??????:optbmgohdr23k2f5 nrage...

 On Fri, 23 Jun 2006 11:48:57 +0200, xs0 <xs0 xs0.com> wrote:

 Regan Heath wrote:

 On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago hotmail.com> 
 wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and 
 even more in large project with many developers.


  My vote is against removing these. I use them and prefer the : syntax 
 for private etc within class/struct declarations.


 My vote is against having either public: or public {} :)

 With both you can't see what applies to a declaration from the 
 declaration alone, but have to scan backwards for an arbitrary amount of 
 lines..


 That doesn't bother me in the slightest (which is why I don't want them 
 removed). I simply group all the public, protected and private methods 
 together and use the : syntax. I can mostly tell from method name and 
 context which access specifier any given function has (or should have) and 
 the syntax is mostly for the compiler benefit, not mine. I definately do 
 not want to have to put private etc in front of every single function 
 declaration.

 Regan


There are many coding style here already!

Please remember, we must speek English here for communion, and not the 
mother-language of you.

D should be a professional language for all the programmer, not a toy of 
someone.

At last, there is no heaven for everyone.
Jun 23 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 24 Jun 2006 08:36:52 +0800, Boris Wang <nano.kago hotmail.com>  
wrote:

 "Regan Heath" <regan netwin.co.nz> ??????:optbmgohdr23k2f5 nrage...

 On Fri, 23 Jun 2006 11:48:57 +0200, xs0 <xs0 xs0.com> wrote:

 Regan Heath wrote:

 On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago hotmail.com>
 wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and
 even more in large project with many developers.


  My vote is against removing these. I use them and prefer the : syntax
 for private etc within class/struct declarations.


 My vote is against having either public: or public {} :)

 With both you can't see what applies to a declaration from the
 declaration alone, but have to scan backwards for an arbitrary amount  
 of
 lines..


 That doesn't bother me in the slightest (which is why I don't want them
 removed). I simply group all the public, protected and private methods
 together and use the : syntax. I can mostly tell from method name and
 context which access specifier any given function has (or should have)  
 and
 the syntax is mostly for the compiler benefit, not mine. I definately do
 not want to have to put private etc in front of every single function
 declaration.

 Regan


 There are many coding style here already!

 Please remember, we must speek English here for communion, and not the
 mother-language of you.

 D should be a professional language for all the programmer, not a toy of
 someone.

 At last, there is no heaven for everyone.


Sorry, I don't understand what you're trying to say.

Regan
Jun 24 2006
prev sibling parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"xs0" <xs0 xs0.com> ??????:e7gddu$26gk$1 digitaldaemon.com...

 Regan Heath wrote:

 On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago hotmail.com> 
 wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and even 
 more in large project with many developers.


 My vote is against removing these. I use them and prefer the : syntax for 
 private etc within class/struct declarations.


 My vote is against having either public: or public {} :)

 With both you can't see what applies to a declaration from the declaration 
 alone, but have to scan backwards for an arbitrary amount of lines..


Just because these reason.

private a_type var;

public static int func(...)
{
}

this syntax is simple, clean and enough.


 xs0
Jun 23 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Fri, 23 Jun 2006 21:21:35 +1000, Boris Wang <nano.kago hotmail.com>  
wrote:


 "xs0" <xs0 xs0.com> ??????:e7gddu$26gk$1 digitaldaemon.com...

 Regan Heath wrote:

 On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago hotmail.com>
 wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and  
 even
 more in large project with many developers.


 My vote is against removing these. I use them and prefer the : syntax  
 for
 private etc within class/struct declarations.


 My vote is against having either public: or public {} :)

 With both you can't see what applies to a declaration from the  
 declaration
 alone, but have to scan backwards for an arbitrary amount of lines..


 Just because these reason.

 private a_type var;

 public static int func(...)
 {
 }

 this syntax is simple, clean and enough.


And this is what ...?

  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(...)
  {
  }

Compared to ...

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

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


-- 
Derek Parnell
Melbourne, Australia
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
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(...)
     {
     }
 }


"Derek Parnell" <derek psych.ward>
写入消息新闻:op.tbmhl9lt6b8z09 ginger.vic.bigpond.net.au...

 On Fri, 23 Jun 2006 21:21:35 +1000, Boris Wang <nano.kago hotmail.com> 
 wrote:


 "xs0" <xs0 xs0.com> ??????:e7gddu$26gk$1 digitaldaemon.com...

 Regan Heath wrote:

 On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago hotmail.com>
 wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and 
 even
 more in large project with many developers.


 My vote is against removing these. I use them and prefer the : syntax 
 for
 private etc within class/struct declarations.


 My vote is against having either public: or public {} :)

 With both you can't see what applies to a declaration from the 
 declaration
 alone, but have to scan backwards for an arbitrary amount of lines..


 Just because these reason.

 private a_type var;

 public static int func(...)
 {
 }

 this syntax is simple, clean and enough.


 And this is what ...?

  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(...)
  {
  }

 Compared to ...

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

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


 -- 
 Derek Parnell
 Melbourne, Australia
Jun 23 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
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
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
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?

"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
Jun 24 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
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
Jun 24 2006
prev sibling next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Fri, 23 Jun 2006 19:05:15 +1000, Boris Wang <nano.kago hotmail.com>  
wrote:


 the harm of these is more than the benefit.


Why?


 all these syntax produce non-readable, non-maintainable codes, and even  
 more in large project with many developers.


Have you evidence or rationale for that position?

I would argue strongly against removing these. My preference is to avoid  
the ':' form and nearly always use the '{}' form. I use the 'public'  
option as a documentation tool plus I hope that one day the 'private'  
option will be the default.

-- 
Derek Parnell
Melbourne, Australia
Jun 23 2006
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Boris Wang wrote:

 the harm of these is more than the benefit.


I disagree. I like them and do not want to see them go away.


 
 all these syntax produce non-readable, non-maintainable codes, and even more 
 in large project with many developers. 
 
 


That's why large teams have coding standards. If you are going to work 
on a large project and something is unreadable to you, make sure your 
coding standards prohibit it. You'll still have to deal with it when 
modifying third party code, but there's nothing you can do about it.

I find the syntax quite readable and have no trouble with it. So I 
strongly appeal that it not be removed.
Jun 23 2006
parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Mike Parker wrote:


 Boris Wang wrote:

 the harm of these is more than the benefit.


 
 I disagree. I like them and do not want to see them go away.
 

 
 all these syntax produce non-readable, non-maintainable codes, and even
 more  in large project with many developers.


 That's why large teams have coding standards. If you are going to work on a
 large project and something is unreadable to you, make sure your coding
 standards prohibit it. You'll still have to deal with it when modifying third
 party code, but there's nothing you can do about it.
 
 I find the syntax quite readable and have no trouble with it. So I strongly
 appeal that it not be removed.


I agree with you.

"public:" and "private:" sections visually separate interface and
implementation.
And if you want you can always establish coding standards for either option.


-- 
AKhropov
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"Andrei Khropov" <andkhropov nospam_mtu-net.ru> 
??????:e7gs64$2ucq$1 digitaldaemon.com...

 Mike Parker wrote:


 Boris Wang wrote:

 the harm of these is more than the benefit.


 I disagree. I like them and do not want to see them go away.


 all these syntax produce non-readable, non-maintainable codes, and even
 more  in large project with many developers.


 That's why large teams have coding standards. If you are going to work on 
 a
 large project and something is unreadable to you, make sure your coding
 standards prohibit it. You'll still have to deal with it when modifying 
 third
 party code, but there's nothing you can do about it.

 I find the syntax quite readable and have no trouble with it. So I 
 strongly
 appeal that it not be removed.


 I agree with you.

 "public:" and "private:" sections visually separate interface and
 implementation.
 And if you want you can always establish coding standards for either 
 option.


In much C++ codes, the declaration and defination of a function is 
seperated, this is the main reason of colon-like syntax.

Otherwize, in no case can Bjarne Stroustrup make the colon-like syntax.




 -- 
 AKhropov
Jun 23 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 24 Jun 2006 07:43:26 +0800, Boris Wang <nano.kago hotmail.com>  
wrote:

 "Andrei Khropov" <andkhropov nospam_mtu-net.ru>
 ??????:e7gs64$2ucq$1 digitaldaemon.com...

 Mike Parker wrote:


 Boris Wang wrote:

 the harm of these is more than the benefit.


 I disagree. I like them and do not want to see them go away.


 all these syntax produce non-readable, non-maintainable codes, and  


 even

 more  in large project with many developers.


 That's why large teams have coding standards. If you are going to work  
 on
 a
 large project and something is unreadable to you, make sure your coding
 standards prohibit it. You'll still have to deal with it when modifying
 third
 party code, but there's nothing you can do about it.

 I find the syntax quite readable and have no trouble with it. So I
 strongly
 appeal that it not be removed.


 I agree with you.

 because
 "public:" and "private:" sections visually separate interface and
 implementation.
 And if you want you can always establish coding standards for either
 option.


 In much C++ codes, the declaration and defination of a function is
 seperated, this is the main reason of colon-like syntax.

 Otherwize, in no case can Bjarne Stroustrup make the colon-like syntax.


I don't think you can make that assertion.

Like several people have said both the : and {} syntax are useful to group  
things together. That alone is reason enough to use them in C++ and indeed  
that is why/how I use them.

Like Derek has just shown (to my mind) the {} syntax makes a cleaner,  
easier to read example, and further many editors will help further by  
highlighting/finding and collapsing blocks declared with either : or {}  
something that simply isn't possible if you specify them all in every case.

Regan
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
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.


 private int var;

 public int func( .. )
{
}


this syntax has no other problem, except that some people don't like it.

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


"Regan Heath" <regan netwin.co.nz> ??????:optbmn7svj23k2f5 nrage...

 On Sat, 24 Jun 2006 07:43:26 +0800, Boris Wang <nano.kago hotmail.com> 
 wrote:

 "Andrei Khropov" <andkhropov nospam_mtu-net.ru>
 ??????:e7gs64$2ucq$1 digitaldaemon.com...

 Mike Parker wrote:


 Boris Wang wrote:

 the harm of these is more than the benefit.


 I disagree. I like them and do not want to see them go away.


 all these syntax produce non-readable, non-maintainable codes, and


 even

 more  in large project with many developers.


 That's why large teams have coding standards. If you are going to work 
 on
 a
 large project and something is unreadable to you, make sure your coding
 standards prohibit it. You'll still have to deal with it when modifying
 third
 party code, but there's nothing you can do about it.

 I find the syntax quite readable and have no trouble with it. So I
 strongly
 appeal that it not be removed.


 I agree with you.

 because
 "public:" and "private:" sections visually separate interface and
 implementation.
 And if you want you can always establish coding standards for either
 option.


 In much C++ codes, the declaration and defination of a function is
 seperated, this is the main reason of colon-like syntax.

 Otherwize, in no case can Bjarne Stroustrup make the colon-like syntax.


 I don't think you can make that assertion.

 Like several people have said both the : and {} syntax are useful to group 
 things together. That alone is reason enough to use them in C++ and indeed 
 that is why/how I use them.

 Like Derek has just shown (to my mind) the {} syntax makes a cleaner, 
 easier to read example, and further many editors will help further by 
 highlighting/finding and collapsing blocks declared with either : or {} 
 something that simply isn't possible if you specify them all in every 
 case.

 Regan
Jun 24 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
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?


 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.

-- 
Derek Parnell
Melbourne, Australia
Jun 24 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"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
Jun 24 2006
parent "Derek Parnell" <derek psych.ward> writes:
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
Jun 24 2006
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jun 24 2006
parent reply Ben Phillips <Ben_member pathlink.com> writes:
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.
Jun 24 2006
parent "Derek Parnell" <derek psych.ward> writes:
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
Jun 24 2006
prev sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Boris Wang wrote:


 
 "Andrei Khropov" <andkhropov nospam_mtu-net.ru>
 ??????:e7gs64$2ucq$1 digitaldaemon.com...

 Mike Parker wrote:
 

 Boris Wang wrote:

 the harm of these is more than the benefit.


 
 I disagree. I like them and do not want to see them go away.
 

 
 all these syntax produce non-readable, non-maintainable codes, and even
 more  in large project with many developers.


 That's why large teams have coding standards. If you are going to work on
 a large project and something is unreadable to you, make sure your coding
 standards prohibit it. You'll still have to deal with it when modifying
 third party code, but there's nothing you can do about it.
 
 I find the syntax quite readable and have no trouble with it. So I
 strongly appeal that it not be removed.


 
 I agree with you.

 "public:" and "private:" sections visually separate interface and
 implementation.
 And if you want you can always establish coding standards for either
 option.
 


 
 In much C++ codes, the declaration and defination of a function is seperated,
 this is the main reason of colon-like syntax.
 
 Otherwize, in no case can Bjarne Stroustrup make the colon-like syntax.


Well, I tend to agree with you.

But data declaration with group modifiers seems clearer to me anyway.
So I think it is good to have both styles.

-- 
AKhropov
Jun 24 2006
prev sibling next sibling parent reply Daniel Keep <daniel.keep.list gmail.com> writes:
Boris Wang wrote:

 the harm of these is more than the benefit.
 
 all these syntax produce non-readable, non-maintainable codes, and even more 
 in large project with many developers. 


Have you seen the International Obfuscated C Code Competition?  By your 
rationale, then the entire C language is evil, and thus by extension, 
most of D is evil.  Given enough time and incentive, you can write 
totally unreadable code in almost anything.

Can you abuse "protection:" and "protection{}"?  Of course you can!  But 
that's not the point.  You can abuse aliases as well.  You can abuse 
pointers.  You can abuse arrays and hashes.  You can abuse the ability 
to choose your own variable names, operator overloading, classes, 
functions... just about anything.

Just because you don't agree with something, can't immediately see its 
benefit, or can't use it properly yourself doesn't mean it should be 
removed.

I personally use all three forms.  I habitually divide my classes into 
clear sections based on who is using them.  Public section first so 
people can read the top of the class for a quick reference, protected 
next for people overriding the class, and public last for internal 
details.  Marking each one seperately would be a pain, and the off-side 
"public:", "protected:" and "private:" help delineate the sections.

I use the braces form for, for example, grouping together small bunches 
of declarations at module level.  When I write my module imports, they 
look like this:







Should I be forced to write all these out long-hand because you don't 
like that form?  You claim that these produce unreadable code, and 
whilst they COULD be abused, they also help me keep MY code more organised.

Should we have all Perl coders shot on sight?  Don't be silly :)

Regards,

	-- Daniel
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"Daniel Keep" <daniel.keep.list gmail.com> 
??????:e7grur$2tq6$1 digitaldaemon.com...

 Boris Wang wrote:

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and even 
 more in large project with many developers.


 Have you seen the International Obfuscated C Code Competition?  By your 
 rationale, then the entire C language is evil, and thus by extension, most 
 of D is evil.  Given enough time and incentive, you can write totally 
 unreadable code in almost anything.

 Can you abuse "protection:" and "protection{}"?  Of course you can!  But 
 that's not the point.  You can abuse aliases as well.  You can abuse 
 pointers.  You can abuse arrays and hashes.  You can abuse the ability to 
 choose your own variable names, operator overloading, classes, 
 functions... just about anything.


NO,NO. I am a programmer of C ,about fifteen years. i like C.



 Just because you don't agree with something, can't immediately see its 
 benefit, or can't use it properly yourself doesn't mean it should be 
 removed.

 I personally use all three forms.  I habitually divide my classes into 
 clear sections based on who is using them.  Public section first so people 
 can read the top of the class for a quick reference, protected next for 
 people overriding the class, and public last for internal details. 
 Marking each one seperately would be a pain, and the off-side "public:", 
 "protected:" and "private:" help delineate the sections.


The key is that your's pleasure is the suffering of other people!


 I use the braces form for, for example, grouping together small bunches of 
 declarations at module level.  When I write my module imports, they look 
 like this:







 Should I be forced to write all these out long-hand because you don't like 
 that form?  You claim that these produce unreadable code, and whilst they 
 COULD be abused, they also help me keep MY code more organised.

 Should we have all Perl coders shot on sight?  Don't be silly :)

 Regards,

 -- Daniel
Jun 23 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 24 Jun 2006 07:55:54 +0800, Boris Wang <nano.kago hotmail.com>  
wrote:

 The key is that your's pleasure is the suffering of other people!


The exact same thing can be said right back at you! :)
Regan
Jun 23 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Boris Wang" <nano.kago hotmail.com> wrote in message 
news:e7gau0$22li$1 digitaldaemon.com...

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and even 
 more in large project with many developers.


While I agree with your argument and personally always use per-member 
protection, other people obviously still like the other methods.

What might be a bit of a compromise would be to get rid of : and keep {}, 
since : has some issues (how do you turn off static, for example?).  {} at 
least introduces a sort of "segment" of code, and makes it possible to see 
when the attributes end.  With good indentation, and a good text editor, you 
can always find what protectection and storage class something is.

class A
{
    // The public "segment"
    public
    {
        method
        field..
        blah
    }

    // Any public static fields
    public static
    {

    }

    // Hidden stuff
    protected
    {

    }
}

Not that terrible.
Jun 23 2006
parent reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:e7gsnn$2vhj$1 digitaldaemon.com...

 "Boris Wang" <nano.kago hotmail.com> wrote in message 
 news:e7gau0$22li$1 digitaldaemon.com...

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and even 
 more in large project with many developers.


 While I agree with your argument and personally always use per-member 
 protection, other people obviously still like the other methods.

 What might be a bit of a compromise would be to get rid of : and keep {}, 
 since : has some issues (how do you turn off static, for example?).  {} at 
 least introduces a sort of "segment" of code, and makes it possible to see 
 when the attributes end.  With good indentation, and a good text editor, 
 you can always find what protectection and storage class something is.

 class A
 {
    // The public "segment"
    public
    {
        method
        field..
        blah
    }

    // Any public static fields
    public static
    {

    }

    // Hidden stuff
    protected
    {

    }
 }

 Not that terrible.


I like it.  It's much more direct than using : syntax IMO.
Jun 23 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 23 Jun 2006 11:20:08 -0400, Ameer Armaly  
<ameer_armaly hotmail.com> wrote:


 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
 news:e7gsnn$2vhj$1 digitaldaemon.com...

 "Boris Wang" <nano.kago hotmail.com> wrote in message
 news:e7gau0$22li$1 digitaldaemon.com...

 the harm of these is more than the benefit.

 all these syntax produce non-readable, non-maintainable codes, and even
 more in large project with many developers.


 While I agree with your argument and personally always use per-member
 protection, other people obviously still like the other methods.

 What might be a bit of a compromise would be to get rid of : and keep  
 {},
 since : has some issues (how do you turn off static, for example?).  {}  
 at
 least introduces a sort of "segment" of code, and makes it possible to  
 see
 when the attributes end.  With good indentation, and a good text editor,
 you can always find what protectection and storage class something is.

 class A
 {
    // The public "segment"
    public
    {
        method
        field..
        blah
    }

    // Any public static fields
    public static
    {

    }

    // Hidden stuff
    protected
    {

    }
 }

 Not that terrible.


 I like it.  It's much more direct than using : syntax IMO.


I hate it and prefer the : syntax :)

Regan
Jun 23 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:optbmgr7jt23k2f5 nrage...


 I hate it and prefer the : syntax :)


Then turn off static with the : syntax ;)
Jun 23 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 23 Jun 2006 21:31:14 -0400, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:optbmgr7jt23k2f5 nrage...


 I hate it and prefer the : syntax :)


 Then turn off static with the : syntax ;)


I have never needed to do that. But lets assume I need to, in that case  
I'll use {} :)

The time I tend to use private etc inline is when there is only a single  
method which requires it (a single things which differs from the others  
inside the block), eg

class A {
//implicit/explicit public:
   ..many methods..
   private int a;
}

if there were several I'd say:

class A {
//implicit/explicit public:
   ..many methods..
private:
   int a;
   int b;
}

These coding practices aren't even hard and fast rules, they've evolved  
over time* and I'm sure I break them some of the time. In addition if I'm  
working on a project with others (something I'm doing right now) I'll  
adapt my practices to the practices of the group, it's really no problem  
for me how it's written, in the end it's just more or less typing (or  
copy/paste).

I think in general the more code you read written in different ways the  
better you get at discerning the true meaning from any particular piece of  
code and the better you become as a programmer. ('you' meaning 'people in  
general' not anyone specifically)

I have had a lot of experience reading code from many people of different  
skill levels and habits, it's no longer a problem for me how it's written  
and as such I don't really care how you or anyone else writes their code.  
I tend then to write mine however I like, usually in the simplest way  
possible.

This entire thread seems to me to be about prescribing how people should  
write code and I disagree with it on principle.

Regan

*often making me wish for a program to rearrange my old code to my new  
practices ;)
Jun 23 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:optbmo3ih323k2f5 nrage...


 *often making me wish for a program to rearrange my old code to my new 
 practices ;)


I know that feeling!  Last fall, I suddenly found myself hating not having 
spaces on either side of operators and after commas.  By now most of my code 
has been converted to the new style, but I still find a few "a=b+c" here and 
there :)
Jun 23 2006
prev sibling parent Frank Benoit <keinfarbton nospam.xyz> writes:
Boris Wang schrieb:

 the harm of these is more than the benefit.
 
 all these syntax produce non-readable, non-maintainable codes, and even more 
 in large project with many developers. 
 
 


I second that.

- public statement;
- public {}
This is good, easy, consistent.

- public:
is ugly C++ style and a bad choice if you can do better. And in this
case you can always use the {} form, which expands the "public" until a
defined place.

Removing it will perhaps break some existing code, but it will also make
D another bit more easy.

Please also remove the inheritance protection.
Jun 24 2006