BLS wrote:

> Hi Daniel,
> Python style indenting is ...
> what I would really like to see in D. but let us keep realistic...
> in fact nothing new, i think also the very first dbase interpreter allows
> it.
> and
> Nowadays the most 4GLs are using a pascal like language without {},
> respective  begin end,  or even ;
> From a compiler designers view it means a lot of additional work.
> 
> Thanks to Eric Andersons message I have had today the very first look on Nemerle. Looks clean, modern and usable.(and the most important point) readable.

Well, khm, I suppose it was my message.

Nemerle developers also have possibility to write in Python-like syntax in mind: http://nemerle.org/Open_projects#Python-like_syntax_front-end

They estimate it to be fairly easy to integrate but of course if it is done it
will mean some kind of split among developers on a style basis.
So maybe to stick with a single syntax is better for the sake of consistency
and code exchange.


P.S. I don't think we should discuss it further here because it's D forum after all.

-- 
AKhropov

The problem is not about {} and BEGIN/END.

Because in D, we can define the function when declare, so the syntax, such private: static: public{}, should be discarded.

"Hasan Aljudy" <hasan.aljudy@gmail.com> ??????:e6rhq4$1ce3$1@digitaldaemon.com...
>I think technically these { things } are called curly braces.
> I love them. 100x times better than begin end. IMO, they make function/class bodies standout.
>
> As for the second question, well, for the example you've given, I'd blame the coder who wrote it.
>
> Boris Wang wrote:
>> First, now, in a function of D, we can make netsted structure, nested function and versioned code block, so much brackets, which are not code block ,in the code sequence.
>>
>> Second, the use of colon and bracket for private/public, static and version keyword, make the judge of access level and storage type is difficult.
>>
>>   class aClass
>>   {
>>     public:
>>       .
>>       .
>>       ...three pages
>>       .
>>       void func( ...)
>>       {
>>
>>        }
>>      .
>>      .
>>      static:
>>       .
>>       ... four pages
>>       .
>>       int gotit(){...}
>>
>> How do you think about all these ?
>>
>>
> 

On Thu, 15 Jun 2006 17:37:41 +0800, Boris Wang wrote:

> First, now, in a function of D, we can make netsted structure, nested function and versioned code block, so much brackets, which are not code block ,in the code sequence.
> 
> Second, the use of colon and bracket for private/public, static and version keyword, make the judge of access level and storage type is difficult.

> ...

> How do you think about all these ?

I agree that the colon format for these qualifiers can lead to hard-to-maintain code because the scope of them is not as obvious. For that reason alone I avoid using them. I only use the single statement format and the braced format...

  private int someVar;

  static {
     int foo;
     int bar;
  }


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
16/06/2006 11:49:54 AM

The only non-OT response, thanks!

I think this is a serious problem, a language should be helpful to produce readable, maintainable codes, and,  restrict the production of non-readable, non-maintainable codes.


"Derek Parnell" <derek@psych.ward> ??????:1simyhs9tx5zh.p1oewy5visyw$.dlg@40tude.net...
> On Thu, 15 Jun 2006 17:37:41 +0800, Boris Wang wrote:
>
>> First, now, in a function of D, we can make netsted structure, nested function and versioned code block, so much brackets, which are not code block ,in the code sequence.
>>
>> Second, the use of colon and bracket for private/public, static and
>> version
>> keyword, make the judge of access level and storage type is difficult.
>
>> ...
>
>> How do you think about all these ?
>
> I agree that the colon format for these qualifiers can lead to
> hard-to-maintain code because the scope of them is not as obvious. For
> that
> reason alone I avoid using them. I only use the single statement format
> and
> the braced format...
>
>  private int someVar;
>
>  static {
>     int foo;
>     int bar;
>  }
>
>
> -- 
> Derek
> (skype: derek.j.parnell)
> Melbourne, Australia
> "Down with mediocrity!"
> 16/06/2006 11:49:54 AM
> 

Sometimes I have used something like this:

struct ObviouslyStaticStruct
{
static:
   // ...
}

Where everything in the struct is static.  But I don't do this often, mostly it's a poor man's namespace, e.g.:

struct constants
{
static:
   const int port = 21;
   const char[] name = "ftpd";
}

writefln(constants.name);

But, no, I'd not use them when it didn't apply to EVERYTHING, that's just too weird.  They have their uses, though, in my opinion.

-[Unknown]


> The only non-OT response, thanks!
> 
> I think this is a serious problem, a language should be helpful to produce readable, maintainable codes, and,  restrict the production of non-readable, non-maintainable codes.
> 
> 
> "Derek Parnell" <derek@psych.ward> ??????:1simyhs9tx5zh.p1oewy5visyw$.dlg@40tude.net...
>> On Thu, 15 Jun 2006 17:37:41 +0800, Boris Wang wrote:
>>
>>> First, now, in a function of D, we can make netsted structure, nested
>>> function and versioned code block, so much brackets, which are not code
>>> block ,in the code sequence.
>>>
>>> Second, the use of colon and bracket for private/public, static and version
>>> keyword, make the judge of access level and storage type is difficult.
>>> ...
>>> How do you think about all these ?
>> I agree that the colon format for these qualifiers can lead to
>> hard-to-maintain code because the scope of them is not as obvious. For that
>> reason alone I avoid using them. I only use the single statement format and
>> the braced format...
>>
>>  private int someVar;
>>
>>  static {
>>     int foo;
>>     int bar;
>>  }
>>
>>
>> -- 
>> Derek
>> (skype: derek.j.parnell)
>> Melbourne, Australia
>> "Down with mediocrity!"
>> 16/06/2006 11:49:54 AM
>>
> 
> 

Unknown W. Brackets wrote:

I've adopted a syntax where I only use the colon (:) form on protection attributes inside class/struct definitions. Outside, at module scope, I use brackets for for protection attributes. Other modifiers, such as static, final, abstract, I use inline. Version statements and multi-line debug statements all get brackets. extern statements get colons.

It's a coding convention I've come to like. I would really hate to see the colon syntax removed because I find it to be much more readable in class definitions:

class MyClass
{
   private
   {
      void myFunc();
   }
}

With one function it's not so bad, just ugly. But with multiple methods, the colon form is much clearer to me. And I really wouldln't like being forced to put all of my protection attributes inline.

This is all just a matter of taste. Having optional coding styles is nice, I think. I understand where you're coming from, but there are many other ways to make code difficult to read. As I see it, this ain't broke so don't fix it.

The previous post was suppose to be in response to Boris. And I wrote it, not Unknown ;)

Mike Parker wrote:
> Unknown W. Brackets wrote:
> 
> I've adopted a syntax where I only use the colon (:) form on protection attributes inside class/struct definitions. Outside, at module scope, I use brackets for for protection attributes. Other modifiers, such as static, final, abstract, I use inline. Version statements and multi-line debug statements all get brackets. extern statements get colons.
> 
> It's a coding convention I've come to like. I would really hate to see the colon syntax removed because I find it to be much more readable in class definitions:
> 
> class MyClass
> {
>    private
>    {
>       void myFunc();
>    }
> }
> 
> With one function it's not so bad, just ugly. But with multiple methods, the colon form is much clearer to me. And I really wouldln't like being forced to put all of my protection attributes inline.
> 
> This is all just a matter of taste. Having optional coding styles is nice, I think. I understand where you're coming from, but there are many other ways to make code difficult to read. As I see it, this ain't broke so don't fix it.

Derek Parnell wrote:
> On Thu, 15 Jun 2006 17:37:41 +0800, Boris Wang wrote:
> 
>> First, now, in a function of D, we can make netsted structure, nested function and versioned code block, so much brackets, which are not code block ,in the code sequence.
>>
>> Second, the use of colon and bracket for private/public, static and version keyword, make the judge of access level and storage type is difficult.
> 
>> ...
>  
>> How do you think about all these ?
> 
> I agree that the colon format for these qualifiers can lead to
> hard-to-maintain code because the scope of them is not as obvious. For that
> reason alone I avoid using them. I only use the single statement format and
> the braced format...
> 
>   private int someVar;
> 
>   static {
>      int foo;
>      int bar;
>   }
> 
> 

Another important feature of the colon is that it can appear inside version{} blocks. You can't do this with the {} form.

version(Windows) {

  extern(Windows):

} else {

  extern(C):

}

// These are extern(Windows) on Windows systems, but
// extern(C) on Linux.
// For example, the MySQL functions behave this way.
void func1();
void func2();

"Mike Parker" <aldacron71@yahoo.com> ??????:e6tjo6$106v$1@digitaldaemon.com...
> Unknown W. Brackets wrote:
>
> I've adopted a syntax where I only use the colon (:) form on protection attributes inside class/struct definitions. Outside, at module scope, I use brackets for for protection attributes. Other modifiers, such as static, final, abstract, I use inline. Version statements and multi-line debug statements all get brackets. extern statements get colons.
>
> It's a coding convention I've come to like. I would really hate to see the colon syntax removed because I find it to be much more readable in class definitions:
>
> class MyClass
> {
>    private
>    {
>       void myFunc();
>    }
> }
>
> With one function it's not so bad, just ugly. But with multiple methods, the colon form is much clearer to me. And I really wouldln't like being forced to put all of my protection attributes inline.
>
> This is all just a matter of taste. Having optional coding styles is nice, I think. I understand where you're coming from, but there are many other ways to make code difficult to read. As I see it, this ain't broke so don't fix it.
>

First, I post the thread, because neighter i like what, nor don't like what.

Second,  please think this problem in  more complicated situation.

Daniel Keep wrote:
> 
> BLS wrote:
> 
>> "Deewiant" <deewiant.doesnotlike.spam@gmail.com> schreef in bericht
>>  news:e6rno9$1ju8$1@digitaldaemon.com...
>> 
>>>> I find something like that gets very annoying quickly, when
>>>> "PROCEDURE
>> 
>> xyz" is
>> 
>>> one or two lines long. Imagine something like (mixed-syntax
>>> pseudocode):
>> 
>> Hi Deewiant, a two line inner function seems , at least to me, to
>> be a quit seldom used construction.
> 
> Well, that depends on your coding style, really.
> 
> Personally, I prefer to write lots of small, well-defined functions.
> If I can't fit a whole function's flow into my head at once, then I
> know I need to break it up.

Kudos, Daniel, for saying that!!

I used to write long functions, but then I got a peek at Turbo Pascal 5.5 library source code, and I was simply astounded. Very few of the functions (or procedures) were more than 5 lines of [actual] code!

I think this was the reason why Borland was able to release new versions of their Pascal and the IDE, quite often, and had very few bugs in them. This coding style is actually encouraged in Java documentation, and the compiler is supposed to optimise away much of the "unneeded function calls", and do automatic inlining of stuff that gets only used in a couple of places -- by default.

From that day on, I myself could tackle much bigger projects, and modifying and rewriting became pleasant, instead of being a nightmare.

(I think programming is taught in such a way that people don't get in a habit of, or see the value in, keeping functions short.)

Another thing they used was function and identifier names that let the naive reader instantly see what was going on. (Sure, it takes "more ink", but when somebody else has to edit your code one day, the difference is like night and day.)

> One interesting approach to this problem I've seen is in Nemerle: it supports both C-style syntax and, with the flip of a compiler switch,
>  Python-style indenting.

Dot Net, anyone? ;-(