I'm doing some text parsing and I'd appreciate some input on code styles 
for loops.

A lot of the processing I'm currently doing involves finding a 
particular character, and then doing something with the text up to that 
point.  For example:

     int i;
     for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
     {}
     // do something with i and s here

This marches ahead until it find a character that isn't a "letter", 
then, with i set to the offset of the last letter+1, is able to do 
something with that group of letters in string s.

My question is on the code style I used here.  The for loop looks a 
little funny.  I think it's the best because all the terms (is that 
right? terms = the bits between the semicolons) of the for statement do 
the right thing and are in the standard position.

However, the body is empty, which is weird, and i has to be declared 
outside of the for loop so I can use it later, which is a little weird.

Any thoughts on how to format this?  Would a while loop be better or 
more readable here?

   int i = 1;
   while( Character.isLetter( s.charAt( i ) ) ) {
      i++;
   }

That while loop wasn't tested, but should do the same thing as the for 
loop above.  Any ideas?

On Oct 21, 1:34=A0pm, markspace <nos...@nowhere.com> wrote:
> I'm doing some text parsing and I'd appreciate some input on code styles
> for loops.
>
> A lot of the processing I'm currently doing involves finding a
> particular character, and then doing something with the text up to that
> point. =A0For example:
>
> =A0 =A0 =A0int i;
> =A0 =A0 =A0for( i =3D 1; Character.isLetter( s.charAt( i) ); i++ )
> =A0 =A0 =A0{}
> =A0 =A0 =A0// do something with i and s here
>
> This marches ahead until it find a character that isn't a "letter",
> then, with i set to the offset of the last letter+1, is able to do
> something with that group of letters in string s.
>
> My question is on the code style I used here. =A0The for loop looks a
> little funny. =A0I think it's the best because all the terms (is that
> right? terms =3D the bits between the semicolons) of the for statement do
> the right thing and are in the standard position.
>
> However, the body is empty, which is weird, and i has to be declared
> outside of the for loop so I can use it later, which is a little weird.
>
> Any thoughts on how to format this? =A0Would a while loop be better or
> more readable here?
>
> =A0 =A0int i =3D 1;
> =A0 =A0while( Character.isLetter( s.charAt( i ) ) ) {
> =A0 =A0 =A0 i++;
> =A0 =A0}
>
> That while loop wasn't tested, but should do the same thing as the for
> loop above. =A0Any ideas?
>

Use what you like, that's why it's called "style".  I strongly
recommend against single-letter variable names like "i" and "s",
though.

Personally I prefer the 'for' version.  There's nothing "weird" about
the index being declared outside the loop body since that's driven by
the actual scope needed.  The only thing "weird" is to declare a
variable for a different scope than it needs, but you're not doing
that.

There is equally nothing "weird" about an empty loop body.  It's done
all the time.  In fact, that's part of why the 'for' syntax is what it
is, going back to 'C' days and beyond - to support compact expression
of a loop.

Go with your 'for' loop, it's bog standard.

--
Lew

On Oct 21, 12:34=A0pm, markspace <nos...@nowhere.com> wrote:
> I'm doing some text parsing and I'd appreciate some input on code styles
> for loops.
>
> A lot of the processing I'm currently doing involves finding a
> particular character, and then doing something with the text up to that
> point. =A0For example:
>
> =A0 =A0 =A0int i;
> =A0 =A0 =A0for( i =3D 1; Character.isLetter( s.charAt( i) ); i++ )
> =A0 =A0 =A0{}
> =A0 =A0 =A0// do something with i and s here
>
> This marches ahead until it find a character that isn't a "letter",
> then, with i set to the offset of the last letter+1, is able to do
> something with that group of letters in string s.
>
> My question is on the code style I used here. =A0The for loop looks a
> little funny. =A0I think it's the best because all the terms (is that
> right? terms =3D the bits between the semicolons) of the for statement do
> the right thing and are in the standard position.
>
> However, the body is empty, which is weird, and i has to be declared
> outside of the for loop so I can use it later, which is a little weird.
>
> Any thoughts on how to format this? =A0Would a while loop be better or
> more readable here?
>
> =A0 =A0int i =3D 1;
> =A0 =A0while( Character.isLetter( s.charAt( i ) ) ) {
> =A0 =A0 =A0 i++;
> =A0 =A0}
>
> That while loop wasn't tested, but should do the same thing as the for
> loop above. =A0Any ideas?

I frequently use a for loop to empty a table something like:
for (;table.getRowCount() > 0;table.removeRow(0));
notice, you don't even need the body {}, if your body is empty or one
line, you can use just a ; to end.

You mention though that you are looking for a particular character,
maybe you should use "some-string-is-here".split("-"). This will give
you an String[] of strings without the -. Another option is "some-
string-is-here".firstIndexOf("-") will tell you the position of the
first "-".

On Oct 21, 10:58=A0am, Lew <l...@lewscanon.com> wrote:
> On Oct 21, 1:34=A0pm, markspace <nos...@nowhere.com> wrote:
>
>
>
>
>
> > I'm doing some text parsing and I'd appreciate some input on code style=
s
> > for loops.
>
> > A lot of the processing I'm currently doing involves finding a
> > particular character, and then doing something with the text up to that
> > point. =A0For example:
>
> > =A0 =A0 =A0int i;
> > =A0 =A0 =A0for( i =3D 1; Character.isLetter( s.charAt( i) ); i++ )
> > =A0 =A0 =A0{}
> > =A0 =A0 =A0// do something with i and s here
>
> > This marches ahead until it find a character that isn't a "letter",
> > then, with i set to the offset of the last letter+1, is able to do
> > something with that group of letters in string s.
>
> > My question is on the code style I used here. =A0The for loop looks a
> > little funny. =A0I think it's the best because all the terms (is that
> > right? terms =3D the bits between the semicolons) of the for statement =
do
> > the right thing and are in the standard position.
>
> > However, the body is empty, which is weird, and i has to be declared
> > outside of the for loop so I can use it later, which is a little weird.
>
> > Any thoughts on how to format this? =A0Would a while loop be better or
> > more readable here?
>
> > =A0 =A0int i =3D 1;
> > =A0 =A0while( Character.isLetter( s.charAt( i ) ) ) {
> > =A0 =A0 =A0 i++;
> > =A0 =A0}
>
> > That while loop wasn't tested, but should do the same thing as the for
> > loop above. =A0Any ideas?
>
> Use what you like, that's why it's called "style". =A0I strongly
> recommend against single-letter variable names like "i" and "s",
> though.
>
> Personally I prefer the 'for' version. =A0There's nothing "weird" about
> the index being declared outside the loop body since that's driven by
> the actual scope needed. =A0The only thing "weird" is to declare a
> variable for a different scope than it needs, but you're not doing
> that.
>
> There is equally nothing "weird" about an empty loop body. =A0It's done
> all the time. =A0In fact, that's part of why the 'for' syntax is what it
> is, going back to 'C' days and beyond - to support compact expression
> of a loop.
>
> Go with your 'for' loop, it's bog standard.
>

It is suspicious that you start the loop at the second character
(i=3D1). This will likely cause problems when s is empty or the first
character is not a letter.
--
Fred K

On Oct 21, 1:34=A0pm, markspace <nos...@nowhere.com> wrote:
> I'm doing some text parsing and I'd appreciate some input on code styles
> for loops.
>
> A lot of the processing I'm currently doing involves finding a
> particular character, and then doing something with the text up to that
> point. =A0For example:
>
> =A0 =A0 =A0int i;
> =A0 =A0 =A0for( i =3D 1; Character.isLetter( s.charAt( i) ); i++ )
> =A0 =A0 =A0{}
> =A0 =A0 =A0// do something with i and s here
>
> This marches ahead until it find a character that isn't a "letter",
> then, with i set to the offset of the last letter+1, is able to do
> something with that group of letters in string s.
>
> ...

> Any thoughts on how to format this? =A0Would a while loop be better or
> more readable here?
>

While I don't have any problem with the style for the problem as
stated, I think it tends to degrade when there are more conditions,
and I often find there are.  E.g., if you aren't guaranteed that there
is any non-alphabetic character then you need:

   for (i=3D1; i<s.length() && Character.isLetter(s.charAt(i)); i +=3D 1)
{
   }

This I would prefer to see as:

   for (i=3D1; i<s.length(); i +=3D 1) {
        if (Character.isLetter(s.charAt(i)) {
            break;
        }
   }

The extra test is also needed if, as another poster noted, the string
may only be one character long.

This separates the loop structure from the logic test which I find
easier to follow.

    Regards,
    Tom McGlynn

"markspace" <nospam@nowhere.com> wrote in message 
news:i9ptik$rcd$1@news.eternal-september.org...
> I'm doing some text parsing and I'd appreciate some input on code styles 
> for loops.
>
> A lot of the processing I'm currently doing involves finding a particular 
> character, and then doing something with the text up to that point.  For 
> example:
>
>     int i;
>     for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
>     {}
>     // do something with i and s here
>
> This marches ahead until it find a character that isn't a "letter", then, 
> with i set to the offset of the last letter+1, is able to do something 
> with that group of letters in string s.
>
> My question is on the code style I used here.  The for loop looks a little 
> funny.  I think it's the best because all the terms (is that right? terms 
> = the bits between the semicolons) of the for statement do the right thing 
> and are in the standard position.

we call these 'expressions'.
not to be confused with 'statements', which are what the variable 
declaration and for loop are.


> However, the body is empty, which is weird, and i has to be declared 
> outside of the for loop so I can use it later, which is a little weird.
>

actually, the braces can be omitted here, hence:
     for( i = 1; Character.isLetter( s.charAt( i) ); i++ );

braces generally only really serve the purpose of lumping multiple 
statements together into a single statement block, and so are typically left 
out when there is only a single statement.

further more, if there is no statement, a single ';' can be used instead, 
which is usually understood as being an "empty statement" or "null 
statement", ane may be used with 'for' and 'while' loops, or wherever else 
they may be useful.


note:
declaring variables outside the loop is also fairly common, and in fact many 
people use this as their primary style (it is declaring variables inside the 
for loop which is itself unusual...).

anyways, functionality is more important than some perception of style.


> Any thoughts on how to format this?  Would a while loop be better or more 
> readable here?
>
>   int i = 1;
>   while( Character.isLetter( s.charAt( i ) ) ) {
>      i++;
>   }
>
> That while loop wasn't tested, but should do the same thing as the for 
> loop above.  Any ideas?
>

again, the braces are optional.

while( Character.isLetter( s.charAt( i ) ) ) i++;
or, taken further:
while(Character.isLetter(s.charAt(i++)));

or, if Java were C or C++...:
while(isalpha(s[i++]));
or:
while(isalpha(*s++));
(the above will not work in Java, but are meant more as illustration).


but, to a large degree, style is irrelevant...
it is much more important that code work than that it adhere to any 
particular sense of aesthetics, or at least within the realm of basic sanity 
(for example, using indentation and not organizing code into a single big 
lump of characters and similar...).

even then, there are cases where it is infact nicer to lump a bunch of 
statements onto a single line, and other cases where it is best to insert 
extra whitespace, and so no simple rules are always ideal.


someone here also advocated the use of longer / "descriptive" variable 
names, but again, this is another one of those points of conflict, and is 
ultimately irrelevant and depending primarily what one is doing. the main 
cost of longer names is that they take more screen space and more mental 
letter-space to store and work with, which is a drawback, and also longer 
names can become particularly awkward.

so, single letter names are convinient and usually "obvious enough", which 
leaves longer names (words, multi-words, ...) mostly for cases where the 
usage of a variable is not immediately obvious or driven by convention (most 
single-letter variable names are somewhat driven by informal conventions, so 
it is understood what the names are regardless of their brevity).

in some cases, one may also have reason for using "hungarian notation", 
although people get into arguments over this as well.

but, ultimately, it is all pointless.
do what makes sense in a given situation, and this is good enough...

On 10/21/2010 11:10 AM, bcr666 wrote:

> You mention though that you are looking for a particular character,
> maybe you should use "some-string-is-here".split("-"). This will give
> you an String[] of strings without the -. Another option is "some-
> string-is-here".firstIndexOf("-") will tell you the position of the
> first "-".


This is good advice.  split() isn't exactly a good match here but 
firstIndexOf() will be useful, thanks for reminding me.

Here's another one, designed to skip over a set of characters.  I 
thought I could implement the inner loop with skip.contains( s.charAt( 
cursor) ) but contains only takes CharSequence, not char.  Bummer.

     public static int skip( String s, int offset, String skip ) {
         int cursor = offset;
         testing_string:
         for( ; cursor < s.length(); cursor++ ) {
             for( int i = 0; i < skip.length(); i++ ) {
                 if( s.charAt( cursor ) == skip.charAt( i ) ) {
                     continue testing_string;
                 }
             }
             break testing_string;
         }
         return cursor;
     }

BGB / cr88192 wrote:
> actually, the braces can be omitted here, hence:
> =A0 =A0 =A0for( i =3D 1; Character.isLetter( s.charAt( i) ); i++ );
>
> braces generally only really serve the purpose of lumping multiple
> statements together into a single statement block, and so are typically l=
eft
> out when there is only a single statement.
>

"... are typically left out ..." - you make that sound like such a
universal rule when in fact most places mandate the opposite, and most
writers recommend the opposite, that the braces are needed even for a
single body statement to prevent anomalies due to obfuscatory
indentation during a refactoring or enhancement activity.

I suggest that the best practice of using curly braces even for single-
statement bodies is what is "typical".  If not, it should be.

> further more, if there is no statement, a single ';' can be used instead,
> which is usually understood as being an "empty statement" or "null
> statement", ane may be used with 'for' and 'while' loops, or wherever els=
e
> they may be useful.
>
> note:
> declaring variables outside the loop is also fairly common, and in fact m=
any
> people use this as their primary style (it is declaring variables inside =
the
> for loop which is itself unusual...).
>

Huh?  Wha...?

This isn't a popularity contest.  You declare a variable for the scope
for which it applies.  If a variable has no use outside the loop body,
it should be declared inside the loop body.  What patzer programmers
do notwithstanding.

Where are you getting your statistics, anyway?  Declaring variables
inside a loop body is darn-near universal.  How in the seven worlds do
you call that "unusual"?

> anyways, functionality is more important than some perception of style.
>

Precisely, so declare variables outside the loop if, and only if,
they're used outside the loop.

markspace wrote:
>> =A0 int i =3D 1;
>> =A0 while( Character.isLetter( s.charAt( i ) ) ) {
>> =A0 =A0 =A0i++;
>> =A0 }
>

BGB / cr88192 wrote:
> again, the braces are optional.
>

By the rules of the language, not by best practice.

> while( Character.isLetter( s.charAt( i ) ) ) i++;
>

Ewwwww!

> or, taken further:
> while(Character.isLetter(s.charAt(i++)));
>

Do you enjoy making your code difficult for others to read?

> but, to a large degree, style is irrelevant...
>

Nope.

To a large degree, style is relevant - it's to the degree that people
need to work comfortably together.

> it is much more important that code work than that it adhere to any
> particular sense of aesthetics, or at least within the realm of basic san=
ity
> (for example, using indentation and not organizing code into a single big
> lump of characters and similar...).
>

I thought from your code snippets that you were in favor of "a single
big lump of characters and similar...".  I'm pleased to be mistaken.

> even then, there are cases where it is infact nicer to lump a bunch of
> statements onto a single line, and other cases where it is best to insert
> extra whitespace, and so no simple rules are always ideal.
>

But simple principles are ideal - make code easy to read and
understand, and hard to misconstrue or screw up.

> someone here also advocated the use of longer / "descriptive" variable
> names, but again, this is another one of those points of conflict, and is
>

It's only a "conflict" between those who care about maintainability
and those who utterly lack professionalism.  The former have no issue
with using longer, more readable names.  The latter have no clue why
it's important.

> ultimately irrelevant and depending primarily what one is doing. the main
> cost of longer names is that they take more screen space and more mental
> letter-space to store and work with, which is a drawback, and also longer
> names can become particularly awkward.
>

What you're saying is true for names that are "too long", but not
names that are "longer".  Descriptive names are not perceived
psychologically as "letter-space", whatever the freak that is supposed
to mean, but as morphemes and memes - i.e., the mind chunks the
information, so your claim about "more mental letter-space" is as
bogus as the terminology.

> so, single letter [sic] names are convinient and usually "obvious enough"=
, which
>

Sez you!  You aren't really correct, but it's a nice opinion.

Single-letter names are only "convenient" for the lazy author.
They're a lot of work for the diligent maintainer.  I In a word,
they're selfish.

> leaves longer names (words, multi-words, ...) mostly for cases where the
> usage of a variable is not immediately obvious or driven by convention (m=
ost
>

or for where you want clarity, lack of error, maintainability,
professionalism, ...

> single-letter variable names are somewhat driven by informal conventions,=
 so
> it is understood what the names are regardless of their brevity).
>

"It is understood" - you are fond of using the passive voice to make
your minority opinions sound like Universal Truth.

> in some cases, one may also have reason for using "hungarian notation",
> although people get into arguments over this as well.
>

Probably because there's no use for it in Java, and it violates the
well-founded and well-understood principles of encapsulation and
information-hiding.

> but, ultimately, it is all pointless.
>

Now we're talking about life in general.

> do what makes sense in a given situation, and this is good enough
>

Spoken like an amateur.

--
Lew

On 10/21/2010 10:34 AM, markspace wrote:
> I'm doing some text parsing and I'd appreciate some input on code styles
> for loops.
>
> A lot of the processing I'm currently doing involves finding a
> particular character, and then doing something with the text up to that
> point. For example:
>
> int i;
> for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
> {}
> // do something with i and s here
>
> This marches ahead until it find a character that isn't a "letter",
> then, with i set to the offset of the last letter+1, is able to do
> something with that group of letters in string s.
>
> My question is on the code style I used here. The for loop looks a
> little funny. I think it's the best because all the terms (is that
> right? terms = the bits between the semicolons) of the for statement do
> the right thing and are in the standard position.
>
> However, the body is empty, which is weird, and i has to be declared
> outside of the for loop so I can use it later, which is a little weird.

int i;
for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
{
   /* EMPTY */
}
// do something with i and s here

I assume "i" and "s" are for illustration, and the real code would use
meaningful identifiers. Depending on context, consider putting the whole
thing in a block to limit the scope of i.

If the starting index really should be 1, it may be worth a comment
explaining why, unless it is obvious in context.

I disagree, strongly, with the idea of using ";" instead of braces
containing a comment. A ";" after the ")" of a for-statement could be a
typo. Someone else reading the code is going to stop and think about
whether the following statement should be the for-loop body, especially
if it uses "i".

My preferred form makes it obvious both that the for-loop body is empty
of syntactic tokens, and that its emptiness was intended.

Patricia

On 21-10-2010 13:34, markspace wrote:
> I'm doing some text parsing and I'd appreciate some input on code styles
> for loops.
>
> A lot of the processing I'm currently doing involves finding a
> particular character, and then doing something with the text up to that
> point. For example:
>
> int i;
> for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
> {}
> // do something with i and s here
>
> This marches ahead until it find a character that isn't a "letter",
> then, with i set to the offset of the last letter+1, is able to do
> something with that group of letters in string s.
>
> My question is on the code style I used here. The for loop looks a
> little funny. I think it's the best because all the terms (is that
> right? terms = the bits between the semicolons) of the for statement do
> the right thing and are in the standard position.
>
> However, the body is empty, which is weird, and i has to be declared
> outside of the for loop so I can use it later, which is a little weird.
>
> Any thoughts on how to format this? Would a while loop be better or more
> readable here?
>
> int i = 1;
> while( Character.isLetter( s.charAt( i ) ) ) {
> i++;
> }
>
> That while loop wasn't tested, but should do the same thing as the for
> loop above. Any ideas?

I would go for the while loop in this case.

It is logically a while operation and not a for operation.

Arne

"Lew" <lew@lewscanon.com> wrote in message 
news:68aa61a9-5999-410a-92d9-909966367f38@w21g2000vby.googlegroups.com...
BGB / cr88192 wrote:

<snip>

nevermind that we disagree on many matters of style...

I still regard that style is largely unimportant in most cases, since the 
language does not require it, and it is not like much actually bad will 
happen due to violating some stylistic rule, anymore than fire will fall 
from the ceiling due to using the wrong silverware or stiring ones' coffee 
with a knife or screwdriver or similar...


any rules one follows are usually due to some specific or potential cost of 
violating it, and if a rule does not result in some obvious cost, why 
bother?

like the braces:
one can leave them out, and save some characters, and if later they need 
multiple statements, they can put them back in. usually the savings (in 
terms of readability and screen space) save more than the effort needed to 
type them back in later if the code is being edited.

in all likelyhood, if one initially is only typing a single statement, 
likely they will never need multiple statements anyways, and hence the 
screen-space savings will be of a larger benefit.


> in some cases, one may also have reason for using "hungarian notation",
> although people get into arguments over this as well.
>

<--
Probably because there's no use for it in Java, and it violates the
well-founded and well-understood principles of encapsulation and
information-hiding.
-->

it is useful in those cases where otherwise it would be difficult to come up 
with good non-clashing variable names, or in cases where several variables 
are closely related but represent different entities. hungarian notation 
allows the basic-name to be used multiple times.

granted, it is pointless for methods given the existence of overloading...


> but, ultimately, it is all pointless.
>

<--
Now we're talking about life in general.
-->

well, more specifically, about language style and debating over language 
style.
what really does it matter?


> do what makes sense in a given situation, and this is good enough
>

<--
Spoken like an amateur.
-->

I have written and worked on projects in the Mloc range (including 3D 
engines and compilers and similar), and in a number of different programming 
languages (C, C++, ASM, Java, C#, ...), so I will contest this description.

markspace <nospam@nowhere.com> writes:
>int i;
>for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
>{}
>// do something with i and s here
>However, the body is empty, which is weird, and i has to be declared 
>outside of the for loop so I can use it later, which is a little weird.

  The weird things are (others might have noticed this already,
  I have not read the thread yet):

    - i starts at 1.

    - �( i)� has a space in front of the �i�, but not after it.

      (I'd write �( s.charAt( i ))�, but this is only my very
      personal style, see
      http://www.purl.org/stefan_ram/pub/c_format_en       .)

  I'd write this as:

int i = -1; while( Character.isLetter( s.charAt( ++i )); 

Patricia Shanahan <pats@acm.org> writes:
>I disagree, strongly, with the idea of using ";" instead of braces
>containing a comment. A ";" after the ")" of a for-statement could be a
>typo.

  In fact, nearly everything could be a typo in source code.

>Someone else reading the code is going to stop and think
>about whether the following statement should be the for-loop
>body, especially if it uses "i".

  Usually, I assume that the programmer intented what he wrote,
  unless I have a reason to assume otherwise. Such a semicolon �;�
  is not such a reason. An �{ /* EMPTY */ }� makes me feel 
  somewhat annoyed/offended.

      NB: THE PERIOD AT THE END OF THE PREVIOUS SENTENCE WAS
      WRITTEN INTENTIONALLY TO MARK THE END OF THE SENTENCE.
           SEE: http://en.wikipedia.org/wiki/Full_stop

Lew wrote:
>> <--
>> Spoken like an amateur.
>> -->

BGB / cr88192 wrote:
> I have written and worked on projects in the Mloc range (including 3D
> engines and compilers and similar), and in a number of different programming
> languages (C, C++, ASM, Java, C#, ...), so I will contest this description.

How about we construe "amateur" in the good sense of "one who loves the art"?

Also, the word was "like", not "as".  I do not actually think that you are an 
amateur, construed in the derogatory sense.

On rereading your post your arguments do make more sense than they seemed a 
couple of hours ago.  Mind you, I don't fully agree, but from a perspective 
they do hang together.

-- 
Lew

markspace wrote:
> I'm doing some text parsing and I'd appreciate some input on code styles
> for loops.

Now *this* is good use o' Usenet!

Besides that, it's the highest form of programming - seeking review and comment.

Good show, old chap!

-- 
Lew

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>�{ /* EMPTY */ }� 

  It reminds me of suggestions to write

Character.isLetter( s.charAt( i ))== true

  , because this is �more readable� than

Character.isLetter( s.charAt( i ))

  . It might be more readable for persons who know English,
  but no or little Java. But source code becomes less readable
  for experienced programmers when it is written with such a
  reader in mind.

  In C, to skip two space-separated integral numerals
  (under certain circumstances):

while( isnum( *++c )); while( isspace( *++c )); while( isnum( *++c ));

  , this is obvious and intelligible. Now try to scan this:

while( isnum( *++c ))
{ /* EMPTY */ }

while( isspace( *++c ))
{ /* EMPTY */ }

while( isnum( *++c ))
{ /* EMPTY */ }

  The �{ /* EMPTY */ }� only distracts the attention of the reader
  towards unimportant parts of the code, gives way to more errors,
  like forgetting to close the comment properly and bloats the code.

On 10/21/2010 07:40 PM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> »{ /* EMPTY */ }«
>
>    It reminds me of suggestions to write
>
> Character.isLetter( s.charAt( i ))== true
>
>    , because this is »more readable« than
>
> Character.isLetter( s.charAt( i ))
>
>    . It might be more readable for persons who know English,
>    but no or little Java. But source code becomes less readable
>    for experienced programmers when it is written with such a
>    reader in mind.
>
>    In C, to skip two space-separated integral numerals
>    (under certain circumstances):
>
> while( isnum( *++c )); while( isspace( *++c )); while( isnum( *++c ));
>
>    , this is obvious and intelligible. Now try to scan this:
>
> while( isnum( *++c ))
> { /* EMPTY */ }
>
> while( isspace( *++c ))
> { /* EMPTY */ }
>
> while( isnum( *++c ))
> { /* EMPTY */ }
>
>    The »{ /* EMPTY */ }« only distracts the attention of the reader
>    towards unimportant parts of the code, gives way to more errors,
>    like forgetting to close the comment properly and bloats the code.
>

On the third hand, one might reasonably find

while( isnum( *++c )){} while( isspace( *++c )){} while( isnum( *++c )){}

equally or even more obvious and intelligible whilst emphasizing a) the 
loopness of each loop and b) the deliberateness of the act - four strokes 
(counting SHIFT) bespeaks commitment a lone semicolon tap might not - without 
undue sacrifice of terseness.  The very shock-value of the idiom helps 
document itself.

-- 
Lew

"Lew" <noone@lewscanon.com> wrote in message 
news:i9qi8k$ogs$1@news.albasani.net...
> Lew wrote:
>>> <--
>>> Spoken like an amateur.
>>> -->
>
> BGB / cr88192 wrote:
>> I have written and worked on projects in the Mloc range (including 3D
>> engines and compilers and similar), and in a number of different 
>> programming
>> languages (C, C++, ASM, Java, C#, ...), so I will contest this 
>> description.
>
> How about we construe "amateur" in the good sense of "one who loves the 
> art"?
>

ok, fair enough.


admittedly, Java is not one of my most heavily used languages (much more of 
my development is in C and C++, and of this, a much larger portion is in C).

it is possible that some amount of C-like stylistic preferences bleed over.


admittedly, there is a notion I have heard before, that when a person moves 
from one language to another, their style should also entirely change as 
well to be whatever is most accepted by the particular 
language/community/... personally, I find this idea both inconvinient and 
unecessary, given that these languages retain mostly similar syntax (and 
what works aesthetically in one language should work similarly well in the 
others, and if there is a severe conflict then this would imply that maybe 
something is not right).

although, this is not to say that one should dogmatically stick to an older 
style either, since if one is working on a piece of code and introduces a 
harsh style change from whatever is already there, then this will be ugly 
regardless of the relative merits of the stylistic conventions in use (or 
worse yet is trying to impose a new style on already existing code).

for example, going and changing a bunch of Java code to use 
'FirstLetterCaps' naming, or a bunch of C# code to use 'camelCase' because 
one has a particular preference would be IMO ill-advised, even though there 
is little requirement either way that Java be camelCase or C# be 
FirstLetterCaps, so one can probably choose which to use based on both 
convention and personal preferences (weighting things as they go).

actually, I have seen cases where people have gone around and changed all 
the capitalization or indentation or whatever else in an existing codebase, 
and IMO this is ugly and inconvinient, as then often pieces of older code 
will no longer work simply because the capitalization is different (and then 
one has to stub things or modify the code or similar to make it fit again).


similar goes for little style wars and artificial divisions between C and 
C++, when as I see it, since it is more or less a simple subset/superset 
issue, why not treat it as such?...

at least with C (or C++) vs Java, there are good reasons why things done one 
way in one language are not done in the same way in the other, ...

admittedly, I have my own little rules and practices, but most are more 
generally related to practical concerns than some abstract notion of 
"language purity" or "style purity" or similar.


> Also, the word was "like", not "as".  I do not actually think that you are 
> an amateur, construed in the derogatory sense.
>
> On rereading your post your arguments do make more sense than they seemed 
> a couple of hours ago.  Mind you, I don't fully agree, but from a 
> perspective they do hang together.
>

yes, ok.

On 21-10-2010 16:42, Lew wrote:
> BGB / cr88192 wrote:
>> actually, the braces can be omitted here, hence:
>>       for( i = 1; Character.isLetter( s.charAt( i) ); i++ );
>>
>> braces generally only really serve the purpose of lumping multiple
>> statements together into a single statement block, and so are typically left
>> out when there is only a single statement.
>>
>
> "... are typically left out ..." - you make that sound like such a
> universal rule when in fact most places mandate the opposite, and most
> writers recommend the opposite, that the braces are needed even for a
> single body statement to prevent anomalies due to obfuscatory
> indentation during a refactoring or enhancement activity.
>
> I suggest that the best practice of using curly braces even for single-
> statement bodies is what is "typical".  If not, it should be.

It is the recommendation in the standard SUN/Oracle Java coding
convention.

http://www.oracle.com/technetwork/java/codeconventions-142311.html#15395

<quote>
Braces are used around all statements, even single statements, when they 
are part of a control structure, such as a if-else or for statement. 
This makes it easier to add statements without accidentally introducing 
bugs due to forgetting to add braces.
</quote>

>> further more, if there is no statement, a single ';' can be used instead,
>> which is usually understood as being an "empty statement" or "null
>> statement", ane may be used with 'for' and 'while' loops, or wherever else
>> they may be useful.
>>
>> note:
>> declaring variables outside the loop is also fairly common, and in fact many
>> people use this as their primary style (it is declaring variables inside the
>> for loop which is itself unusual...).
>>
>
> Huh?  Wha...?
>
> This isn't a popularity contest.  You declare a variable for the scope
> for which it applies.  If a variable has no use outside the loop body,
> it should be declared inside the loop body.  What patzer programmers
> do notwithstanding.
>
> Where are you getting your statistics, anyway?  Declaring variables
> inside a loop body is darn-near universal.  How in the seven worlds do
> you call that "unusual"?

The "universal" does not apply to C89 and a few other widely used
languages.

> Single-letter names are only "convenient" for the lazy author.
> They're a lot of work for the diligent maintainer.  I In a word,
> they're selfish.

i,j and k are idiomatic for for loops.

Arne

On 10/21/2010 1:34 PM, markspace wrote:
> I'm doing some text parsing and I'd appreciate some input on code styles
> for loops.
>
> A lot of the processing I'm currently doing involves finding a
> particular character, and then doing something with the text up to that
> point. For example:
>
> int i;
> for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
> {}
> // do something with i and s here
>
> This marches ahead until it find a character that isn't a "letter",
> then, with i set to the offset of the last letter+1, is able to do
> something with that group of letters in string s.

     You'd better hope that such a non-letter character exists, or
you'll march right off the end of the string ...

> My question is on the code style I used here. The for loop looks a
> little funny. I think it's the best because all the terms (is that
> right? terms = the bits between the semicolons) of the for statement do
> the right thing and are in the standard position.
>
> However, the body is empty, which is weird, and i has to be declared
> outside of the for loop so I can use it later, which is a little weird.
>
> Any thoughts on how to format this? Would a while loop be better or more
> readable here?
>
> int i = 1;
> while( Character.isLetter( s.charAt( i ) ) ) {
> i++;
> }
>
> That while loop wasn't tested, but should do the same thing as the for
> loop above. Any ideas?

     Either is all right (once you fix the end-of-string issue).
The wide scope of `i' is usually not an issue, because it's quite
likely that after you've peeled off the leading letters you'll want
to do something with the rest of the string, and `i' will thus have
a significance that extends beyond the immediate search loop.

     If it makes you uncomfortable, though, you can always encapsulate
the search in a method like

	static int findFirstNonLetterIgnoringCharAt0(String s) ...

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 21-10-2010 15:55, BGB / cr88192 wrote:
> "markspace"<nospam@nowhere.com>  wrote in message
>> However, the body is empty, which is weird, and i has to be declared
>> outside of the for loop so I can use it later, which is a little weird.
>>
>
> actually, the braces can be omitted here, hence:
>       for( i = 1; Character.isLetter( s.charAt( i) ); i++ );
>
> braces generally only really serve the purpose of lumping multiple
> statements together into a single statement block, and so are typically left
> out when there is only a single statement.

No. In Java we typical use them even for single statements.

> but, to a large degree, style is irrelevant...

No. Reading code that uses different styles or very unusual
styles make reading code slower.

Slower = cost more $$$$ for maintenance.

$$$$ is relevant in professional software development.

> in some cases, one may also have reason for using "hungarian notation",
> although people get into arguments over this as well.

Even MS has given up on that.

> but, ultimately, it is all pointless.
> do what makes sense in a given situation, and this is good enough...

Wrong.

It would absolutely terrible if every generation of developers had
to learn everything from scratch instead of benefiting from
best practices learned by previous generations of developers.

Arne

Arne Vajh�j <arne@vajhoej.dk> writes:
><quote>
>Braces are used around all statements, even single statements, when they 
>are part of a control structure, such as a if-else or for statement. 
>This makes it easier to add statements without accidentally introducing 
>bugs due to forgetting to add braces.
></quote>

  This quote, however, does not apply to �{}�: �{}� are not
  �braces used around a statement�, because �� is not a statement. 

On 21-10-2010 20:42, BGB / cr88192 wrote:
> admittedly, Java is not one of my most heavily used languages (much more of
> my development is in C and C++, and of this, a much larger portion is in C).
>
> it is possible that some amount of C-like stylistic preferences bleed over.

Java and C/C++ coding conventions differ a lot more than
the basic syntax.


> admittedly, there is a notion I have heard before, that when a person moves
> from one language to another, their style should also entirely change as
> well to be whatever is most accepted by the particular
> language/community/... personally, I find this idea both inconvinient and
> unecessary, given that these languages retain mostly similar syntax (and
> what works aesthetically in one language should work similarly well in the
> others, and if there is a severe conflict then this would imply that maybe
> something is not right).

It is not easy but one should do it.

It will be very confusing for a maintenance programmer working
on code in language X without knowing language Y, if the code
uses the coding conventions of Y.

> actually, I have seen cases where people have gone around and changed all
> the capitalization or indentation or whatever else in an existing codebase,
> and IMO this is ugly and inconvinient, as then often pieces of older code
> will no longer work simply because the capitalization is different (and then
> one has to stub things or modify the code or similar to make it fit again).

An IDE with refactoring capability can do that safely.

But I admit that the source control statistics will go
completely crazy.

Arne

On 21-10-2010 22:12, Stefan Ram wrote:
> Arne Vajh�j<arne@vajhoej.dk>  writes:
>> <quote>
>> Braces are used around all statements, even single statements, when they
>> are part of a control structure, such as a if-else or for statement.
>> This makes it easier to add statements without accidentally introducing
>> bugs due to forgetting to add braces.
>> </quote>
>
>    This quote, however, does not apply to �{}�: �{}� are not
>    �braces used around a statement�, because �� is not a statement.

I was commenting on whether it should be used for "single statement"
(which occurred in what I quoted).

I think the logic applies to no statement as well, but strictly speaking
the quote does not cover that.

Arne

On 21-10-2010 19:21, Stefan Ram wrote:
> Patricia Shanahan<pats@acm.org>  writes:
>> I disagree, strongly, with the idea of using ";" instead of braces
>> containing a comment. A ";" after the ")" of a for-statement could be a
>> typo.
>
>    In fact, nearly everything could be a typo in source code.
>
>> Someone else reading the code is going to stop and think
>> about whether the following statement should be the for-loop
>> body, especially if it uses "i".
>
>    Usually, I assume that the programmer intented what he wrote,
>    unless I have a reason to assume otherwise. Such a semicolon �;�
>    is not such a reason. An �{ /* EMPTY */ }� makes me feel
>    somewhat annoyed/offended.
>
>        NB: THE PERIOD AT THE END OF THE PREVIOUS SENTENCE WAS
>        WRITTEN INTENTIONALLY TO MARK THE END OF THE SENTENCE.
>             SEE: http://en.wikipedia.org/wiki/Full_stop

The cost of the ending period being removed is approx. zero
while the cost of the semicolon in the code could be pretty
big, so I am not sure that it makes sense to conclude
from English to code.

Arne

On 21-10-2010 19:40, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> �{ /* EMPTY */ }�
>
>    It reminds me of suggestions to write
>
> Character.isLetter( s.charAt( i ))== true
>
>    , because this is �more readable� than
>
> Character.isLetter( s.charAt( i ))
>
>    . It might be more readable for persons who know English,
>    but no or little Java. But source code becomes less readable
>    for experienced programmers when it is written with such a
>    reader in mind.

One has to stop somewhere and make some minimum assumptions
about the maintenance programmers skills.

Assuming that they know how boolean expressions work
is IMHO an OK assumption. Every developer no matter
level and language experience should know that.

Arne

On 10/21/2010 6:40 PM, Patricia Shanahan wrote:
> [...]
> int i;
> for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
> {
> /* EMPTY */
> }

     Another idiom you may encounter for empty loop bodies is

	for (i = 1; Character.isLetter(s.charAt(i)); i++)
	    continue;

.... with or without curly braces, according to local style.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 10/21/2010 7:14 PM, Arne Vajh�j wrote:
....
> It will be very confusing for a maintenance programmer working
> on code in language X without knowing language Y, if the code
> uses the coding conventions of Y.

It can be confusing even if the programmer does know both languages and
their conventions.

Patricia

On 10/21/2010 7:40 PM, Stefan Ram wrote:
> [...]
>    In C, to skip two space-separated integral numerals
>    (under certain circumstances):
>
> while( isnum( *++c )); while( isspace( *++c )); while( isnum( *++c ));
>
>    , this is obvious and intelligible. [...]

     ... and wrong, unless the "certain circumstances" happen to
include foreknowledge that the string is exactly of the given form,
and not, for example, "a23z" (which would cause the third loop to
wander drunkenly past the end of the string, inspecting whatever
random bytes it happened to find in the rest of memory).

     Personally, I cannot recall a single occasion in more than forty
years of programming when I (1) wanted to skip over two numbers this
way and (2) wanted to ignore what those numbers were and (3) had such
complete trust that no oddly-formatted strings could ever show up.
(I've had (1) and (2) together, but not along with (3); (3) almost
never holds.)  That is, I have never had the slightest urge to write
three such loops, do not expect that I ever will, and do not intend
to let them influence my style.  YMMV, but I hope sincerely that it
doesn't V appreciably.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On Thu, 21 Oct 2010 11:10:06 -0700, bcr666 wrote:

> I frequently use a for loop to empty a table something like: for
> (;table.getRowCount() > 0;table.removeRow(0)); notice, you don't even
> need the body {}, if your body is empty or one line, you can use just a
> ; to end.

Eeeuw. This is exactly the type of loop (loop until something changes 
state) that should almost always be a while:

while (table.getRowCount() > 0) {
    table.removeRow(0);
}

"Arne Vajh�j" <arne@vajhoej.dk> wrote in message 
news:4cc0f389$0$23764$14726298@news.sunsite.dk...
> On 21-10-2010 20:42, BGB / cr88192 wrote:
>> admittedly, Java is not one of my most heavily used languages (much more 
>> of
>> my development is in C and C++, and of this, a much larger portion is in 
>> C).
>>
>> it is possible that some amount of C-like stylistic preferences bleed 
>> over.
>
> Java and C/C++ coding conventions differ a lot more than
> the basic syntax.

but, in many respects the basic syntax is similar between these languages, 
and WRT things like use of braces, indentation, ... there really does not 
need to be much difference.


>> admittedly, there is a notion I have heard before, that when a person 
>> moves
>> from one language to another, their style should also entirely change as
>> well to be whatever is most accepted by the particular
>> language/community/... personally, I find this idea both inconvinient and
>> unecessary, given that these languages retain mostly similar syntax (and
>> what works aesthetically in one language should work similarly well in 
>> the
>> others, and if there is a severe conflict then this would imply that 
>> maybe
>> something is not right).
>
> It is not easy but one should do it.
>
> It will be very confusing for a maintenance programmer working
> on code in language X without knowing language Y, if the code
> uses the coding conventions of Y.

except, Java and C/C++ syntax, and common stylistic conventions, are close 
enough that, in many regards, the differences are neglibible...

granted, one can't do C style string or pointer funkiness in Java, but even 
in C these are things to be used with care, as overusing them can make code 
ugly.

some many common C-style naming conventions would be rather out of place in 
Java, but they are unneeded anyways since the language has things like 
packages and classes (and doesn't allow top-level variables and functions), 
naturally leading to some differences in naming and organization.


most of the rest are matters that people will debate endlessly with no real 
consensus.


>> actually, I have seen cases where people have gone around and changed all
>> the capitalization or indentation or whatever else in an existing 
>> codebase,
>> and IMO this is ugly and inconvinient, as then often pieces of older code
>> will no longer work simply because the capitalization is different (and 
>> then
>> one has to stub things or modify the code or similar to make it fit 
>> again).
>
> An IDE with refactoring capability can do that safely.
>
> But I admit that the source control statistics will go
> completely crazy.

it is a mess when the project is being worked on by multiple independent 
parties, and someone maintaining their own code has their code break because 
someone working on the main project (or someone on a different team, or 
whatever, ...) decided to change a bunch of stuff.


admittedly, this is a reason I am a bit fussy about wanting projects 
partitioned between individuals and groups:
it generally reduces the problem of people stepping on each other while 
working on the code, and also the matter of someone random thinking they 
know how the code should be better than the main people maintaining it, as 
well as for reducing the politics and beuracracy related to updates. since 
if each person "owns" their own little section of code, there doesn't need 
to be some much debate about localized changes, and instead people can 
debate about what happens at the borders (as the interfaces become implicit 
contracts).

or such...

"Arne Vajh�j" <arne@vajhoej.dk> wrote in message 
news:4cc0f247$0$23765$14726298@news.sunsite.dk...
> On 21-10-2010 15:55, BGB / cr88192 wrote:
>> "markspace"<nospam@nowhere.com>  wrote in message
>>> However, the body is empty, which is weird, and i has to be declared
>>> outside of the for loop so I can use it later, which is a little weird.
>>>
>>
>> actually, the braces can be omitted here, hence:
>>       for( i = 1; Character.isLetter( s.charAt( i) ); i++ );
>>
>> braces generally only really serve the purpose of lumping multiple
>> statements together into a single statement block, and so are typically 
>> left
>> out when there is only a single statement.
>
> No. In Java we typical use them even for single statements.
>

odd...


>> but, to a large degree, style is irrelevant...
>
> No. Reading code that uses different styles or very unusual
> styles make reading code slower.
>
> Slower = cost more $$$$ for maintenance.
>
> $$$$ is relevant in professional software development.
>

only if one can seriously show that most people are actually effected, in 
general, by getting confused over matters of braces and whitespace.

apart from a few edge cases:
the big ugly block of characters;
the ugly 1 or 2-space tab (luckily, this one has largely died off, as the 4 
or 8 space tab are near-universal);
....

it would be a surprise if people were really effected much.


>> in some cases, one may also have reason for using "hungarian notation",
>> although people get into arguments over this as well.
>
> Even MS has given up on that.
>

if one looks in 'windows.h' and similar, they see it all over the place, as 
well as all-caps type-names...

granted, it would be ill advised to write new code like this, as it is bad 
enough dealing with this in Windows code, but even then, it still serves a 
purpose:
"warning: this region of code is almost completely non-portable...".


>> but, ultimately, it is all pointless.
>> do what makes sense in a given situation, and this is good enough...
>
> Wrong.
>
> It would absolutely terrible if every generation of developers had
> to learn everything from scratch instead of benefiting from
> best practices learned by previous generations of developers.

people do so already...

"doing what makes sense" is, maybe 75%-90% of the time or more, following 
whatever is the common practice in a particular case...

then a person does something different when there is some good reason to do 
so, rather than adhering to dogmas even in cases where it would make the 
code worse as a result.

"making sense" is, after all, primarily a matter of localized cost 
minimization, and if following conventions makes sense, then this is what 
makes sense, and if a convention is stupid, it may make sense to blow it 
off...

"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message 
news:i9r03t$ppg$1@news.eternal-september.org...
> On 10/21/2010 7:40 PM, Stefan Ram wrote:
>> [...]
>>    In C, to skip two space-separated integral numerals
>>    (under certain circumstances):
>>
>> while( isnum( *++c )); while( isspace( *++c )); while( isnum( *++c ));
>>
>>    , this is obvious and intelligible. [...]
>
>     ... and wrong, unless the "certain circumstances" happen to
> include foreknowledge that the string is exactly of the given form,
> and not, for example, "a23z" (which would cause the third loop to
> wander drunkenly past the end of the string, inspecting whatever
> random bytes it happened to find in the rest of memory).
>
>     Personally, I cannot recall a single occasion in more than forty
> years of programming when I (1) wanted to skip over two numbers this
> way and (2) wanted to ignore what those numbers were and (3) had such
> complete trust that no oddly-formatted strings could ever show up.
> (I've had (1) and (2) together, but not along with (3); (3) almost
> never holds.)  That is, I have never had the slightest urge to write
> three such loops, do not expect that I ever will, and do not intend
> to let them influence my style.  YMMV, but I hope sincerely that it
> doesn't V appreciably.
>

I have... rarely... used code similar to the example, but usually this is 
for special case logic (typically pattern matching), where a variation from 
the accepted form is usually regarded as a match failure (some extra checks 
are then added to verify at each spot that the characters are what are 
expected, and deviation results in giving up).


othertimes though, I have used string-based logic to drive special purpose 
finite-state-machines, but an invalid string here is a potentially serious 
condition (these are places where a malformed string either means something 
has gone notably wrong, or this compromises the internal integrity of the 
code).

usually this kind of thing is mostly confined to things like code-generation 
and compilation logic, or for things operating in close proximity to the 
native calling convention, and in a few cases for self-composing or 
self-modifying code.

both my x86-assembler and x86-interpreter use some logic similar to the 
above as well (as a control notation for emitting and decoding machine 
instructions), where in this case the idea was partly motivated by something 
I saw in the Quake3 JIT engine.


but, for most general-purpose code, this sort of thing is nasty.

for general-purpose strings, I prefer to regard them as immutable atomic 
units.

On 10/22/2010 12:35 AM, ClassCastException wrote:
> On Thu, 21 Oct 2010 11:10:06 -0700, bcr666 wrote:
>
>> I frequently use a for loop to empty a table something like: for
>> (;table.getRowCount()>  0;table.removeRow(0)); notice, you don't even
>> need the body {}, if your body is empty or one line, you can use just a
>> ; to end.
>
> Eeeuw. This is exactly the type of loop (loop until something changes
> state) that should almost always be a while:
>
> while (table.getRowCount()>  0) {
>      table.removeRow(0);
> }

     Side-note and topic drift: That's an O(N^2) loop if `table' is
backed by something like an ArrayList, where all the undeleted rows
need to be slid downward to fill the vacated space.  We don't *know*
what's behind `table' in this fragment, of course, but given our
ignorance it might be prudent to write

	while (table.getRowCount() > 0) {
	    table.removeRow(table.getRowCount() - 1);
	}

Still better,

	while (! table.isEmpty()) {
	    table.removeRow(table.getRowCount() - 1);
	}

Best of all,

	table.clear();

     We now return you to your regularly scheduled style war.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

"Arne Vajh�j" <arne@vajhoej.dk> wrote in message 
news:4cc0f4a3$0$23764$14726298@news.sunsite.dk...
> On 21-10-2010 19:21, Stefan Ram wrote:
>> Patricia Shanahan<pats@acm.org>  writes:
>>> I disagree, strongly, with the idea of using ";" instead of braces
>>> containing a comment. A ";" after the ")" of a for-statement could be a
>>> typo.
>>
>>    In fact, nearly everything could be a typo in source code.
>>
>>> Someone else reading the code is going to stop and think
>>> about whether the following statement should be the for-loop
>>> body, especially if it uses "i".
>>
>>    Usually, I assume that the programmer intented what he wrote,
>>    unless I have a reason to assume otherwise. Such a semicolon �;�
>>    is not such a reason. An �{ /* EMPTY */ }� makes me feel
>>    somewhat annoyed/offended.
>>
>>        NB: THE PERIOD AT THE END OF THE PREVIOUS SENTENCE WAS
>>        WRITTEN INTENTIONALLY TO MARK THE END OF THE SENTENCE.
>>             SEE: http://en.wikipedia.org/wiki/Full_stop
>
> The cost of the ending period being removed is approx. zero
> while the cost of the semicolon in the code could be pretty
> big, so I am not sure that it makes sense to conclude
> from English to code.
>

one would have to question the competence of the programmers to make this 
case.

it becomes a matter of habit when and where to place them, and things are 
not exactly looking good for the project if the programmers are not skilled 
enough to deal with these sort of issues.

so help you if anything actually difficult pops up...

On 10/21/2010 11:17 PM, BGB / cr88192 wrote:

> but, in many respects the basic syntax is similar between these languages,
> and WRT things like use of braces, indentation, ... there really does not
> need to be much difference.


You probably already know this but Sun (now Oracle) publishes guidelines 
for Java code styles.  And pretty much everyone follows them.  While not 
enforced by the compiler to the extend that say Python does, they are 
still the de facto standard in the Java programming world.

Specifically WRT braces, Sun recommends that you always use braces, even 
for blocks that are a single statement and could use a semi-colon 
instead.  So for an empty statement, I used braces.

Arne Vajh�j <arne@vajhoej.dk> writes:
>The cost of the ending period being removed is approx. zero

  Somewhat off topic here, but:

      �Karl Kraus was convinced that every little error, albeit
      of an importance that was seemingly limited in time and
      space, shows the great evils of the world and era. Thus,
      he could see in a missing comma a symptom of that state
      of the world that would allow a world war. One of the
      main points of his writings was to show the great evils
      inherent in such seemingly small errors.

      Language was to him the most important tell-tale for the
      wrongs of the world. He viewed his contemporaries'
      careless treatment of language as a sign for their
      careless treatment of the world as a whole.�

http://en.wikipedia.org/w/index.php?title=Karl_Kraus&oldid=384906924

  Karl Kraus died in 1936 and didn't know programming
  languages, but compare the above with:

      �I have never, ever, ever seen a great software developer
      who does not have amazing attention to detail.�

http://www.softwarebyrob.com/articles/Personality_Traits_of_the_Best_Software_Developers.aspx

On 10/21/2010 11:48 PM, BGB / cr88192 wrote:

> "Arne Vajh�j"<arne@vajhoej.dk>  wrote in message
>> No. In Java we typical use them even for single statements.

> odd...


Yeah, but the de facto standard.  Someone already linked to the Java 
code style guidelines, so I won't repeat it here.


> only if one can seriously show that most people are actually effected, in
> general, by getting confused over matters of braces and whitespace.


I think they are affected.  I'm not affected by the code I wrote, but I 
assume a maintainer would be.  Therefore I asked for opinions in a 
public forum.


>
> apart from a few edge cases:
> the big ugly block of characters;
> the ugly 1 or 2-space tab (luckily, this one has largely died off, as the 4
> or 8 space tab are near-universal);


In my experience, tabs died out a decade ago.  All indentation is with 
spaces now.  I always favored tabs myself, but the world has moved on. 
Que sera sera.


> if one looks in 'windows.h' and similar, they see it all over the place, as
> well as all-caps type-names...


Well, yeah.  They have to be backwards compatible.  They can't change 
*existing* public APIs.


Trying to say this with good humor:  I get the feeling that some of your 
info is 15 years out of date. ;)

On 10/21/2010 7:04 PM, Eric Sosman wrote:

> You'd better hope that such a non-letter character exists, or
> you'll march right off the end of the string ...


Yes. :)  As has been pointed out repeatedly. :) :)  I think it is 
guaranteed, but you and everyone else was quite correct to point this 
out.  I'd better add a check in anyway, I do so dislike getting 
IndexOutOfBoundException from "working" programs.

On 22-10-2010 02:17, BGB / cr88192 wrote:
> "Arne Vajh�j"<arne@vajhoej.dk>  wrote in message
> news:4cc0f389$0$23764$14726298@news.sunsite.dk...
>> On 21-10-2010 20:42, BGB / cr88192 wrote:
>>> admittedly, Java is not one of my most heavily used languages (much more
>>> of
>>> my development is in C and C++, and of this, a much larger portion is in
>>> C).
>>>
>>> it is possible that some amount of C-like stylistic preferences bleed
>>> over.
>>
>> Java and C/C++ coding conventions differ a lot more than
>> the basic syntax.
>
> but, in many respects the basic syntax is similar between these languages,
> and WRT things like use of braces, indentation, ... there really does not
> need to be much difference.

True. There rare no need for a difference.

But there are a difference.

>>> admittedly, there is a notion I have heard before, that when a person
>>> moves
>>> from one language to another, their style should also entirely change as
>>> well to be whatever is most accepted by the particular
>>> language/community/... personally, I find this idea both inconvinient and
>>> unecessary, given that these languages retain mostly similar syntax (and
>>> what works aesthetically in one language should work similarly well in
>>> the
>>> others, and if there is a severe conflict then this would imply that
>>> maybe
>>> something is not right).
>>
>> It is not easy but one should do it.
>>
>> It will be very confusing for a maintenance programmer working
>> on code in language X without knowing language Y, if the code
>> uses the coding conventions of Y.
>
> except, Java and C/C++ syntax, and common stylistic conventions, are close
> enough that, in many regards, the differences are neglibible...

That would result in horrible code.

The basic syntax is very similar. But standard style are very
different. Common paradigms are different. Etc..

> most of the rest are matters that people will debate endlessly with no real
> consensus.

No.

There are about 99% concensus or so that it is good to follow coding
conventions.

>>> actually, I have seen cases where people have gone around and changed all
>>> the capitalization or indentation or whatever else in an existing
>>> codebase,
>>> and IMO this is ugly and inconvinient, as then often pieces of older code
>>> will no longer work simply because the capitalization is different (and
>>> then
>>> one has to stub things or modify the code or similar to make it fit
>>> again).
>>
>> An IDE with refactoring capability can do that safely.
>>
>> But I admit that the source control statistics will go
>> completely crazy.
>
> it is a mess when the project is being worked on by multiple independent
> parties, and someone maintaining their own code has their code break because
> someone working on the main project (or someone on a different team, or
> whatever, ...) decided to change a bunch of stuff.

It is always a mess to change public API's.

But if someone was sleeping while reviewing the API and
approved something completely non standard, then they
pay the price later.

Arne

"markspace" <nospam@nowhere.com> wrote in message 
news:i9sejd$a52$1@news.eternal-september.org...
> On 10/21/2010 11:17 PM, BGB / cr88192 wrote:
>
>> but, in many respects the basic syntax is similar between these 
>> languages,
>> and WRT things like use of braces, indentation, ... there really does not
>> need to be much difference.
>
>
> You probably already know this but Sun (now Oracle) publishes guidelines 
> for Java code styles.  And pretty much everyone follows them.  While not 
> enforced by the compiler to the extend that say Python does, they are 
> still the de facto standard in the Java programming world.
>
> Specifically WRT braces, Sun recommends that you always use braces, even 
> for blocks that are a single statement and could use a semi-colon instead. 
> So for an empty statement, I used braces.
>

probably, but OTOH, MS has different guidelines for C#, and C and C++ tend 
to use slightly other conventions as well...


in all cases though, most of these conventions are immaterial.

the compiler doesn't care, and there is little reason people should care 
either, since a human is smarter and more flexible than a compiler, people 
should presumably act as such...

what weight do they hold, as they are basically just statements of 
preferences by some party, rather than being based strictly on what is most 
practical or convinient, or being imposed by a limitation of the technology, 
or similar...

it is really no different than saying that one can't stir drinks with a 
screwdriver:
little exists in either the drink or the screwdriver to prevent this, and 
either way the drink gets stirred.
the only real difference then is that one has not had to go and fetch a 
spoon, and created a piece of dirty silverware, ... (since a screwdriver can 
just be wiped off...).

or such...

On 10/22/2010 11:12 AM, BGB / cr88192 wrote:

> probably, but OTOH, MS has different guidelines for C#, and C and C++ tend
> to use slightly other conventions as well...


And MS meas what to C or C++?  They implement a compiler, they don't 
issue the standard.  If IEEE or ANSI published standards for C coding, 
I'd say we should follow them.  It happens that they don't (AFAIK), so 
coding standards tend to be wild west style.

(Actually I think there are some implicit code style standards in K&R, 
but that's not quite official, so...).

Sun is... what, the copyright holder of the Java spec?  And they own 
several critical patents, apparently.  Modifying the JLS is a public 
process, because Sun wants Java to be widely supported and used, but it 
Java is their property.  They issue guidelines, the world follows those 
guidelines.  When folks who are new here post code with underbars in 
variable names (for example), it's always jarring and they always get 
corrected.

WRT C#, MS owns their baby and they can issue what guidelines they like. 
  In that case I think we should follow them.


> in all cases though, most of these conventions are immaterial.


This is where we disagree.  I think it's a big advantage for everyone to 
use the same coding standard.  All the code in Java that I see, whether 
my own, Sun's, Apache, etc. uses the same standard, and it makes it very 
easy to read.  That's a real cost driver there, imo, and every good 
professional should strive to drive done costs where practical.

"markspace" <nospam@nowhere.com> wrote in message 
news:i9sf54$ele$1@news.eternal-september.org...
> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>
>> "Arne Vajh�j"<arne@vajhoej.dk>  wrote in message
>>> No. In Java we typical use them even for single statements.
>
>> odd...
>
>
> Yeah, but the de facto standard.  Someone already linked to the Java code 
> style guidelines, so I won't repeat it here.
>

yes, but as I see it, it shouldn't matter that much...

not that I disagree with them that much either, only the idea that there 
"should" be rigid style rules, and a few misc things I think are 
pointless...


>
>> only if one can seriously show that most people are actually effected, in
>> general, by getting confused over matters of braces and whitespace.
>
> I think they are affected.  I'm not affected by the code I wrote, but I 
> assume a maintainer would be.  Therefore I asked for opinions in a public 
> forum.
>

possibly, but not likely that much, so long as it is nothing "too" 
obnoxious.


say, if one were naming their variables something like:
"NsZ__ROFLOL_ia"
one would have to question their judgement regardless of the programming 
language in use.

admittedly, I tend to dislike naming things with 
"some_glob_of_words_and_underscores", as this doesn't really help matters 
much at all...


but, inserting extra braces, or using "{}" in place of ";", ... these thing 
seem like silliness.


about the only really sane rules I think are:
in general, use "camelCase" and avoid underscores in Java (I typically only 
use underscores as scope separators in C anyways, and also when doing name 
mangling).

I use them some in a cusom version of the class library, but more for "Z_*" 
classes, which are intended to be used internally by the classlib 
implementation (IOW: they intentionally look ugly...). I may switch though 
to just simply using a "Z*" prefix instead for internal classes.

admittedly, I also tend to use an "I*" prefix some for interfaces, since it 
makes it obvious what are classes and what are interfaces.


>>
>> apart from a few edge cases:
>> the big ugly block of characters;
>> the ugly 1 or 2-space tab (luckily, this one has largely died off, as the 
>> 4
>> or 8 space tab are near-universal);
>
>
> In my experience, tabs died out a decade ago.  All indentation is with 
> spaces now.  I always favored tabs myself, but the world has moved on. Que 
> sera sera.
>

well, I still see a lot of tabs.

but, with space-based tabs, it is a matter of if the tab spot is 4 or 8 
spaces ().
a lot of older code used 2-space indentation, but I dislike this and think 4 
or 8 is better (and except in rare cases have not seen 2-space indentation 
in a long time).


>
>> if one looks in 'windows.h' and similar, they see it all over the place, 
>> as
>> well as all-caps type-names...
>
>
> Well, yeah.  They have to be backwards compatible.  They can't change 
> *existing* public APIs.
>
>
> Trying to say this with good humor:  I get the feeling that some of your 
> info is 15 years out of date. ;)
>

I am still seeing what I am still seeing, which is what I see in the 
languages I tend to use (mostly C, some C++, and some Java and C#, and some 
x86 and x86-64 assembler thrown in the mix...).

On 22-10-2010 12:42, Stefan Ram wrote:
> Arne Vajh�j<arne@vajhoej.dk>  writes:
>> The cost of the ending period being removed is approx. zero
>
>    Somewhat off topic here, but:
>
>        �Karl Kraus was convinced that every little error, albeit
>        of an importance that was seemingly limited in time and
>        space, shows the great evils of the world and era. Thus,
>        he could see in a missing comma a symptom of that state
>        of the world that would allow a world war. One of the
>        main points of his writings was to show the great evils
>        inherent in such seemingly small errors.
>
>        Language was to him the most important tell-tale for the
>        wrongs of the world. He viewed his contemporaries'
>        careless treatment of language as a sign for their
>        careless treatment of the world as a whole.�
>
> http://en.wikipedia.org/w/index.php?title=Karl_Kraus&oldid=384906924
>
>    Karl Kraus died in 1936 and didn't know programming
>    languages, but compare the above with:
>
>        �I have never, ever, ever seen a great software developer
>        who does not have amazing attention to detail.�
>
> http://www.softwarebyrob.com/articles/Personality_Traits_of_the_Best_Software_Developers.aspx

Very interesting.

And I agree with much of it.

But there is a tough world out there with budgets and deadlines.

Arne

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>On 10/21/2010 7:40 PM, Stefan Ram wrote:
>>In C, to skip two space-separated integral numerals
>>(under certain circumstances):
>>while( isnum( *++c )); while( isspace( *++c )); while( isnum( *++c ));
>(...) Personally, I cannot recall a single occasion in more than forty
>years of programming when I (1) wanted to skip over two numbers this
>way and (2) wanted to ignore what those numbers were and (3) had such

  I have been looking for similar loops �in the wild�:

  A sequence of skipping scanning while loops:

      while (!isspace(*p)) ++p; while (isspace(*p)) ++p;

http://github.com/mono/mono/blob/master/libgc/os_dep.c

  While loops with a semicolon (and no corresponding �do� in front of them):

      while (*c && *c++!='\n');

http://www.opensource.apple.com/source/man/man-4/man/man2html/man2html.c

  Well, and I believe:

      while( *p++ = *q++ );

  is an idiom known to every C programmer.

On Fri, 22 Oct 2010 16:08:12 -0700, BGB / cr88192 wrote:

> well, I still see a lot of tabs.
> 
> but, with space-based tabs, it is a matter of if the tab spot is 4 or 8
> spaces ().
> a lot of older code used 2-space indentation, but I dislike this and
> think 4 or 8 is better (and except in rare cases have not seen 2-space
> indentation in a long time).

It still seems to be standard in the Lisp/Scheme world.

ClassCastException <zjkg3d9gj56@gmail.invalid> writes:
>>a lot of older code used 2-space indentation, but I dislike this and
>>think 4 or 8 is better (and except in rare cases have not seen 2-space
>>indentation in a long time).
>It still seems to be standard in the Lisp/Scheme world.

  One Way to Format Parentheses

  There are several different ways to format texts with braces
  and parentheses. One of them is being described here.

  Indentation within Braces

  An indentation of just one space often is too small to be seen
  clearly, because the natural width and form of characters
  often varies by an amount that is not very much smaller than a
  space. Therefore, the indentation should amount to at least
  two positions. In order not to waste horizontal spaces, an
  indentation of exactly two positions is chosen. This means,
  that the left position of the next level is two larger than
  the position of the directly enclosing level.

  Indentation by two positions within a block

{ ++x;
  ++x; }
^ ^
0 2

  Bad: A small indentation by one position is not always visible
  clearly

{++x;
 ++x; }

  Good: The indentation by two positions is visible clearly

{ ++x;
  ++x; }

  Bad: A large indentation by more than two positions wastes
  horizontal space with no additional benefit

{    ++x;
     ++x; }

Spaces within braces

  In mathematics, there are often no spaces at the inner side of
  parentheses or braces in expressions, but spaces are used
  indeed at the inner side of braces in set notation, when the
  braces contain a description (not when they contain a list).

  Spaces in set notation

{ x | x  > 2 }

  This style is adopted here: One space is written at the inner
  side of braces.

  Spaces at the inner side of parentheses within a block

{ ++x; }

  This style is consistent with the indentation by two
  positions, because only using this style, corresponding parts
  of two lines have the same position.

  Bad: No space after the first brace, the two statements are
  misaligned

{++x;
  ++x; }

  Good: One space after the first brace, the two statements are
  properly aligned

{ ++x;
  ++x; }

  Bad: Two spaces after the first brace, the two statements are
  misaligned

{  ++x;
  ++x; }

  There are some exceptions to this rule: No spaces are used
  within empty braces "{}" and between two or more closing
  braces of the same direction "}}", except, when the first one
  of them is part of an empty pair "{} }" (an empty pair of
  braces if treated like a single non-braces character).

  Unified rules for all Brackets

  For simplicity and uniformity, the rules from above apply to
  all kinds of brackets, including parentheses, braces (curly
  brackets), square brackets, and angle brackets.

  Spaces within parentheses and square brackets

{ y = f( x )+ g() + a[ 2 ]; }

  Binary operators are sorrounded by a space, but the space is
  omitted, when there already is a space on the other side of a
  sequence of brackets directly beside the operator: By this rule,
  " )+" is written instead of " ) +".

  Representation of the Syntactical Structure

  A method or function definition consists of a head and a body.
  The following representation shows this structure:

  Good formatting according to the structure

void alpha() // head
{ beta(); }  // body

  The following formatting is misleading, because the line break
  does not match the structural break:

  Bad line break within the body

void alpha() { // head and the beginning of the body
  beta(); }    // the rest of the body

  This formatting also would make no sense for blocks within
  blocks. So it is often not used for such blocks. Therefore
  even the adopters of this style can not use it uniformly.

  Opening Braces Look Like "bullets"

  There is a well known style to publish lists in typography
  using bullets sticking out on the left, looking like this:

  Common list representation with bullets in typography

o This is the first point
  of this list, it is written
  here just as an example.

o Here is another entry

o This is another example given
  just as an example to show
  an example

  The braces of the beginnings of blocks stand out on the left
  just the same, when the formatting being described here is
  used, so they look quite naturally as beginning-of-a-block
  markers, when one is used to the typographical list notation:

  Left braces look like bullets to mark blocks

{ printf(); printf();
  printf(); printf(); printf();
  printf(); printf(); }

{ printf(); printf(); }

{ printf(); printf(); printf();
  printf(); printf();
  printf(); }

  Neutrality

  Someone wrote this C code:

while( fgets( eingabe, sizeof eingabe, stdin ))
  if( sscanf( eingabe, "%d", &wert )!= 1 )
    fprintf( stderr, "Please enter a number!\n" );
  else
    summe += wert;

  It amazes me that I can add braces by my style conventions
  (not changing the meaning of the code)
  without the need to change the position of any character of
  the given code or need to change the overall number of lines:

  The code from above plus braces

while( fgets( eingabe, sizeof eingabe, stdin ))
{ if( sscanf( eingabe, "%d", &wert )!= 1 )
  { fprintf( stderr, "Please enter a number!\n" ); }
  else
  { summe += wert; }}

  Insofar, my bracing style might be considered non-obtrusive.

  Lines per Contents

  Lines containing only a single brace waste vertical space, so
  less contents fits on the same screen space. Therefore, I usually
  avoid them, but sometimes I do use them, when this helps to
  increase readability. I also might temporarily use them when editing
  a section of code. Of course, they would help programmers paid or
  being judged by the lines-of-code productivity.

On Thu, 21 Oct 2010, Eric Sosman wrote:

> On 10/21/2010 6:40 PM, Patricia Shanahan wrote:
>> [...]
>> int i;
>> for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
>> {
>> /* EMPTY */
>> }
>
>    Another idiom you may encounter for empty loop bodies is
>
> 	for (i = 1; Character.isLetter(s.charAt(i)); i++)
> 	    continue;

Oh, i haven't seen that. I like that one.

> ... with or without curly braces, according to local style.

Death to braces around single statements!

Actually, whilst i'd write this:

for (i = 1; Character.isLetter(s.charAt(i)); i++) continue;

And i'm fine with this, really:

for (i = 1; Character.isLetter(s.charAt(i)); i++) {
 	continue;
}

I can't abide this:

for (i = 1; Character.isLetter(s.charAt(i)); i++)
 	continue;

That's just asking for trouble. Either the loop body is small enough to go 
on one line, or it's big enough to be a block.

tom

-- 
I'm having trouble getting women. Does anyone have Justina Robson's
email? -- Martin

On Fri, 22 Oct 2010, markspace wrote:

> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>
>> apart from a few edge cases: the big ugly block of characters; the ugly 
>> 1 or 2-space tab (luckily, this one has largely died off, as the 4 or 8 
>> space tab are near-universal);
>
> In my experience, tabs died out a decade ago.  All indentation is with 
> spaces now.  I always favored tabs myself, but the world has moved on. 
> Que sera sera.

Seriously? We use nothing but where i work. In java and XML, at least - 
for some reason, in JSP (well, HTML, really) we tend use two spaces. I 
think because JSP/HTML tends to have much more deeply nested constructs.

I think our use of tabs must stem from the fact that Eclipse, by default, 
uses tabs for indentation. They must have a reason to do that.

tom

-- 
I'm having trouble getting women. Does anyone have Justina Robson's
email? -- Martin

On Fri, 22 Oct 2010, Stefan Ram wrote:

> Arne Vajh?j <arne@vajhoej.dk> writes:
>> The cost of the ending period being removed is approx. zero
>
>  Somewhat off topic here, but:
>
>      ?Karl Kraus was convinced that every little error, albeit
>      of an importance that was seemingly limited in time and
>      space, shows the great evils of the world and era. Thus,
>      he could see in a missing comma a symptom of that state
>      of the world that would allow a world war. One of the
>      main points of his writings was to show the great evils
>      inherent in such seemingly small errors.
>
>      Language was to him the most important tell-tale for the
>      wrongs of the world. He viewed his contemporaries'
>      careless treatment of language as a sign for their
>      careless treatment of the world as a whole.?
>
> http://en.wikipedia.org/w/index.php?title=Karl_Kraus&oldid=384906924

Sounds like an interesting chap, thanks for bringing him to my attention.

>  Karl Kraus died in 1936 and didn't know programming
>  languages, but compare the above with:
>
>      ?I have never, ever, ever seen a great software developer
>      who does not have amazing attention to detail.?
>
> http://www.softwarebyrob.com/articles/Personality_Traits_of_the_Best_Software_Developers.aspx

It's certainly a quality that commands a lot of respect from me.

tom

-- 
Ten years of radio astronomy have taught humanity more about the creation
and organization of the universe than thousands of years of religion
and philosophy. -- P. C. W. Davis

On Oct 23, 1:36=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> =A0 Well, and I believe:
>
> =A0 =A0 =A0 while( *p++ =3D *q++ );
>
> =A0 is an idiom known to every C programmer.

Many compilers will give you a warning for the ";" immediately
following the closing parenthesis without at least white space in
between - likelyhood that the semicolon is there by mistake is too
high. For example

    while( *p++ =3D *q++);
        count++;

is surely a bug.

"Tom Anderson" <twic@urchin.earth.li> wrote in message 
news:alpine.DEB.1.10.1010231445460.27709@urchin.earth.li...
> On Fri, 22 Oct 2010, markspace wrote:
>
>> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>>
>>> apart from a few edge cases: the big ugly block of characters; the ugly 
>>> 1 or 2-space tab (luckily, this one has largely died off, as the 4 or 8 
>>> space tab are near-universal);
>>
>> In my experience, tabs died out a decade ago.  All indentation is with 
>> spaces now.  I always favored tabs myself, but the world has moved on. 
>> Que sera sera.
>
> Seriously? We use nothing but where i work. In java and XML, at least - 
> for some reason, in JSP (well, HTML, really) we tend use two spaces. I 
> think because JSP/HTML tends to have much more deeply nested constructs.
>
> I think our use of tabs must stem from the fact that Eclipse, by default, 
> uses tabs for indentation. They must have a reason to do that.
>

yeah, the editor I use uses tabs as well, but I have the tab-spot set at 4.
an advantage of tabs is that they adjust indent to whatever are ones' 
preferences/settings, but at the downside that they don't always keep things 
aligned exactly as wanted when moving between editors.

2 spaces for indent seems as too little IMO, as it makes it harder to 
clearly see the starts and ends of blocks.
Torvalds had defined his coding style rules as using 8-space tabs.
it was asserted that if one actually ends up using up all the screen space, 
then the function should be broken apart anyways.

also, where I put the opening brace tends to depend some on context:

usually, structs/... use the:
stuff... {
}
style, but functions/methods tend to be:
declaration...
{
    ...
}

except when they are very small, where I may use an inline form:
declaration...
    { ... }

for if/for/... I tend to leave out the braces unless needed, and will also 
have them inlined as above if this looks better.

typical formatting for an if block may be:
if...
    ...
else ...

braces will generally always be used in an if/else chain:
if...
    { ... }
else if...
    { ... }
else if...
....

since it both avoids a syntactic ambiguity, as well as avoids potential 
compiler warnings (some compilers will often start complaining about nested 
if/else without braces, as it can become ambiguous). also once before I was 
faced with a bug which had resulted from the use of nested if-else without 
braces, and confusion about which if/block got the else (at the time, I had 
thought it was outward-inward, but later realized it was inward-outward). 
the result has since been as a general matter of policy to use braces with 
if/else chains.


usually exact naming convention in use depends some on the language in use 
and on special cases (in C and C++, I use different naming conventions for 
internal and external symbols, typically different uses of capitalization 
and different treatment of '_').

in Java I have ended up some using a Z prefix some for internal classes 
which otherwise can't be private (often these are the classes which include 
all the native calls and VM-specific stuff). technically I end up using 
public as they may be used from multiple packages within in the classlib 
(thus far this is about the only place I have used this convention), but 
ideally client code shouldn't touch them (hence the Z). the Z also serves by 
tending to put them at the end of the directory listing.

an example is 'Z_ConsoleOutput' which overrides 'PrintStream' for sake of 
sending stuff to the console (IOW: "System.out"). there are various reasons 
for doing this (I would rename it "ZConsoleOutput" but this is a hassle 
since it uses JNI and I would end up having to mess with its JNI stuff...).

other cases mostly just centralize some stuff (WRT JNI interfaces), which 
the Sun apparently was intent to spread "all over the damn place" WRT 
designing the classlib (sadly, still woefully incomplete, as a lot of even 
basic stuff is stubs...).

note: I don't use Classpath due to trying to avoid GPL, and am not using the 
Apache libs here due to operating in a slightly non-standard operating 
environment (the Apache libs seem to be more designed with running directly 
on the OS in mind).

....


I tend not to use extra whitespace between operators except usually in the 
case of && and ||, and often complex expressions use extra parens to 
disambiguate (or whenever && or || are involved).

exact spacing policy tends to adapt towards surrounding code. but, for my 
own code, I tend to avoid extra spaces.

or such...

"christian.bau" <christian.bau@cbau.wanadoo.co.uk> wrote in message 
news:493ce92e-97c0-47e2-8713-2b0ab384e517@x42g2000yqx.googlegroups.com...
On Oct 23, 1:36 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> Well, and I believe:
>
> while( *p++ = *q++ );
>
> is an idiom known to every C programmer.

<--
Many compilers will give you a warning for the ";" immediately
following the closing parenthesis without at least white space in
between - likelyhood that the semicolon is there by mistake is too
high. For example

    while( *p++ = *q++);
        count++;

is surely a bug.
-->

not that I have seen...


in most C and C++ code this practice is sufficiently common that it would 
make a lot of code start spewing warnings all over the place if compilers 
were to warn about it.

but, then again, some compilers will warn about unused local variables, 
which is personally a bit annoying.
hence, it becomes fairly common to ignore many warning conditions until they 
become errors if the compiler is intent on giving too many warnings over 
pointless crap and one doesn't feel like spending all the extra time needed 
to go clean them up...

it is better when warnings are confined to more serious issues, like using 
an uninitialized variable, ...


warning: implicit conversion from 'void *' to 'Foo *' without a cast; ...
hence the dreaded "casting the result of malloc" event (some people get 
really fussy for or against casting the results of malloc calls...).


admittedly, using a while-loop to perform a copy or similar this way is 
generally ugly (usually strcpy or memcpy is preferable, and often faster).

much like, 'strcmp()' is the usual way of copying strings, and is generally 
preferable to hand-rolled loops.

but, there are many other cases where one will end up using loops like this.

On 10/23/2010 6:47 AM, Tom Anderson wrote:

> On Fri, 22 Oct 2010, markspace wrote:
>> In my experience, tabs died out a decade ago. All indentation is with
>> spaces now. I always favored tabs myself, but the world has moved on.
>> Que sera sera.


> Seriously? We use nothing but where i work. In java and XML, at least -
> for some reason, in JSP (well, HTML, really) we tend use two spaces. I
> think because JSP/HTML tends to have much more deeply nested constructs.


Yes.  It seems like any project I've worked on recently, any attempt to 
use tabs just resulted in horribly unreadable code.  Primarily my own, 
when it was used by others.  And this I didn't like.

Tabs work when you can standardize.  But to do that reliably, you need 
to use something like a vi line: /* :se ts=4 sw=4 */  And I don't see a 
lot of this in code anymore.

[Dropping comp.lang.java.programmer cross-post]

"BGB / cr88192" <cr88192@hotmail.com> writes:
[...]
> but, then again, some compilers will warn about unused local variables, 
> which is personally a bit annoying.
> hence, it becomes fairly common to ignore many warning conditions until they 
> become errors if the compiler is intent on giving too many warnings over 
> pointless crap and one doesn't feel like spending all the extra time needed 
> to go clean them up...

You find warnings about unused local variable annoying?  Why?
Is there any reason to declare a variable if you're not going to
use it?

> it is better when warnings are confined to more serious issues, like using 
> an uninitialized variable, ...
>
>
> warning: implicit conversion from 'void *' to 'Foo *' without a cast; ...
> hence the dreaded "casting the result of malloc" event (some people get 
> really fussy for or against casting the results of malloc calls...).

What C compiler (*not* C++ compiler) warns about an implicit
conversion from void* to Foo*?

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnd3r0y5r0.fsf@nuthaus.mib.org...

> "BGB / cr88192" <cr88192@hotmail.com> writes:
> [...]
>> but, then again, some compilers will warn about unused local variables,
>> which is personally a bit annoying.

> You find warnings about unused local variable annoying?  Why?
> Is there any reason to declare a variable if you're not going to
> use it?

Where code is incomplete, or in development, declarations can exist but not 
the statements that use them (or they might be commented out temporarily).

For example, if I've just written a complicated set of declarations, I might 
compile to check for errors, before I've written any actual code.

This sort of warning is useful when development has finished.

-- 
Bartc

 

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnd3r0y5r0.fsf@nuthaus.mib.org...
>> "BGB / cr88192" <cr88192@hotmail.com> writes:
>> [...]
>>> but, then again, some compilers will warn about unused local variables,
>>> which is personally a bit annoying.
>
>> You find warnings about unused local variable annoying?  Why?
>> Is there any reason to declare a variable if you're not going to
>> use it?
>
> Where code is incomplete, or in development, declarations can exist but not 
> the statements that use them (or they might be commented out temporarily).
>
> For example, if I've just written a complicated set of declarations, I might 
> compile to check for errors, before I've written any actual code.
>
> This sort of warning is useful when development has finished.

Or during maintenance, which typically continues long after development
has "finished".

Personally, I want to be warned about unused variables unless I
ask not to be.  Most compilers let you disable specific warnings.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 10/24/10 11:20 AM, BartC wrote:
>
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnd3r0y5r0.fsf@nuthaus.mib.org...
>
>> "BGB / cr88192" <cr88192@hotmail.com> writes:
>> [...]
>>> but, then again, some compilers will warn about unused local variables,
>>> which is personally a bit annoying.
>
>> You find warnings about unused local variable annoying? Why?
>> Is there any reason to declare a variable if you're not going to
>> use it?
>
> Where code is incomplete, or in development, declarations can exist but
> not the statements that use them (or they might be commented out
> temporarily).
>
> For example, if I've just written a complicated set of declarations, I
> might compile to check for errors, before I've written any actual code.

If you are doing that, your functions are too long or complex.  If the 
code as written does not require a variable, don't declare it.

-- 
Ian Collins

On 23-10-2010 09:47, Tom Anderson wrote:
> On Fri, 22 Oct 2010, markspace wrote:
>> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>>> apart from a few edge cases: the big ugly block of characters; the
>>> ugly 1 or 2-space tab (luckily, this one has largely died off, as the
>>> 4 or 8 space tab are near-universal);
>>
>> In my experience, tabs died out a decade ago. All indentation is with
>> spaces now. I always favored tabs myself, but the world has moved on.
>> Que sera sera.
>
> Seriously? We use nothing but where i work. In java and XML, at least -
> for some reason, in JSP (well, HTML, really) we tend use two spaces. I
> think because JSP/HTML tends to have much more deeply nested constructs.

Most coding conventions say spaces instead of tab.

The standard Java coding convention prescribes either
4sp,8sp,12sp,16sp or 4sp,1t,1t+4sp,2t and mixing tabs
and spaces are not really that good an idea.

Arne

On 23-10-2010 11:55, BGB / cr88192 wrote:
> 2 spaces for indent seems as too little IMO, as it makes it harder to
> clearly see the starts and ends of blocks.
> Torvalds had defined his coding style rules as using 8-space tabs.
> it was asserted that if one actually ends up using up all the screen space,
> then the function should be broken apart anyways.

He does not code much Java AFAIK, so ...

Arne

On 22-10-2010 12:27, BGB / cr88192 wrote:
> "Arne Vajh�j"<arne@vajhoej.dk>  wrote in message
> news:4cc0f4a3$0$23764$14726298@news.sunsite.dk...
>> On 21-10-2010 19:21, Stefan Ram wrote:
>>> Patricia Shanahan<pats@acm.org>   writes:
>>>> I disagree, strongly, with the idea of using ";" instead of braces
>>>> containing a comment. A ";" after the ")" of a for-statement could be a
>>>> typo.
>>>
>>>     In fact, nearly everything could be a typo in source code.
>>>
>>>> Someone else reading the code is going to stop and think
>>>> about whether the following statement should be the for-loop
>>>> body, especially if it uses "i".
>>>
>>>     Usually, I assume that the programmer intented what he wrote,
>>>     unless I have a reason to assume otherwise. Such a semicolon �;�
>>>     is not such a reason. An �{ /* EMPTY */ }� makes me feel
>>>     somewhat annoyed/offended.
>>>
>>>         NB: THE PERIOD AT THE END OF THE PREVIOUS SENTENCE WAS
>>>         WRITTEN INTENTIONALLY TO MARK THE END OF THE SENTENCE.
>>>              SEE: http://en.wikipedia.org/wiki/Full_stop
>>
>> The cost of the ending period being removed is approx. zero
>> while the cost of the semicolon in the code could be pretty
>> big, so I am not sure that it makes sense to conclude
>> from English to code.
>>
>
> one would have to question the competence of the programmers to make this
> case.
>
> it becomes a matter of habit when and where to place them, and things are
> not exactly looking good for the project if the programmers are not skilled
> enough to deal with these sort of issues.
>
> so help you if anything actually difficult pops up...

You seem to have missed one of the most basic problems
in software development.

Developers are humans.

Even if they know things, then they can still get it
wrong.

Competent programmers should certainly know the
semantics of that semicolon, but they can still
miss it when reading the code.

The probability for one programmer missing it for
one specific line is very low.

But the probability for at least one programmer
out of a large team missing it for a large code
base is goes towards certainty for larger
teams and code bases.

Arne

On 21-10-2010 18:49, BGB / cr88192 wrote:
> "Lew"<lew@lewscanon.com>  wrote in message
> news:68aa61a9-5999-410a-92d9-909966367f38@w21g2000vby.googlegroups.com...
> BGB / cr88192 wrote:
>
> <snip>
>
> nevermind that we disagree on many matters of style...
>
> I still regard that style is largely unimportant in most cases, since the
> language does not require it, and it is not like much actually bad will
> happen due to violating some stylistic rule, anymore than fire will fall
> from the ceiling due to using the wrong silverware or stiring ones' coffee
> with a knife or screwdriver or similar...
>
>
> any rules one follows are usually due to some specific or potential cost of
> violating it, and if a rule does not result in some obvious cost, why
> bother?
>
> like the braces:
> one can leave them out, and save some characters, and if later they need
> multiple statements, they can put them back in. usually the savings (in
> terms of readability and screen space) save more than the effort needed to
> type them back in later if the code is being edited.
>
> in all likelyhood, if one initially is only typing a single statement,
> likely they will never need multiple statements anyways, and hence the
> screen-space savings will be of a larger benefit.

Well - you have heard so many people tell you that consistent style
is important for readability.

Then you van believe it or not.

If you don't then we can make our conclusions.

> I have written and worked on projects in the Mloc range (including 3D
> engines and compilers and similar), and in a number of different programming
> languages (C, C++, ASM, Java, C#, ...), so I will contest this description.

If you have written MLOC projects, then we do know your true
expertise.

Arne

On 22-10-2010 14:12, BGB / cr88192 wrote:
> "markspace"<nospam@nowhere.com>  wrote in message
> news:i9sejd$a52$1@news.eternal-september.org...
>> On 10/21/2010 11:17 PM, BGB / cr88192 wrote:
>>
>>> but, in many respects the basic syntax is similar between these
>>> languages,
>>> and WRT things like use of braces, indentation, ... there really does not
>>> need to be much difference.
>>
>>
>> You probably already know this but Sun (now Oracle) publishes guidelines
>> for Java code styles.  And pretty much everyone follows them.  While not
>> enforced by the compiler to the extend that say Python does, they are
>> still the de facto standard in the Java programming world.
>>
>> Specifically WRT braces, Sun recommends that you always use braces, even
>> for blocks that are a single statement and could use a semi-colon instead.
>> So for an empty statement, I used braces.
>>
>
> probably, but OTOH, MS has different guidelines for C#, and C and C++ tend
> to use slightly other conventions as well...
>
> in all cases though, most of these conventions are immaterial.
>
> the compiler doesn't care, and there is little reason people should care
> either, since a human is smarter and more flexible than a compiler, people
> should presumably act as such...
>
> what weight do they hold, as they are basically just statements of
> preferences by some party, rather than being based strictly on what is most
> practical or convinient, or being imposed by a limitation of the technology,
> or similar...

Maybe you should read a tutorial.

In most cases coding conventions do not claim that the choice
is better or more logical than any other convention.

The main point in coding convention is consistency.

You pick a convention and stick to it.

Arne

On 22-10-2010 14:46, markspace wrote:
> On 10/22/2010 11:12 AM, BGB / cr88192 wrote:
>> probably, but OTOH, MS has different guidelines for C#, and C and C++
>> tend
>> to use slightly other conventions as well...
>
> And MS meas what to C or C++? They implement a compiler, they don't
> issue the standard. If IEEE or ANSI published standards for C coding,
> I'd say we should follow them. It happens that they don't (AFAIK), so
> coding standards tend to be wild west style.

If you do serious Win32 API/MFC/ALT programming, then you
better stick to MS coding convention.

A lot of that stuff goes way beyond the C and C++ standards
and are truly MS land.

Arne

On 22-10-2010 02:48, BGB / cr88192 wrote:
> "Arne Vajh�j"<arne@vajhoej.dk>  wrote in message
> news:4cc0f247$0$23765$14726298@news.sunsite.dk...
>> On 21-10-2010 15:55, BGB / cr88192 wrote:
>>> "markspace"<nospam@nowhere.com>   wrote in message
>>>> However, the body is empty, which is weird, and i has to be declared
>>>> outside of the for loop so I can use it later, which is a little weird.
>>>>
>>>
>>> actually, the braces can be omitted here, hence:
>>>        for( i = 1; Character.isLetter( s.charAt( i) ); i++ );
>>>
>>> braces generally only really serve the purpose of lumping multiple
>>> statements together into a single statement block, and so are typically
>>> left
>>> out when there is only a single statement.
>>
>> No. In Java we typical use them even for single statements.
>
> odd...

More odd that you were not aware.

>>> but, to a large degree, style is irrelevant...
>>
>> No. Reading code that uses different styles or very unusual
>> styles make reading code slower.
>>
>> Slower = cost more $$$$ for maintenance.
>>
>> $$$$ is relevant in professional software development.
>
> only if one can seriously show that most people are actually effected, in
> general, by getting confused over matters of braces and whitespace.

You will have to believe in the experience provided here.

>>> in some cases, one may also have reason for using "hungarian notation",
>>> although people get into arguments over this as well.
>>
>> Even MS has given up on that.
>
> if one looks in 'windows.h' and similar, they see it all over the place, as
> well as all-caps type-names...

windows.h is MS technology mid 90's.

They have dropped it for .NET (the MS technology of this decade).

>> It would absolutely terrible if every generation of developers had
>> to learn everything from scratch instead of benefiting from
>> best practices learned by previous generations of developers.
>
> people do so already...
>
> "doing what makes sense" is, maybe 75%-90% of the time or more, following
> whatever is the common practice in a particular case...
>
> then a person does something different when there is some good reason to do
> so, rather than adhering to dogmas even in cases where it would make the
> code worse as a result.

Yes.

But you are the one that has emphasized that there are no
material difference in most cases.

And in this case you should stick to the convention.

Arne

On 22-10-2010 19:08, BGB / cr88192 wrote:
> "markspace"<nospam@nowhere.com>  wrote in message
> news:i9sf54$ele$1@news.eternal-september.org...
>> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>>> "Arne Vajh�j"<arne@vajhoej.dk>   wrote in message
>>>> No. In Java we typical use them even for single statements.
>>
>>> odd...
>>
>> Yeah, but the de facto standard.  Someone already linked to the Java code
>> style guidelines, so I won't repeat it here.
>
> yes, but as I see it, it shouldn't matter that much...

The people that will have to maintain your code later may disagree.

> but, with space-based tabs, it is a matter of if the tab spot is 4 or 8
> spaces ().
> a lot of older code used 2-space indentation, but I dislike this and think 4
> or 8 is better (and except in rare cases have not seen 2-space indentation
> in a long time).

The Java standard is 4.

Arne

"Arne Vajh�j" <arne@vajhoej.dk> wrote in message 
news:4cc3963a$0$23751$14726298@news.sunsite.dk...
> On 22-10-2010 14:12, BGB / cr88192 wrote:
>> "markspace"<nospam@nowhere.com>  wrote in message
>> news:i9sejd$a52$1@news.eternal-september.org...
>>> On 10/21/2010 11:17 PM, BGB / cr88192 wrote:
>>>
>>>> but, in many respects the basic syntax is similar between these
>>>> languages,
>>>> and WRT things like use of braces, indentation, ... there really does 
>>>> not
>>>> need to be much difference.
>>>
>>>
>>> You probably already know this but Sun (now Oracle) publishes guidelines
>>> for Java code styles.  And pretty much everyone follows them.  While not
>>> enforced by the compiler to the extend that say Python does, they are
>>> still the de facto standard in the Java programming world.
>>>
>>> Specifically WRT braces, Sun recommends that you always use braces, even
>>> for blocks that are a single statement and could use a semi-colon 
>>> instead.
>>> So for an empty statement, I used braces.
>>>
>>
>> probably, but OTOH, MS has different guidelines for C#, and C and C++ 
>> tend
>> to use slightly other conventions as well...
>>
>> in all cases though, most of these conventions are immaterial.
>>
>> the compiler doesn't care, and there is little reason people should care
>> either, since a human is smarter and more flexible than a compiler, 
>> people
>> should presumably act as such...
>>
>> what weight do they hold, as they are basically just statements of
>> preferences by some party, rather than being based strictly on what is 
>> most
>> practical or convinient, or being imposed by a limitation of the 
>> technology,
>> or similar...
>
> Maybe you should read a tutorial.
>
> In most cases coding conventions do not claim that the choice
> is better or more logical than any other convention.
>
> The main point in coding convention is consistency.
>
> You pick a convention and stick to it.
>

and, in the name of consistency, one can stick to the existing practices...

now, if one goes and looks at the Apache class library, one will see that 
they don't exactly strictly follow the style conventions in the tutorial 
either...


from what I have seen, the style varies from one place to another, from one 
codebase to another, ...
and, FWIW, this doesn't matter much...

about the only real piece of style which really matters all that much is the 
naming conventions, and even then, this is only likely a minor issue.

On 21.10.2010 19:34, markspace wrote:
> I'm doing some text parsing and I'd appreciate some input on code styles
> for loops.
>
> A lot of the processing I'm currently doing involves finding a
> particular character, and then doing something with the text up to that
> point. For example:
>
> int i;
> for( i = 1; Character.isLetter( s.charAt( i) ); i++ )
> {}
> // do something with i and s here
>
> This marches ahead until it find a character that isn't a "letter",
> then, with i set to the offset of the last letter+1, is able to do
> something with that group of letters in string s.

Did you consider using regular expressions?  I do not know what your 
inputs look like and what processing you have to do with this.  But if 
you need to take the string apart in more ways you could start with

package parsing;

import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class LetterParsing {

   /** Pick a better name. */
   private static final Pattern PAT = Pattern.compile("\\A.(\\p{Alpha}*)");

   public static void main(String[] args) {
     for (final String s : args) {
       final Matcher m = PAT.matcher(s);

       if (m.find()) {
         final String letters = m.group(1);
         System.out.println("Found letters: '" + letters + "'");
       } else {
         // no match
         System.out.println("Did not find any letters in '" + s + "'");
       }
     }
   }

}

Note, I let the regexp start with a dot because your indexes start at 1!

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

On Sat, 23 Oct 2010 22:15:27 -0400, Arne Vajhøj wrote:

> On 22-10-2010 14:46, markspace wrote:
>> On 10/22/2010 11:12 AM, BGB / cr88192 wrote:
>>> probably, but OTOH, MS has different guidelines for C#, and C and C++
>>> tend
>>> to use slightly other conventions as well...
>>
>> And MS meas what to C or C++? They implement a compiler, they don't
>> issue the standard. If IEEE or ANSI published standards for C coding,
>> I'd say we should follow them. It happens that they don't (AFAIK), so
>> coding standards tend to be wild west style.
> 
> If you do serious Win32 API/MFC/ALT programming, then you better stick
> to MS coding convention.
> 
> A lot of that stuff goes way beyond the C and C++ standards and are
> truly MS land.
>
Agreed. I dislike their so-called Hungarian notation intensely. I find 
that jumble of crap at the front, e.g. psaGetValues(), obscures the name 
and, worse, if refactoring a design requires you to change the type of a 
variable or the return value from a function you have to change its name 
as well!

I think the usual K&R naming standards as codified and explained in "The 
Practise of Programming" by Kernighan and Pike are fine for C in non-MS 
shops and work acceptably in Java as well without clashing with accepted 
Java practise. It contains Java code examples as well as C, C++, awk and 
Perl. 

BTW, I'd recommend reading this book to people learning to program in 
Java. Its sections on designing code for ease of testing and debugging 
are excellent and so are its comments about optimisation and use of 
profilers to determine what sections of a program are worth optimising.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Sat, 23 Oct 2010 22:13:18 -0400, Arne Vajhøj wrote:

> The main point in coding convention is consistency.
> 
> You pick a convention and stick to it.
> 
IME one of the worst crimes a programmer can commit is to modify an 
existing program without sticking to the style it was originally written 
in. It doesn't matter how much you hate the original style - use it and 
follow its naming convention whatever that might be! 

The effect of making changes in your pet style when that's at odds to the 
original coding style are:

- everybody who works on the program in future will think you're a prat.

- if the program was already badly coded you'll just turn it into
  a complete dogs dinner.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 10/23/2010 10:04 PM, Arne Vajh�j wrote:
>
> Developers are humans.
>
> Even if they know things, then they can still get it
> wrong.
>
> Competent programmers should certainly know the
> semantics of that semicolon, but they can still
> miss it when reading the code.

     They can get it wrong even if they read it and understand
it correctly.  If I'm reading someone else's code and see an
oddly-positioned semicolon and understand perfectly well what
it signifies and what the program will do, I still may wonder:
"Did the original author really *mean* to do that, or did his
cat wander across the keyboard at just the wrong moment?"  What
should have been a routine reading turns into an archaeological
excavation; the code is understandable but not readable.

     I've seen this happen (admittedly not in Java, but that's
probably just happenstance).  Once upon a time, having some spare
cycles, I decided to crank the compiler warning levels up as high
as they'd go while dumping my then company's three million lines
of C through it, just to see what might drop from the branches.
I got what you'd expect: Lots and lots of "venial" warnings, a few
obvious mistakes with obvious fixes -- and about half a dozen cases
that were quite clearly wrong, but where more than one "obvious" fix
was possible.  Which fix?  Well, what was the author's intention?

     Two of the errors were in code whose authors were still available;
the others were "orphans" in subsystems I wasn't familiar with.  Lots
of slow digging ensued ...

     The moral: It is not enough that you write correct code; you
must also write clear code.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 10/24/2010 4:27 AM, Robert Klemme wrote:

> Did you consider using regular expressions? I do not know what your
> inputs look like and what processing you have to do with this. But if
> you need to take the string apart in more ways you could start with


I did, but I consider using regex for simple text parsing (i.e., looking 
for a single character delimiter) to be pernicious.  Regex is slow to 
execute and harder to read than a simple loop.  Therefore if I can just 
code something up "by eye" I do.  If I can't map it out in my head 
easily then I consider Regex.

"Martin Gregorie" <martin@address-in-sig.invalid> wrote in message 
news:ia17mk$a31$2@localhost.localdomain...
> On Sat, 23 Oct 2010 22:13:18 -0400, Arne Vajh�j wrote:
>
>> The main point in coding convention is consistency.
>>
>> You pick a convention and stick to it.
>>
> IME one of the worst crimes a programmer can commit is to modify an
> existing program without sticking to the style it was originally written
> in. It doesn't matter how much you hate the original style - use it and
> follow its naming convention whatever that might be!
>
> The effect of making changes in your pet style when that's at odds to the
> original coding style are:
>
> - everybody who works on the program in future will think you're a prat.
>
> - if the program was already badly coded you'll just turn it into
>  a complete dogs dinner.
>

this is the one argument here I agree with...


it doesn't really matter what some authority says the coding styles should 
be (Sun or MS or others), and ones' personal use of style should be flexible 
(style is largely immaterial anyways).

this then leaves meshing with the existing code, and this is one of the 
major ways where stylistic flexibility helps:
so one can write code which meshes with the code which is already there.


for writing ones' own code, things are a little more flexible, but I 
disagree that there is or should be any single authoritative style, and 
infact still believe that the optimal way to format something depends 
somewhat on the factors surrounding the particular piece of code in question 
(including more fluid matters, such as its overall design and style...).

for example, regions of code written in a more OO style will be better 
suited to certain formatting practices, and regions of code written in a 
more FP style will be better suited to others...


the main goal though is about minimizing costs, which may mean following 
common conventions in many/most cases, disregarding them in some others, and 
trying to style-match with the existing coding practices when working on or 
maintaining existing code (as breaking the existing style makes things ugly, 
regardless of whatever style one is using).

altering style in ways which breaks code is something to be extra avoided 
IMO, even if one doesn't like the original style all that much...

On 24-10-2010 08:03, Martin Gregorie wrote:
> On Sat, 23 Oct 2010 22:15:27 -0400, Arne Vajhøj wrote:
>
>> On 22-10-2010 14:46, markspace wrote:
>>> On 10/22/2010 11:12 AM, BGB / cr88192 wrote:
>>>> probably, but OTOH, MS has different guidelines for C#, and C and C++
>>>> tend
>>>> to use slightly other conventions as well...
>>>
>>> And MS meas what to C or C++? They implement a compiler, they don't
>>> issue the standard. If IEEE or ANSI published standards for C coding,
>>> I'd say we should follow them. It happens that they don't (AFAIK), so
>>> coding standards tend to be wild west style.
>>
>> If you do serious Win32 API/MFC/ALT programming, then you better stick
>> to MS coding convention.
>>
>> A lot of that stuff goes way beyond the C and C++ standards and are
>> truly MS land.
>>
> Agreed. I dislike their so-called Hungarian notation intensely. I find
> that jumble of crap at the front, e.g. psaGetValues(), obscures the name
> and, worse, if refactoring a design requires you to change the type of a
> variable or the return value from a function you have to change its name
> as well!

I don't like it either.

But for good and for worse that is what MS unmanaged C/C++
developers has to live with.

Arne

On 24-10-2010 08:09, Martin Gregorie wrote:
> On Sat, 23 Oct 2010 22:13:18 -0400, Arne Vajhøj wrote:
>
>> The main point in coding convention is consistency.
>>
>> You pick a convention and stick to it.
>>
> IME one of the worst crimes a programmer can commit is to modify an
> existing program without sticking to the style it was originally written
> in. It doesn't matter how much you hate the original style - use it and
> follow its naming convention whatever that might be!
>
> The effect of making changes in your pet style when that's at odds to the
> original coding style are:
>
> - everybody who works on the program in future will think you're a prat.
>
> - if the program was already badly coded you'll just turn it into
>    a complete dogs dinner.

Or the next maintainer will miss something critical, because
he assumed that everything was written in a certain style.

Arne

On 23-10-2010 23:40, BGB / cr88192 wrote:
> "Arne Vajh�j"<arne@vajhoej.dk>  wrote in message
> news:4cc3963a$0$23751$14726298@news.sunsite.dk...
>> On 22-10-2010 14:12, BGB / cr88192 wrote:
>>> probably, but OTOH, MS has different guidelines for C#, and C and C++
>>> tend
>>> to use slightly other conventions as well...
>>>
>>> in all cases though, most of these conventions are immaterial.
>>>
>>> the compiler doesn't care, and there is little reason people should care
>>> either, since a human is smarter and more flexible than a compiler,
>>> people
>>> should presumably act as such...
>>>
>>> what weight do they hold, as they are basically just statements of
>>> preferences by some party, rather than being based strictly on what is
>>> most
>>> practical or convinient, or being imposed by a limitation of the
>>> technology,
>>> or similar...
>>
>> Maybe you should read a tutorial.
>>
>> In most cases coding conventions do not claim that the choice
>> is better or more logical than any other convention.
>>
>> The main point in coding convention is consistency.
>>
>> You pick a convention and stick to it.
>>
>
> and, in the name of consistency, one can stick to the existing practices...
>
> now, if one goes and looks at the Apache class library, one will see that
> they don't exactly strictly follow the style conventions in the tutorial
> either...

Apache projects require the code to follow their specified
coding standard.

Some Apache projects follow the standard Java coding standard
completely.

Some of them follow it with a few changes. The most common change
is the location of the {.

Arne

"Arne Vajh�j" <arne@vajhoej.dk> wrote in message 
news:4cc48c64$0$23764$14726298@news.sunsite.dk...
> On 23-10-2010 23:40, BGB / cr88192 wrote:
>> "Arne Vajh�j"<arne@vajhoej.dk>  wrote in message
>> news:4cc3963a$0$23751$14726298@news.sunsite.dk...
>>> On 22-10-2010 14:12, BGB / cr88192 wrote:
>>>> probably, but OTOH, MS has different guidelines for C#, and C and C++
>>>> tend
>>>> to use slightly other conventions as well...
>>>>
>>>> in all cases though, most of these conventions are immaterial.
>>>>
>>>> the compiler doesn't care, and there is little reason people should 
>>>> care
>>>> either, since a human is smarter and more flexible than a compiler,
>>>> people
>>>> should presumably act as such...
>>>>
>>>> what weight do they hold, as they are basically just statements of
>>>> preferences by some party, rather than being based strictly on what is
>>>> most
>>>> practical or convinient, or being imposed by a limitation of the
>>>> technology,
>>>> or similar...
>>>
>>> Maybe you should read a tutorial.
>>>
>>> In most cases coding conventions do not claim that the choice
>>> is better or more logical than any other convention.
>>>
>>> The main point in coding convention is consistency.
>>>
>>> You pick a convention and stick to it.
>>>
>>
>> and, in the name of consistency, one can stick to the existing 
>> practices...
>>
>> now, if one goes and looks at the Apache class library, one will see that
>> they don't exactly strictly follow the style conventions in the tutorial
>> either...
>
> Apache projects require the code to follow their specified
> coding standard.
>
> Some Apache projects follow the standard Java coding standard
> completely.
>
> Some of them follow it with a few changes. The most common change
> is the location of the {.
>

yes, but it is not the exact same convention from the link elsewhere in the 
thread, which sort of invalidates the whole "one true convention" argument, 
in favor of a "code in this project should use 'this' particular 
convention"...

things are moderately limited though by factors, such as how far one can go 
before code starts looking weird or nasty, which usually takes a bit more 
than matters of where exactly one puts their braces, or if there is 
whitespace around operators, ...

On Sun, 24 Oct 2010 14:53:40 -0400, Arne Vajhøj wrote:

> On 24-10-2010 08:03, Martin Gregorie wrote:
>> On Sat, 23 Oct 2010 22:15:27 -0400, Arne Vajhøj wrote:
>>
>>> On 22-10-2010 14:46, markspace wrote:
>>>> On 10/22/2010 11:12 AM, BGB / cr88192 wrote:
>>>>> probably, but OTOH, MS has different guidelines for C#, and C and
>>>>> C++ tend
>>>>> to use slightly other conventions as well...
>>>>
>>>> And MS meas what to C or C++? They implement a compiler, they don't
>>>> issue the standard. If IEEE or ANSI published standards for C coding,
>>>> I'd say we should follow them. It happens that they don't (AFAIK), so
>>>> coding standards tend to be wild west style.
>>>
>>> If you do serious Win32 API/MFC/ALT programming, then you better stick
>>> to MS coding convention.
>>>
>>> A lot of that stuff goes way beyond the C and C++ standards and are
>>> truly MS land.
>>>
>> Agreed. I dislike their so-called Hungarian notation intensely. I find
>> that jumble of crap at the front, e.g. psaGetValues(), obscures the
>> name and, worse, if refactoring a design requires you to change the
>> type of a variable or the return value from a function you have to
>> change its name as well!
> 
> I don't like it either.
> 
> But for good and for worse that is what MS unmanaged C/C++ developers
> has to live with.
>
Indeed, but its yet another reason I don't write code in that environment.

BTW, what do you make of this situation: at the start of a major project 
in which there was a project manager, a technical manager and I was the 
design authority and C was the programming language, and my design and 
project-specific infrastructure specifications (e.g. a set of common 
supporting libraries to handle intra-process connections and an active 
data dictionary used to transform a set on incoming data formats to 
common internal formats) had been signed off, the TM wrote a spec. 
mandating K&R naming and coding standards and went off on leave for two 
weeks. 

Meanwhile two of us got stuck in and wrote and tested the supporting 
libraries to the standards that he'd released.

At this point the TM returned, tore up his original coding standards and 
re-issued them mandating 'Hungarian notation'. His next action was to 
tell me that the support libraries must be rewritten in hungarian 
notation.

By now the rest of the programmers were on board and we had a challenging 
deadline to meet, so I told him to get stuffed and was able to make this 
stick due to looming deadlines. All the code I wrote both then and 
subsequently (under even tighter deadlines) adhered to the original 
standards. 

I maintain he was right out order changing his issued standards so 
radically. What do you guys think?


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Tom Anderson <twic@urchin.earth.li> writes:

> On Fri, 22 Oct 2010, markspace wrote:
>
>> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>>
>>> apart from a few edge cases: the big ugly block of characters; the
>>> ugly 1 or 2-space tab (luckily, this one has largely died off, as
>>> the 4 or 8 space tab are near-universal);
>>
>> In my experience, tabs died out a decade ago.  All indentation is
>> with spaces now.  I always favored tabs myself, but the world has
>> moved on. Que sera sera.
>
> Seriously? We use nothing but where i work. In java and XML, at least
> - 
> for some reason, in JSP (well, HTML, really) we tend use two spaces. I
> think because JSP/HTML tends to have much more deeply nested
> constructs.
>
> I think our use of tabs must stem from the fact that Eclipse, by
> default, uses tabs for indentation. They must have a reason to do
> that.
>
> tom

The trouble with tabs is that everyone has a different idea of what
the spacing should be, and they rarely bother to document it because
it's so obviously the one true way.  This is manageable in a smallish
office environment but for distributed projects it turns into a
complete mess.  I've seen source files where different sections
assumed different tab widths, so that no matter how you configured
your editor some parts of it would still look wrong.  So some projects
ban the use of tabs completely [1].

Eclipse insists on indenting Java code anyway (and on breaking lines
in weird places, but that's another story) so using tabs doesn't
really offer any convenience.

[1] http://www.sfr-fresh.com/unix/misc/unzip552.tar.gz:a/unzip-5.52/proginfo/ZipPorts
(look for NO FEELTHY TABS)

-- 
Jim Janney

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> 
>      NB: THE PERIOD AT THE END OF THE PREVIOUS SENTENCE WAS
>      WRITTEN INTENTIONALLY TO MARK THE END OF THE SENTENCE.
>           SEE: http://en.wikipedia.org/wiki/Full_stop

An "/* Empty */" is more akin to a "[sic]" than a full stop,
though. How do you feel about "[sic]"?

-- 
Leif Roar Moldskred

On Mon, 25 Oct 2010, Jim Janney wrote:

> Tom Anderson <twic@urchin.earth.li> writes:
>
>> On Fri, 22 Oct 2010, markspace wrote:
>>
>>> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>>>
>>>> apart from a few edge cases: the big ugly block of characters; the
>>>> ugly 1 or 2-space tab (luckily, this one has largely died off, as
>>>> the 4 or 8 space tab are near-universal);
>>>
>>> In my experience, tabs died out a decade ago.  All indentation is
>>> with spaces now.  I always favored tabs myself, but the world has
>>> moved on. Que sera sera.
>>
>> Seriously? We use nothing but where i work. In java and XML, at least
>> -
>> for some reason, in JSP (well, HTML, really) we tend use two spaces. I
>> think because JSP/HTML tends to have much more deeply nested
>> constructs.
>>
>> I think our use of tabs must stem from the fact that Eclipse, by 
>> default, uses tabs for indentation. They must have a reason to do that.
>
> The trouble with tabs is that everyone has a different idea of what the 
> spacing should be, and they rarely bother to document it because it's so 
> obviously the one true way.  This is manageable in a smallish office 
> environment but for distributed projects it turns into a complete mess. 
> I've seen source files where different sections assumed different tab 
> widths, so that no matter how you configured your editor some parts of 
> it would still look wrong.

'Wrong' how? Whatever the tab width, things indented with the same number 
of tabs will line up, and that's what matters. Sometimes that indentation 
might be more, sometimes less. How does that matter?

Mixing tabs and spaces will wreck you, of course, but everybody knows not 
to do that.

> Eclipse insists on indenting Java code anyway (and on breaking lines
> in weird places, but that's another story)

We add a 0 to the end of the default line lengths, so it effectively never 
breaks lines. We have wide monitors, and if a line needs breaking, a 
programmer will break it.

> so using tabs doesn't really offer any convenience.

True.

tom

-- 
Vive la chimie, en particulier, et la connaissance en general. --
Herve This

Leif Roar Moldskred <leifm@huldreheim.homelinux.org> writes:
>An "/* Empty */" is more akin to a "[sic]" than a full stop,
>though. How do you feel about "[sic]"?

  �[sic!]� helps when used with wrong (and possibly
  unintended) spellings/uses/words:

      �He wrote "I used this diagrama[sic!] to obtain the values".�
      �He wrote "I rode[sic!] this diagram to obtain the values".�

  But it would not make sense with correct
  spellings/uses/words, even when somewhat unexpected:

      �( (...)
      the voice of your eyes is deeper than all roses)
      nobody, not even the rain, has such small hands�

    (E. E. Cummings)

  Addings any �[sic!]�s there would hurt the text.

  Also, �[sic!]� is never added by the original author of a
  text, but used by others, when quoting text of someone else.

Stefan Ram wrote:
>> =A0 =A0 =A0NB: [sic] THE PERIOD AT THE END OF THE PREVIOUS SENTENCE WAS
>> =A0 =A0 =A0WRITTEN INTENTIONALLY TO MARK THE END OF THE SENTENCE.
>> =A0 =A0 =A0 =A0 =A0 SEE:http://en.wikipedia.org/wiki/Full_stop
>

Leif Roar Moldskred wrote:
> An "/* Empty */" is more akin to a "[sic]" than a full stop,
> though. How do you feel about "[sic]"?
>

Similarly, you don't normally need to initialize member variables to
zero-like ('null', 'false', 0, 0L, etc.) values, and in fact will
incur a tiny performance hit if you do, but if and when you do it
emphasizes by way of literate programming that the initial value has
semantic significance beyond "I'm not yet used."

Thus:

 public class Foo
 {
    private Bar bar;        // just a normal let-the-system-initialize-
it
    private Qux qux =3D null; // emphasize that algorithm depends on
initial 'null' state
    private boolean condn =3D false; // emphasize that 'condn' starts
out 'false'
    ...
 }

Both of the indicated non-default initializations to the default value
will result in the member variable being assigned the default initial
value twice, once by default and the second time by the explicit
initialization.

--
Lew

On 25-10-2010 08:32, Tom Anderson wrote:
> On Mon, 25 Oct 2010, Jim Janney wrote:
>
>> Tom Anderson <twic@urchin.earth.li> writes:
>>
>>> On Fri, 22 Oct 2010, markspace wrote:
>>>
>>>> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>>>>
>>>>> apart from a few edge cases: the big ugly block of characters; the
>>>>> ugly 1 or 2-space tab (luckily, this one has largely died off, as
>>>>> the 4 or 8 space tab are near-universal);
>>>>
>>>> In my experience, tabs died out a decade ago. All indentation is
>>>> with spaces now. I always favored tabs myself, but the world has
>>>> moved on. Que sera sera.
>>>
>>> Seriously? We use nothing but where i work. In java and XML, at least
>>> -
>>> for some reason, in JSP (well, HTML, really) we tend use two spaces. I
>>> think because JSP/HTML tends to have much more deeply nested
>>> constructs.
>>>
>>> I think our use of tabs must stem from the fact that Eclipse, by
>>> default, uses tabs for indentation. They must have a reason to do that.
>>
>> The trouble with tabs is that everyone has a different idea of what
>> the spacing should be, and they rarely bother to document it because
>> it's so obviously the one true way. This is manageable in a smallish
>> office environment but for distributed projects it turns into a
>> complete mess. I've seen source files where different sections assumed
>> different tab widths, so that no matter how you configured your editor
>> some parts of it would still look wrong.
>
> 'Wrong' how? Whatever the tab width, things indented with the same
> number of tabs will line up, and that's what matters. Sometimes that
> indentation might be more, sometimes less. How does that matter?

Try to get it to work with labels and with stuff that require multiple
column style alignments. Not possible.

> Mixing tabs and spaces will wreck you, of course, but everybody knows
> not to do that.

Not everyone.

Arne

On Mon, 25 Oct 2010 00:09:52 -0600, Jim Janney wrote:

> Tom Anderson <twic@urchin.earth.li> writes:
> 
>> On Fri, 22 Oct 2010, markspace wrote:
>>
>>> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>>>
>>>> apart from a few edge cases: the big ugly block of characters; the
>>>> ugly 1 or 2-space tab (luckily, this one has largely died off, as the
>>>> 4 or 8 space tab are near-universal);
>>>
>>> In my experience, tabs died out a decade ago.  All indentation is with
>>> spaces now.  I always favored tabs myself, but the world has moved on.
>>> Que sera sera.
>>
>> Seriously? We use nothing but where i work. In java and XML, at least -
>> for some reason, in JSP (well, HTML, really) we tend use two spaces. I
>> think because JSP/HTML tends to have much more deeply nested
>> constructs.
>>
>> I think our use of tabs must stem from the fact that Eclipse, by
>> default, uses tabs for indentation. They must have a reason to do that.
>>
>> tom
> 
> The trouble with tabs is that everyone has a different idea of what the
> spacing should be, and they rarely bother to document it because it's so
> obviously the one true way.  This is manageable in a smallish office
> environment but for distributed projects it turns into a complete mess. 
> I've seen source files where different sections assumed different tab
> widths, so that no matter how you configured your editor some parts of
> it would still look wrong.  So some projects ban the use of tabs
> completely [1].

Nah. The trouble with tabs is that tabs very obviously should always be 
exactly 8 spaces, but 8 is way too deep an indent. ;-)

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message 
news:loops-20101023023312@ram.dialup.fu-berlin.de...
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>On 10/21/2010 7:40 PM, Stefan Ram wrote:
>>>In C, to skip two space-separated integral numerals
>>>(under certain circumstances):
>>>while( isnum( *++c )); while( isspace( *++c )); while( isnum( *++c ));
>>(...) Personally, I cannot recall a single occasion in more than forty
>>years of programming when I (1) wanted to skip over two numbers this
>>way and (2) wanted to ignore what those numbers were and (3) had such
>
>  I have been looking for similar loops �in the wild�:
>
>  A sequence of skipping scanning while loops:
>
>      while (!isspace(*p)) ++p; while (isspace(*p)) ++p;
>
> http://github.com/mono/mono/blob/master/libgc/os_dep.c
>
>  While loops with a semicolon (and no corresponding �do� in front of 
> them):
>
>      while (*c && *c++!='\n');
>
> http://www.opensource.apple.com/source/man/man-4/man/man2html/man2html.c
>
>  Well, and I believe:
>
>      while( *p++ = *q++ );
>
>  is an idiom known to every C programmer.
>

They do that though, don't they?

Scouser 

"BGB / cr88192" <cr88192@hotmail.com> might have writ, in
news:i9v341$2so$1@news.albasani.net: 

> ... some compilers will warn about unused local
> variables, which is personally a bit annoying.

I once used a "language" where some unused variables, believe it or not,
caused Fatal Errors!!  I even complained about it on Usenet in
Message <90507@sun.uucp> :
   
http://groups.google.com/group/comp.unix.wizards/msg/3774732a57ef112d?
hl=en&dmode=source 

(People e-mailed me in response to that post, saying they'd printed
it and taped it to the wall!)

> "christian.bau" <christian.bau@cbau.wanadoo.co.uk> wrote:
>> while( *p++ = *q++ );
>>
>> is an idiom known to every C programmer.

I prefer
    while (*p++ = *q++) {
    }

James Dow Allen

James Dow Allen <gmail@jamesdowallen.nospam> writes:

> "BGB / cr88192" <cr88192@hotmail.com> might have writ, in
> news:i9v341$2so$1@news.albasani.net: 
>
>> ... some compilers will warn about unused local
>> variables, which is personally a bit annoying.
>
> I once used a "language" where some unused variables, believe it or not,
> caused Fatal Errors!!  I even complained about it on Usenet in
> Message <90507@sun.uucp> :
>
> http://groups.google.com/group/comp.unix.wizards/msg/3774732a57ef112d?
> hl=en&dmode=source 
>
> (People e-mailed me in response to that post, saying they'd printed
> it and taped it to the wall!)
>
>> "christian.bau" <christian.bau@cbau.wanadoo.co.uk> wrote:
>>> while( *p++ = *q++ );
>>>
>>> is an idiom known to every C programmer.
>
> I prefer
>     while (*p++ = *q++) {
>     }
>
> James Dow Allen

Why? That's ridiculous.

The point of having no {} is that you realise that all the *serious*
stuff is going on inside the while loop statement itself.

On Oct 23, 6:39=A0pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> "christian.bau" <christian....@cbau.wanadoo.co.uk> wrote in message
>
> but, there are many other cases where one will end up using loops like th=
is.
>
for(i=3D0;i<N;i++)
  /* do work here */

or

for(i=3D0;array[i] !=3D sentinel;i++)
  /* do work here */

is my preferred method, because it doesn't corrupt the pointers. In
the olden days indexing used to be a little bit slower because the
compiler would create an extra variable and offset calculation.
However that's no longer much of a concern.

On 23 Oct, 23:12, Ian Collins <ian-n...@hotmail.com> wrote:
> On 10/24/10 11:20 AM, BartC wrote:
>
>
>
>
>
>
>
> > "Keith Thompson" <ks...@mib.org> wrote in message
> >news:lnd3r0y5r0.fsf@nuthaus.mib.org...
>
> >> "BGB / cr88192" <cr88...@hotmail.com> writes:
> >> [...]
> >>> but, then again, some compilers will warn about unused local variable=
s,
> >>> which is personally a bit annoying.
>
> >> You find warnings about unused local variable annoying? Why?
> >> Is there any reason to declare a variable if you're not going to
> >> use it?
>
> > Where code is incomplete, or in development, declarations can exist but
> > not the statements that use them (or they might be commented out
> > temporarily).
>
> > For example, if I've just written a complicated set of declarations, I
> > might compile to check for errors, before I've written any actual code.
>
> If you are doing that, your functions are too long or complex. =A0If the
> code as written does not require a variable, don't declare it.

sometimes you're forced to declare paramters you don't use (eg.
callback functions)

On 31.10.2010 13:32, Richard wrote:
> James Dow Allen <gmail@jamesdowallen.nospam> writes:
>>> "christian.bau" <christian.bau@cbau.wanadoo.co.uk> wrote:
>>>> while( *p++ = *q++ );
>>>>
>>>> is an idiom known to every C programmer.
>>
>> I prefer
>>     while (*p++ = *q++) {
>>     }
>>
>> James Dow Allen
> 
> Why? That's ridiculous.
> 
> The point of having no {} is that you realise that all the *serious*
> stuff is going on inside the while loop statement itself.

I prefer

while (*p++ = *q++)
    ;

The empty statement where the single statement always goes. Can not be
seen as a typo.

-- 

Don't relax!  It's only your tension that's holding you together.

On 11/ 1/10 02:54 AM, Nick Keighley wrote:
> On 23 Oct, 23:12, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 10/24/10 11:20 AM, BartC wrote:
>>
>>
>>
>>
>>
>>
>>
>>> "Keith Thompson"<ks...@mib.org>  wrote in message
>>> news:lnd3r0y5r0.fsf@nuthaus.mib.org...
>>
>>>> "BGB / cr88192"<cr88...@hotmail.com>  writes:
>>>> [...]
>>>>> but, then again, some compilers will warn about unused local variables,
>>>>> which is personally a bit annoying.
>>
>>>> You find warnings about unused local variable annoying? Why?
>>>> Is there any reason to declare a variable if you're not going to
>>>> use it?
>>
>>> Where code is incomplete, or in development, declarations can exist but
>>> not the statements that use them (or they might be commented out
>>> temporarily).
>>
>>> For example, if I've just written a complicated set of declarations, I
>>> might compile to check for errors, before I've written any actual code.
>>
>> If you are doing that, your functions are too long or complex.  If the
>> code as written does not require a variable, don't declare it.
>
> sometimes you're forced to declare paramters you don't use (eg.
> callback functions)

The topic was unused local variables, not unused parameters.

-- 
Ian Collins

On 11/ 1/10 12:32 AM, Richard wrote:
> James Dow Allen<gmail@jamesdowallen.nospam>  writes:
>
>> "BGB / cr88192"<cr88192@hotmail.com>  might have writ, in
>> news:i9v341$2so$1@news.albasani.net:
>>
>>> ... some compilers will warn about unused local
>>> variables, which is personally a bit annoying.
>>
>> I once used a "language" where some unused variables, believe it or not,
>> caused Fatal Errors!!  I even complained about it on Usenet in
>> Message<90507@sun.uucp>  :
>>
>> http://groups.google.com/group/comp.unix.wizards/msg/3774732a57ef112d?
>> hl=en&dmode=source
>>
>> (People e-mailed me in response to that post, saying they'd printed
>> it and taped it to the wall!)
>>
>>> "christian.bau"<christian.bau@cbau.wanadoo.co.uk>  wrote:
>>>> while( *p++ = *q++ );
>>>>
>>>> is an idiom known to every C programmer.
>>
>> I prefer
>>      while (*p++ = *q++) {
>>      }
>>
>> James Dow Allen
>
> Why? That's ridiculous.
>
> The point of having no {} is that you realise that all the *serious*
> stuff is going on inside the while loop statement itself.

It's a great way to confuse readers!

-- 
Ian Collins

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On 23 Oct, 23:12, Ian Collins <ian-n...@hotmail.com> wrote:
[...]
>> If you are doing that, your functions are too long or complex.  If the
>> code as written does not require a variable, don't declare it.
>
> sometimes you're forced to declare paramters you don't use (eg.
> callback functions)

There's usually a way to silence warnings about unused parameters, such
as

    (void)unused_param;

(But there's no *standard* way to do so.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 10/31/2010 3:04 PM, Keith Thompson wrote:
>
> There's usually a way to silence warnings about unused parameters, such
> as
>
>      (void)unused_param;
>
> (But there's no *standard* way to do so.)

     There is no *standard* way to silence any warning whatsoever,
including "scary.c: trick or treat!"

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Ian Collins <ian-news@hotmail.com> writes:
>>The point of having no {} is that you realise that all the *serious*
>>stuff is going on inside the while loop statement itself.
>It's a great way to confuse readers!

  Indeed, most people will be confused by this, since most
  people do not know the C programming language at all.
  However, a C programmer will not be confused by this (by
  definition).

  Have you ever tried to speak for someone from whom you know
  that he can not understand English very well? You will have
  noticed that you language becomes crippled and unnatural.

  We must write code that is as readable as possible. But
  we may assume that the reader

      - knows C and

      - reads every single character of the source code,

  otherwise writing readable code is impossible (because we
  cannot know upfront which specific part of C a specific
  reader will not know or which specific part of our source
  code he will miss to read).

  One exercise of my programming class for C beginners is
  to predict the output of this program:

#include <stdio.h>

int main()
{ printf( "1\n" ); /* writes "1" *
  printf( "2\n" );  * writes "2" */ }

  .

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>{ printf( "1\n" ); /* writes "1" *
>  printf( "2\n" );  * writes "2" */ }

  Or, what do you think about the following variant?
  (I am not sure if it's still valid and portable C.)

{ printf( "1\n" ); /* writes "1" *\
  printf( "2\n" ); \* writes "2" */ }

On 10/31/2010 3:22 PM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> { printf( "1\n" ); /* writes "1" *
>>   printf( "2\n" );  * writes "2" */ }
>
>    Or, what do you think about the following variant?
>    (I am not sure if it's still valid and portable C.)
>
> { printf( "1\n" ); /* writes "1" *\
>    printf( "2\n" ); \* writes "2" */ }

     I'm not entirely convinced of the pedagogical value, but
if you think this sort of thing is useful consider:

	printf ("2\n");  /*
	printf ("3\n");   * Print all the
	printf ("5\n");   * 1-digit primes
	printf ("7\n");   */

Throw in a red herring, if you wish:

	printf ("2\n");  /*
	printf ("3\n");   * Print all the
	printf ("5\n");   * 1-digit primes
	printf ("9\n");   */

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>   One exercise of my programming class for C beginners is
>   to predict the output of this program:
>
> #include <stdio.h>
>
> int main()
> { printf( "1\n" ); /* writes "1" *
>   printf( "2\n" );  * writes "2" */ }

1

The second printf() is commented out. Do I pass? :-)

sherm--

-- 
Sherm Pendley
                                   <http://camelbones.sourceforge.net>
Cocoa Developer

On 11/ 1/10 08:17 AM, Stefan Ram wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>>> The point of having no {} is that you realise that all the *serious*
>>> stuff is going on inside the while loop statement itself.
>> It's a great way to confuse readers!
>
>    Indeed, most people will be confused by this, since most
>    people do not know the C programming language at all.
>    However, a C programmer will not be confused by this (by
>    definition).

Restoring the context:

James Dow Allen <gmail@jamesdowallen.nospam> writes:

 >
 > I prefer
 >     while (*p++ = *q++) {
 >     }
 >

The confusion stems not from the syntax, but from the empty braces, did 
he intend there to be some code in there?

-- 
Ian Collins

Ian Collins ha scritto:
> On 11/ 1/10 08:17 AM, Stefan Ram wrote:
>> Ian Collins<ian-news@hotmail.com>  writes:
>>>> The point of having no {} is that you realise that all the *serious*
>>>> stuff is going on inside the while loop statement itself.
>>> It's a great way to confuse readers!
>>
>>    Indeed, most people will be confused by this, since most
>>    people do not know the C programming language at all.
>>    However, a C programmer will not be confused by this (by
>>    definition).
> 
> Restoring the context:
> 
> James Dow Allen <gmail@jamesdowallen.nospam> writes:
> 
>  >
>  > I prefer
>  >     while (*p++ = *q++) {
>  >     }
>  >
> 
> The confusion stems not from the syntax, but from the empty braces, did 
> he intend there to be some code in there?

and what if sometime in the future you need to meat up a bit the body of 
the loop?

bye

On 11/ 1/10 09:48 AM, superpollo wrote:
> Ian Collins ha scritto:
>> On 11/ 1/10 08:17 AM, Stefan Ram wrote:
>>> Ian Collins<ian-news@hotmail.com> writes:
>>>>> The point of having no {} is that you realise that all the *serious*
>>>>> stuff is going on inside the while loop statement itself.
>>>> It's a great way to confuse readers!
>>>
>>> Indeed, most people will be confused by this, since most
>>> people do not know the C programming language at all.
>>> However, a C programmer will not be confused by this (by
>>> definition).
>>
>> Restoring the context:
>>
>> James Dow Allen <gmail@jamesdowallen.nospam> writes:
>>
>> >
>> > I prefer
>> > while (*p++ = *q++) {
>> > }
>> >
>>
>> The confusion stems not from the syntax, but from the empty braces,
>> did he intend there to be some code in there?
>
> and what if sometime in the future you need to meat up a bit the body of
> the loop?

You add some.  I don't see the relevance of the question.

-- 
Ian Collins

Ian Collins ha scritto:
> On 11/ 1/10 09:48 AM, superpollo wrote:
>> Ian Collins ha scritto:
>>> On 11/ 1/10 08:17 AM, Stefan Ram wrote:
>>>> Ian Collins<ian-news@hotmail.com> writes:
>>>>>> The point of having no {} is that you realise that all the *serious*
>>>>>> stuff is going on inside the while loop statement itself.
>>>>> It's a great way to confuse readers!
>>>>
>>>> Indeed, most people will be confused by this, since most
>>>> people do not know the C programming language at all.
>>>> However, a C programmer will not be confused by this (by
>>>> definition).
>>>
>>> Restoring the context:
>>>
>>> James Dow Allen <gmail@jamesdowallen.nospam> writes:
>>>
>>> >
>>> > I prefer
>>> > while (*p++ = *q++) {
>>> > }
>>> >
>>>
>>> The confusion stems not from the syntax, but from the empty braces,
>>> did he intend there to be some code in there?
>>
>> and what if sometime in the future you need to meat up a bit the body of
>> the loop?
> 
> You add some.  I don't see the relevance of the question.

if braces are already there, then you have to type less... :-)

bye

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>{ printf( "1\n" ); /* writes "1" *
>>  printf( "2\n" );  * writes "2" */ }
>
>   Or, what do you think about the following variant?
>   (I am not sure if it's still valid and portable C.)
>
> { printf( "1\n" ); /* writes "1" *\
>   printf( "2\n" ); \* writes "2" */ }

Yes, it's valid.  The backslash on the end of the first line is
a line-splicing character if it's not followed by white space, or
just part of the comment if it is, but the program's meaning is the
same either way.  (I had thought it might affect later occurrences
of __LINE__, but the line number is defined in terms of physical
lines, not logical lines.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Ian Collins <ian-news@hotmail.com> writes:
> On 11/ 1/10 08:17 AM, Stefan Ram wrote:
>> Ian Collins<ian-news@hotmail.com>  writes:
>>>> The point of having no {} is that you realise that all the *serious*
>>>> stuff is going on inside the while loop statement itself.
>>> It's a great way to confuse readers!
>>
>>    Indeed, most people will be confused by this, since most
>>    people do not know the C programming language at all.
>>    However, a C programmer will not be confused by this (by
>>    definition).
>
> Restoring the context:
>
> James Dow Allen <gmail@jamesdowallen.nospam> writes:
>
>  >
>  > I prefer
>  >     while (*p++ = *q++) {
>  >     }
>  >
>
> The confusion stems not from the syntax, but from the empty braces, did 
> he intend there to be some code in there?

One possible alternative is:

    while (*p++ = *q++) {
        /* nothing */
    }

Another is:

    while (*p++ = *q++) {
        continue;
    }

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Sun, 31 Oct 2010 21:55:53 +0100, superpollo wrote:

> Ian Collins ha scritto:
>> On 11/ 1/10 09:48 AM, superpollo wrote:
>>> Ian Collins ha scritto:
>>>> On 11/ 1/10 08:17 AM, Stefan Ram wrote:
>>>>> Ian Collins<ian-news@hotmail.com> writes:
>>>>>>> The point of having no {} is that you realise that all the
>>>>>>> *serious* stuff is going on inside the while loop statement
>>>>>>> itself.
>>>>>> It's a great way to confuse readers!
>>>>>
>>>>> Indeed, most people will be confused by this, since most people do
>>>>> not know the C programming language at all. However, a C programmer
>>>>> will not be confused by this (by definition).
>>>>
>>>> Restoring the context:
>>>>
>>>> James Dow Allen <gmail@jamesdowallen.nospam> writes:
>>>>
>>>>
>>>> > I prefer
>>>> > while (*p++ = *q++) {
>>>> > }
>>>> >
>>>> >
>>>> The confusion stems not from the syntax, but from the empty braces,
>>>> did he intend there to be some code in there?
>>>
>>> and what if sometime in the future you need to meat up a bit the body
>>> of the loop?
>> 
>> You add some.  I don't see the relevance of the question.
> 
> if braces are already there, then you have to type less... :-)

YAGNI!

On Oct 31, 9:17=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
> =A0 One exercise of my programming class for C beginners is
> =A0 to predict the output of this program:
>
> #include <stdio.h>
>
> int main()
> { printf( "1\n" ); /* writes "1" *
> =A0 printf( "2\n" ); =A0* writes "2" */ }
>
If I didn't know C at all I'd say that '/' is a line continuation
character of some sort and * comment * is the comment syntax, and the
program consists of two printing statements.

On Oct 31, 9:17=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
> =A0 We must write code that is as readable as possible. But
> =A0 we may assume that the reader
>
> =A0 =A0 =A0 - knows C and
>
> =A0 =A0 =A0 - reads every single character of the source code,
>
> =A0 otherwise writing readable code is impossible (because we
> =A0 cannot know upfront which specific part of C a specific
> =A0 reader will not know or which specific part of our source
> =A0 code he will miss to read).
>
Yesterday I translated a Python routine into C. I've don't know Python
- I've glanced at some source but I've never read a Python primer nor
used a Python compiler/interpreter (I don't even know which). However
I was able to complete the task successfully. It's a combination of
knowing what the function was intended to achieve and the fact that
most programming languages encode similar operations with similar
syntax.

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Oct 31, 9:17 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>>
>>   We must write code that is as readable as possible. But
>>   we may assume that the reader
>>
>>       - knows C and
>>
>>       - reads every single character of the source code,
>>
>>   otherwise writing readable code is impossible (because we
>>   cannot know upfront which specific part of C a specific
>>   reader will not know or which specific part of our source
>>   code he will miss to read).
>>
> Yesterday I translated a Python routine into C. I've don't know Python
> - I've glanced at some source but I've never read a Python primer nor
> used a Python compiler/interpreter (I don't even know which). However
> I was able to complete the task successfully. It's a combination of
> knowing what the function was intended to achieve and the fact that
> most programming languages encode similar operations with similar
> syntax.

Is that a long winded way of saying you wrote some C?

If you are claiming that converting Python manually into C is
straightforward then you're right : you haven't got a clue about Python.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

On Nov 1, 8:41=A0am, Richard <rgrd...@gmail.com> wrote:
> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> > Yesterday I translated a Python routine into C. I've don't know Python
> > - I've glanced at some source but I've never read a Python primer nor
> > used a Python compiler/interpreter (I don't even know which). However
> > I was able to complete the task successfully. It's a combination of
> > knowing what the function was intended to achieve and the fact that
> > most programming languages encode similar operations with similar
> > syntax.
>
> Is that a long winded way of saying you wrote some C?
>
> If you are claiming that converting Python manually into C is
> straightforward then you're right : you haven't got a clue about Python.
>
It was an alignment algorithm. Whilst I know basically how it works,
it's tricky to get all the details right and my attempt to write in C
from scratch was taking too long. So I pulled out an existing routine
in Python and just manually translated the logic to C. The only
difficult bit was that the Python used an associative array, which of
course you can't translate directly to C. However it wasn't necessary
and it was possible to get rid of it by hard-coding.

On Nov 1, 1:59=A0am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 11/ 1/10 12:32 AM, Richard wrote:
> > James Dow Allen<gm...@jamesdowallen.nospam> =A0writes:
>
> >> "BGB / cr88192"<cr88...@hotmail.com> =A0might have writ, in
> >>news:i9v341$2so$1@news.albasani.net:
>
> >>> ... some compilers will warn about unused local
> >>> variables, which is personally a bit annoying.
>
> >> I once used a "language" where some unused variables, believe it or no=
t,
> >> caused Fatal Errors!! =A0I even complained about it on Usenet in
> >> Message<90...@sun.uucp> =A0:
>
> >>http://groups.google.com/group/comp.unix.wizards/msg/3774732a57ef112d?
> >> hl=3Den&dmode=3Dsource
>
> >> (People e-mailed me in response to that post, saying they'd printed
> >> it and taped it to the wall!)
>
> >>> "christian.bau"<christian....@cbau.wanadoo.co.uk> =A0wrote:
> >>>> while( *p++ =3D *q++ );
>
> >>>> is an idiom known to every C programmer.
>
> >> I prefer
> >> =A0 =A0 =A0while (*p++ =3D *q++) {
> >> =A0 =A0 =A0}
>
> >> James Dow Allen
>
> > Why? That's ridiculous.
>
> > The point of having no {} is that you realise that all the *serious*
> > stuff is going on inside the while loop statement itself.
>
> It's a great way to confuse readers!

I find these objections baffling.  It's only a short slide from
     while (foo) ;
to
     while (foo) gak;
so the construction
     while (foo) {
     }
is the clearest way *to emphasize* that the while-body is empty!

An ironic fact is that, if I'm sure the while-body will remain
empty "forever" I might use a third form
    while (foo)
         ;
but posted the form with braces as being "better style"!   :-)

But finally, and more importantly, there is something else about
these responses that astounds me.  My earlier post was on a
completely different matter -- languages that consider unused
variables to be "fatal errors" and my then-thought amusing
post on the topic.  No one responded to that, focussing instead
on the trivial stylistic variation I mentioned at the end of
my post almost parenthetically.

Fine.  *AND YET NONE OF YOU DELETED* the other matter from the
quoted text: it's still visible in this response, traveling
through two quoters!  You quibble about the placement of
white space in a C program, yet don't know enough to do trivial
edits of quoted material in Usenet responses!!

Increasingly, this newsgroup cracks me up.

James Dow Allen

James Dow Allen wrote:
> But finally, and more importantly, there is something else about
> these responses that astounds me.  My earlier post was on a
> completely different matter -- languages that consider unused
> variables to be "fatal errors" and my then-thought amusing
> post on the topic.  No one responded to that, focussing instead
> on the trivial stylistic variation I mentioned at the end of
> my post almost parenthetically.

Perhaps no one cared about the other point.

> Fine.  *AND YET NONE OF YOU DELETED* the other matter from the

OOOOO!  Snap!

> quoted text: it's still visible in this response, traveling
> through two quoters!  You quibble about the placement of

Awwwww, gee whiz!

> white space in a C program, yet don't know enough to do trivial
> edits of quoted material in Usenet responses!!

Is it really a matter of knowledge?  Somehow I don't think so.

> Increasingly, this newsgroup cracks me up.

Blah, blah, blah.  (BTW, which of the two newsgroups did you mean by "this" one?)

And what exactly did your post contribute?   Nothing.

-- 
Lew

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
news:177302da-1c92-4122-81d6-afb93c2e37e1@p1g2000yqm.googlegroups.com...
On Oct 23, 6:39 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> "christian.bau" <christian....@cbau.wanadoo.co.uk> wrote in message
>
> but, there are many other cases where one will end up using loops like 
> this.
>

<--
for(i=0;i<N;i++)
  /* do work here */

or

for(i=0;array[i] != sentinel;i++)
  /* do work here */

is my preferred method, because it doesn't corrupt the pointers. In
the olden days indexing used to be a little bit slower because the
compiler would create an extra variable and offset calculation.
However that's no longer much of a concern.
-->

it is often still a little slower, as the compiler will often calculate the 
offset in a secondary register and then use an indirect memory load to 
access it.

j=*p++;
is still often a little faster than:
j=p[i];

although, for most cases the differences are small enough to be ignored.

all this may sometimes lead to loops like:
for(p=start; p<end; p++)
    ... do something with p ...

nevermind this:
for(obj=first; obj; obj=obj->next)
    ... do something with obj ...


but, in general, one is better advised to leave things to style, and only 
really try to micro-optimize in cases where the profiler says it is 
needed...

On Nov 1, 2:04=A0pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
>
> it is often still a little slower, as the compiler will often calculate t=
he
> offset in a secondary register and then use an indirect memory load to
> access it.
>
> j=3D*p++;
> is still often a little faster than:
> j=3Dp[i];
>
> although, for most cases the differences are small enough to be ignored.
>

I've only got tcc, which though a fine compiler isn't really intended
to be cutting edge state of the art.

Can someone compile these two to assembly with a mainstream compiler
like gcc / MS Visual C ?

char *strcpyindex(char *dest, char *src)
{
  int i;

  for(i=3D0;src[i];i++)
    dest[i] =3D src[i];
  dest[i] =3D 0;
  return dest;
}

char *strcpyptr(char *dest, char *src)
{
  char *answer =3D dest;

  while(*dest++ =3D *src++);
  return answer;
}

On 11/01/2010 08:43 AM, Malcolm McLean wrote:
> char *strcpyindex(char *dest, char *src)
> {
>    int i;
>
>    for(i=0;src[i];i++)
>      dest[i] = src[i];
>    dest[i] = 0;
>    return dest;
> }

[gcc -O2]
	xorl	%ebx, %ebx
	movl	8(%ebp), %eax
	movzbl	(%esi), %ecx
	testb	%cl, %cl
	je	.L3
..L6:
	addl	$1, %edx
	movb	%cl, (%eax,%ebx)
	movzbl	(%esi,%edx), %ecx
	movl	%edx, %ebx
	testb	%cl, %cl
	jne	.L6
..L3:
	movb	$0, (%eax,%ebx)

> char *strcpyptr(char *dest, char *src)
> {
>    char *answer = dest;
>
>    while(*dest++ = *src++);
>    return answer;
> }

..L10:
	movzbl	(%ebx,%edx), %ecx
	movb	%cl, (%eax,%edx)
	addl	$1, %edx
	testb	%cl, %cl
	jne	.L10

-O2 converted the arrays into pointers (kind of), but, oddly enough, 
didn't think to eliminate the use of %ebx as redundant with %ebx 
(perhaps array-to-pointer conversion pass happens after subexpression 
elimination?). Otherwise, the two loops are exactly identical.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--232016332-1694142445-1288645372=:4900
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Sun, 31 Oct 2010, Malcolm McLean wrote:

> On Oct 31, 9:17�pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
>> � We must write code that is as readable as possible. But
>> � we may assume that the reader
>>
>> � � � - knows C and
>>
>> � � � - reads every single character of the source code,
>>
>> � otherwise writing readable code is impossible (because we
>> � cannot know upfront which specific part of C a specific
>> � reader will not know or which specific part of our source
>> � code he will miss to read).
>
> Yesterday I translated a Python routine into C. I've don't know Python - 
> I've glanced at some source but I've never read a Python primer nor used 
> a Python compiler/interpreter (I don't even know which). However I was 
> able to complete the task successfully. It's a combination of knowing 
> what the function was intended to achieve and the fact that most 
> programming languages encode similar operations with similar syntax.

Python has been called 'executable pseudocode'. If written cleanly, it is 
highly readable, even to those who don't know it.

If written badly, of course, it's as bad as the cleanest bits of perl.

tom

-- 
Through the darkness of Future Past the magician longs to see.
--232016332-1694142445-1288645372=:4900--

On Sun, 31 Oct 2010, Stefan Ram wrote:

>  One exercise of my programming class for C beginners is
>  to predict the output of this program:
>
> #include <stdio.h>
>
> int main()
> { printf( "1\n" ); /* writes "1" *
>  printf( "2\n" );  * writes "2" */ }

Crafty!

But will it even compile, given the lack of a return statement in a 
non-void-returning method?

Maybe it will, being C. It bloody well shouldn't though!

tom

-- 
Through the darkness of Future Past the magician longs to see.

According to Tom Anderson  <twic@urchin.earth.li>:
> But will it even compile, given the lack of a return statement in a 
> non-void-returning method?

In C, the lack of a return statement in a non-void-returning method is
allowed. What triggers "undefined behaviour" (aka "all of Hell is
breaking loose") is reaching the closing '}' of a function _and_ trying
to use the returned value (or, more appropriately, the value which
should have been returned but was not). In a C implementation with a
well-defined compilation phase (that's the normal state of affairs in
C), the compilation MUST NOT fail on such a lack of a return statement
in a non-void-returning function: problems implied by that lack of
return may become apparent only at runtime.

Also, there is a special provision for the main() method, in which
falling off the function end is explicitly defined to have the same
effect as returning a zero (i.e. reporting a "success" to the operating
system).


Of course, nothing of the above prevents a C compiler from emitting
a warning about the lack of return.


> Maybe it will, being C. It bloody well shouldn't though!

C is not for the faint of heart. It probably isn't for the sane of
brain either.


	--Thomas Pornin

"Tom Anderson" <twic@urchin.earth.li> wrote in message 
news:alpine.DEB.1.10.1011012102020.4900@urchin.earth.li...

> Python has been called 'executable pseudocode'. If written cleanly, it is
> highly readable, even to those who don't know it.

I think Python is the last language I'd use for pseudocode.  No-one writing 
Python can resist using all it's features which renders it incomprehensible 
to anyone else. And for porting code, it is also necessary to duplicate it's 
myriad libraries.

Probably Lua is better for that role, being far simpler with less built-in 
stuff.

-- 
Bartc 

On 11/1/2010 5:05 PM, Tom Anderson wrote:
> On Sun, 31 Oct 2010, Stefan Ram wrote:
>
>> One exercise of my programming class for C beginners is
>> to predict the output of this program:
>>
>> #include <stdio.h>
>>
>> int main()
>> { printf( "1\n" ); /* writes "1" *
>> printf( "2\n" ); * writes "2" */ }
>
> Crafty!
>
> But will it even compile, given the lack of a return statement in a
> non-void-returning method?
>
> Maybe it will, being C. It bloody well shouldn't though!

     Under C90 rules it will compile, but the effect is undefined
(unless the environment chooses to ignore the returned value).
Under C99 rules it will compile, and will return zero.

     I agree heartily with your final sentence.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>It bloody well shouldn't though!
>I agree heartily with your final sentence.

  By this you agree with a sentence with an expletive, but
  whatever: This reminds my of one of my own style rules, that
  I can apply to both topics discussed here: loops and the
  main function:

      �When two wordings are equivalent, use the shorter one.�

  Thus, �; while( example() );�, not �; while( example() ){}�,
  and �int main(){}�, not �int main(){ return 0; }�.

  (A semicolon was added above in front of the �while�
  to clarify that this is not the tail of a do loop.)

  This rule, however does not apply to formatting (white space),
  so �{ return 0; }� is ok, even if �{return 0;}� would be
  shorter.

  In the case of �while( 1 )� versus �for( ;; )� I am not sure:
  The for loop is shorter in terms of non-whitespace characters
  while the while loop is shorter in terms of tokens.

On 11/1/2010 6:40 PM, Stefan Ram wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>>> It bloody well shouldn't though!
>> I agree heartily with your final sentence.
>
>    By this you agree with a sentence with an expletive, but
>    whatever: This reminds my of one of my own style rules, that
>    I can apply to both topics discussed here: loops and the
>    main function:
>
>        �When two wordings are equivalent, use the shorter one.�
....

Do you consider this rule a way of making the code as readable as
possible, or a substitute for that approach?

Patricia

Patricia Shanahan <pats@acm.org> writes:
>Do you consider this rule a way of making the code as readable as
>possible, or a substitute for that approach?

  Possibly, we sometimes make terms absolute, which really
  need a referent. �Readable� might be a predicate of a text
  and a reader:

      Readable( text, reader ),

  not of a text alone

      Readable( text ).

  Having said this, I see this rule as a rule that can coexist
  with a rule requiring readability and maintainability but in
  parts has a different scope.

  It is much more precise. While one man's readability could
  be another man's obfuscation, the lenght of a code segment
  is more objective.

  Usually, any unnecessary part will catch the attention of
  the reader and might disctract him or make him think about
  something irrelevant (that is, �why was this verbose/
  unnecessary part added here?�).

  For example, we have:

      cos 2x = cos� x - sin� x

  If this is written as

      cos 2x =( cos� x )-( sin� x ),

  , one man might say �Great! Now I finally see the
  precedences - that 's more readable!�, another man might say
  �Well, what does the author want to convey with the
  additional redundant braces?�. So, it might be difficult to
  be sure what is �more readable� of the two. In such case my
  brevity rule helps to find a �canonical� form, that is, to
  prefer the first one.

  But I see my rule more in terms of token counts than in
  terms of letter counts, so I do not want to oppose variable
  names to be sufficiently long to carry enough meaning to
  help the reader to understand the code.

  I would say that, when it is obvious what is more readable,
  the more readable variant should be chosen and would restrict
  my brevity rule to a subordinate r�le, that is, only when
  the readability of two choice does not differ that much or
  can not be determined precisely enough to make a clear choice,
  the I would go for the shorter one.

  It should have become clear that I do not see any problem
  whatsoever to read a loop body made of a semicolon statement
  solely or a main function implicitly returning a value, so
  in these cases, I do not hesitate to apply my brevity rul
  rule. I would not apply it, should it's result look
  obviously less readable to me, because in this case,
  readability would be more important than brevity.

On 11/1/2010 9:40 PM, Stefan Ram wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>>> It bloody well shouldn't though!
>> I agree heartily with your final sentence.
>
>    By this you agree with a sentence with an expletive, but
>    whatever: This reminds my of one of my own style rules, that
>    I can apply to both topics discussed here: loops and the
>    main function:
>
>        �When two wordings are equivalent, use the shorter one.�

     ITYM "When two wordings are equivalent, use the shorter."

     ;-)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>It bloody well shouldn't though!
>>I agree heartily with your final sentence.
>
>   By this you agree with a sentence with an expletive, but
>   whatever: This reminds my of one of my own style rules, that
>   I can apply to both topics discussed here: loops and the
>   main function:
>
>       »When two wordings are equivalent, use the shorter one.«

This just shifts all the burden onto the word "equivalent".  If one form
is clearer than another, are they equivalent?  Surely you can't mean
simply semantic equivalence?

>   Thus, »; while( example() );«, not »; while( example() ){}«,
>   and »int main(){}«, not »int main(){ return 0; }«.

I won't comment on the style since discussions of that sort are so often
unproductive.

>   (A semicolon was added above in front of the »while«
>   to clarify that this is not the tail of a do loop.)

But it may still be the tail of a do loop!  If you really must show that
the while is at the start of a statement, you could use a label:

  x: while (example());

or, I think, you could write:

  ) while (example());

or

  else while (example());

<snip>
-- 
Ben.

Stefan Ram wrote:
>> »When two wordings are equivalent, use the shorter one.«

Eric Sosman wrote:
> ITYM "When two wordings are equivalent, use the shorter."
>
> ;-)

   Simplify! Simplify! Simplify!
   - Henry David Thoreau

   One simplify would have sufficed.
   - Ralph Waldo Emerson

However, what may be a good rule for code (and I am not saying it is) does not 
make a good rule for literature.  Verbosity is a tool of the literate every 
bit as much as brevity.

One "simplify" may well have sufficed, or perhaps Thoreau intended the 
self-contradiction, or perhaps was setting up Emerson for the reply.  (They 
were good friends and in the habit of trading quips.)  For the latter two 
purposes, one "simplify" would not have sufficed.

It's all accordin'.  One may write

  for ( int len; (len = read( buf )) > 0; output( buf, len ) )
  {
  }

with intentional bracely verbosity specifically to call attention to the empty 
loopness of the construct, granting the equivalence in readability but 
asserting the need for emphasis, in which case one semicolon would not suffice.

-- 
Lew
"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de 
la faire plus courte."
Blaise Pascal, 1623-1662

Thomas Pornin <pornin@bolet.org> writes:

> According to Tom Anderson  <twic@urchin.earth.li>:
>> But will it even compile, given the lack of a return statement in a 
>> non-void-returning method?
>
> In C, the lack of a return statement in a non-void-returning method is
> allowed. What triggers "undefined behaviour" (aka "all of Hell is
> breaking loose") is reaching the closing '}' of a function _and_ trying
> to use the returned value (or, more appropriately, the value which
> should have been returned but was not). In a C implementation with a
> well-defined compilation phase (that's the normal state of affairs in
> C), the compilation MUST NOT fail on such a lack of a return statement
> in a non-void-returning function: problems implied by that lack of
> return may become apparent only at runtime.

I've often wondered - although I'd never write it - about something like
this:

int process_items(struct thing *items, int mode) {
    if(mode == 0) {
      /* do some stuff */
      return;
    } else {
      int count = 0;
      /* do some other stuff, counting items */
      return count;
   }
}

int main(void) {
    struct thing *stuff = create_items();
    /* set up items etc ... */
    process_items(stuff,1);
    printf("There are %d\n",process_items(stuff));
    return EXIT_SUCCESS;
}

As I said, lots of reasons not to do it that way - including that this
toy is clearly a case for a single return and a function-wide count variable that
is always returned - but is it entirely OK?

> C is not for the faint of heart. It probably isn't for the sane of
> brain either.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

On Tue, 02 Nov 2010 00:17:13 -0400, Lew wrote:

> Stefan Ram wrote:
>>> »When two wordings are equivalent, use the shorter one.«
> 
> Eric Sosman wrote:
>> ITYM "When two wordings are equivalent, use the shorter."
>>
>> ;-)
> 
>    Simplify! Simplify! Simplify!
>    - Henry David Thoreau
> 
>    One simplify would have sufficed.
>    - Ralph Waldo Emerson
> 
> However, what may be a good rule for code (and I am not saying it is)
> does not make a good rule for literature.  Verbosity is a tool of the
> literate every bit as much as brevity.
> 
> One "simplify" may well have sufficed, or perhaps Thoreau intended the
> self-contradiction, or perhaps was setting up Emerson for the reply. 
> (They were good friends and in the habit of trading quips.)  For the
> latter two purposes, one "simplify" would not have sufficed.
> 
> It's all accordin'.  One may write
> 
>   for ( int len; (len = read( buf )) > 0; output( buf, len ) ) {
>   }
> 
> with intentional bracely verbosity specifically to call attention to the
> empty loopness of the construct, granting the equivalence in readability
> but asserting the need for emphasis, in which case one semicolon would
> not suffice.

Emphasis also provides a fourth reason for tripling the "Simplify!".

Nick <3-nospam@temporary-address.org.uk> writes:

> Thomas Pornin <pornin@bolet.org> writes:
<snip>
>> In C, the lack of a return statement in a non-void-returning method is
>> allowed. What triggers "undefined behaviour" (aka "all of Hell is
>> breaking loose") is reaching the closing '}' of a function _and_ trying
>> to use the returned value (or, more appropriately, the value which
>> should have been returned but was not).
<snip>
> I've often wondered - although I'd never write it - about something like
> this:
>
> int process_items(struct thing *items, int mode) {
>     if(mode == 0) {
>       /* do some stuff */
>       return;
>     } else {
>       int count = 0;
>       /* do some other stuff, counting items */
>       return count;
>    }
> }
>
> int main(void) {
>     struct thing *stuff = create_items();
>     /* set up items etc ... */
>     process_items(stuff,1);
>     printf("There are %d\n",process_items(stuff));

There should be a second argument in this call, but that's not the point
of your post.

>     return EXIT_SUCCESS;
> }
>
> As I said, lots of reasons not to do it that way - including that this
> toy is clearly a case for a single return and a function-wide count
> variable that is always returned - but is it entirely OK?

No, not in C99.  The presence of either a return with an expression in a
void function; or the presence of one without in a non-void function are
constraint violations in C99.

If you remove the first return statement altogether (and thus simply
allow execution to "fall off the end" of the function) then the program
is OK (presuming that there are all the right declarations, of course).

-- 
Ben.

On Mon, 1 Nov 2010, Thomas Pornin wrote:

> According to Tom Anderson  <twic@urchin.earth.li>:
>> But will it even compile, given the lack of a return statement in a
>> non-void-returning method?
>
> In C, the lack of a return statement in a non-void-returning method is
> allowed. What triggers "undefined behaviour" (aka "all of Hell is
> breaking loose") is reaching the closing '}' of a function _and_ trying
> to use the returned value (or, more appropriately, the value which
> should have been returned but was not). In a C implementation with a
> well-defined compilation phase (that's the normal state of affairs in
> C), the compilation MUST NOT fail on such a lack of a return statement
> in a non-void-returning function: problems implied by that lack of
> return may become apparent only at runtime.

Thanks - and to Eric - for the explanation.

> Of course, nothing of the above prevents a C compiler from emitting a 
> warning about the lack of return.

Nor, presumably, from doing something crafty to cause that usage to blow 
up loudly at runtime.

tom

-- 
Scheme is simple and elegant *if you're a computer*.

On Tue, 2 Nov 2010, Stefan Ram wrote:

> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>> It bloody well shouldn't though!
>> I agree heartily with your final sentence.
>
>  By this you agree with a sentence with an expletive, but
>  whatever: This reminds my of one of my own style rules, that
>  I can apply to both topics discussed here: loops and the
>  main function:
>
>      ?When two wordings are equivalent, use the shorter one.?

I can assure you that that sentence is not equivalent to the one without 
the expletive. I have CVS records of a week of code cleanup to prove it.

tom

-- 
Scheme is simple and elegant *if you're a computer*.

On Mon, 01 Nov 2010 23:40:24 -0400, Eric Sosman  
<esosman@ieee-dot-org.invalid> wrote:

> On 11/1/2010 9:40 PM, Stefan Ram wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
....
>>        »When two wordings are equivalent, use the shorter one.«
>
>      ITYM "When two wordings are equivalent, use the shorter."
>
>      ;-)

By induction, we could shorten this to
    "When wordings are equivalent, use the shortest."
-- 
Morris Keesan -- mkeesan@post.harvard.edu

On Nov 2, 6:12=A0pm, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
> On Mon, 01 Nov 2010 23:40:24 -0400, Eric Sosman =A0
>
>
>
> <esos...@ieee-dot-org.invalid> wrote:
> > On 11/1/2010 9:40 PM, Stefan Ram wrote:
> >> Eric Sosman<esos...@ieee-dot-org.invalid> =A0writes:
> ...
> >> =A0 =A0 =A0 =A0=BBWhen two wordings are equivalent, use the shorter on=
e.=AB
>
> > =A0 =A0 =A0ITYM "When two wordings are equivalent, use the shorter."
>
> > =A0 =A0 =A0;-)
>
> By induction, we could shorten this to
> =A0 =A0 "When wordings are equivalent, use the shortest."
> --
> Morris Keesan -- mkee...@post.harvard.edu

Use the shortest of equivalent wordings.

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Nov 2, 6:12 pm, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>> On Mon, 01 Nov 2010 23:40:24 -0400, Eric Sosman  
>>
>> <esos...@ieee-dot-org.invalid> wrote:
>> > On 11/1/2010 9:40 PM, Stefan Ram wrote:
>> >> Eric Sosman<esos...@ieee-dot-org.invalid>  writes:
>> ...
>> >>        »When two wordings are equivalent, use the shorter one.«
>>
>> >      ITYM "When two wordings are equivalent, use the shorter."
>>
>> >      ;-)
>>
>> By induction, we could shorten this to
>>     "When wordings are equivalent, use the shortest."
>> --
>> Morris Keesan -- mkee...@post.harvard.edu
>
> Use the shortest of equivalent wordings.

Wrdngs equiv? Shrtst!

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Tue, 02 Nov 2010 09:27:19 -0700, Keith Thompson wrote:

> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Nov 2, 6:12 pm, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>>> On Mon, 01 Nov 2010 23:40:24 -0400, Eric Sosman
>>>
>>> <esos...@ieee-dot-org.invalid> wrote:
>>> > On 11/1/2010 9:40 PM, Stefan Ram wrote:
>>> >> Eric Sosman<esos...@ieee-dot-org.invalid>  writes:
>>> ...
>>> >>        »When two wordings are equivalent, use the shorter one.«
>>>
>>> >      ITYM "When two wordings are equivalent, use the shorter."
>>>
>>> >      ;-)
>>>
>>> By induction, we could shorten this to
>>>     "When wordings are equivalent, use the shortest."
>>> --
>>> Morris Keesan -- mkee...@post.harvard.edu
>>
>> Use the shortest of equivalent wordings.
> 
> Wrdngs equiv? Shrtst!

WES!

Tom Anderson <twic@urchin.earth.li> writes:

> On Mon, 1 Nov 2010, Thomas Pornin wrote:
>
>> According to Tom Anderson  <twic@urchin.earth.li>:
>>> But will it even compile, given the lack of a return statement in a
>>> non-void-returning method?
>>
>> In C, the lack of a return statement in a non-void-returning method is
>> allowed. What triggers "undefined behaviour" (aka "all of Hell is
>> breaking loose") is reaching the closing '}' of a function _and_ trying
>> to use the returned value (or, more appropriately, the value which
>> should have been returned but was not). In a C implementation with a
>> well-defined compilation phase (that's the normal state of affairs in
>> C), the compilation MUST NOT fail on such a lack of a return statement
>> in a non-void-returning function: problems implied by that lack of
>> return may become apparent only at runtime.
>
> Thanks - and to Eric - for the explanation.
>
>> Of course, nothing of the above prevents a C compiler from emitting
>> a warning about the lack of return.
>
> Nor, presumably, from doing something crafty to cause that usage to
> blow up loudly at runtime.

That depends on what you mean by "that usage"!

Just to be 100% clear: the simple fact of omitting the return (in some
path through the function) can not, of itself, cause anything to blow up
at run-time.  Anything at all is permitted, however, if the caller
attempts to use the value that was not returned (if you see what I
mean).

This is probably what you meant, but given the placement of the remark
there was some scope for other readers to misunderstand.

-- 
Ben.

On 01.11.2010 22:30, BartC wrote:
> "Tom Anderson" <twic@urchin.earth.li> wrote in message
> news:alpine.DEB.1.10.1011012102020.4900@urchin.earth.li...
>
>> Python has been called 'executable pseudocode'. If written cleanly, it is
>> highly readable, even to those who don't know it.
>
> I think Python is the last language I'd use for pseudocode. No-one
> writing Python can resist using all it's features which renders it
> incomprehensible to anyone else. And for porting code, it is also
> necessary to duplicate it's myriad libraries.
>
> Probably Lua is better for that role, being far simpler with less
> built-in stuff.

Of course I have to throw in Ruby here.  Very clean syntax, clean OO 
implementation and no significant whitespace.  I often find that Ruby 
code looks like pseudo code - but it actually can be executed.  :-)

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>It bloody well shouldn't though!
>>I agree heartily with your final sentence.
>
>   By this you agree with a sentence with an expletive, but
>   whatever: This reminds my of one of my own style rules, that
>   I can apply to both topics discussed here: loops and the
>   main function:
>
>       >>When two wordings are equivalent, use the shorter one.<<
>
> [snip]

This advisory sounds suspiciously like "Other things being
equal, the shorter one is better."  The whole question is,
what other things are relevant, and under what conditions
are they equal.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Nick <3-nospam@temporary-address.org.uk> writes:
>
>> Thomas Pornin <pornin@bolet.org> writes:
> <snip>
>>> In C, the lack of a return statement in a non-void-returning method is
>>> allowed. What triggers "undefined behaviour" (aka "all of Hell is
>>> breaking loose") is reaching the closing '}' of a function _and_ trying
>>> to use the returned value (or, more appropriately, the value which
>>> should have been returned but was not).
> <snip>
>> I've often wondered - although I'd never write it - about something like
>> this:
>>
>> int process_items(struct thing *items, int mode) {
>>     if(mode == 0) {
>>       /* do some stuff */
>>       return;
>>     } else {
>>       int count = 0;
>>       /* do some other stuff, counting items */
>>       return count;
>>    }
>> }
>>
>> int main(void) {
>>     struct thing *stuff = create_items();
>>     /* set up items etc ... */
>>     process_items(stuff,1);
>>     printf("There are %d\n",process_items(stuff));
>
> There should be a second argument in this call, but that's not the point
> of your post.

Well spotted.
>
>>     return EXIT_SUCCESS;
>> }
>>
>> As I said, lots of reasons not to do it that way - including that this
>> toy is clearly a case for a single return and a function-wide count
>> variable that is always returned - but is it entirely OK?
>
> No, not in C99.  The presence of either a return with an expression in a
> void function; or the presence of one without in a non-void function are
> constraint violations in C99.
>
> If you remove the first return statement altogether (and thus simply
> allow execution to "fall off the end" of the function) then the program
> is OK (presuming that there are all the right declarations, of course).

Thanks for confirming it.  It's odd that an int function that ends with
"return;}" is a constraint violation but one that ends with a plain "}"
isn't, since for a void function they'd both be OK.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

Nick <3-nospam@temporary-address.org.uk> writes:
[...]
> Thanks for confirming it.  It's odd that an int function that ends with
> "return;}" is a constraint violation but one that ends with a plain "}"
> isn't, since for a void function they'd both be OK.

Yes, it's odd, but it's easier for a compiler to determine that a
return with no expression in a non-void function, or a return with
an expression in a void function, is an error, than to detect a
*missing* return statement.

For example:

    int spin(void) {
        while (1) {
            continue;
        }
    }

The missing return isn't really an error, since the closing brace can
never be reached.

Also;

    int foo(void) {
        if (condition) {
            return 42;
        }
    }

This isn't an error if "condition" is always true.

Reaching the closing "}" of a non-void function is really a run-time
error that can sometimes, but not always, be detected at compile
time.

The standard *could* have required that no execution path in a
non-void function may reach the closing "}", but that would require
more analysis than the standard generally requires compilers to
perform.  Compilers are of course free to warn about missing returns.

Something I never noticed before: as far as I can tell, this:

int func(void) {
    struct { double x; } result = { 0.0 };
    return result;
}

does not violate any constraints.  Its behavior is undefined, but
only by an omission of the definition of the behavior.  C99 6.8.6.4p3
says:

    If the expression has a type different from the return type of
    the function in which it appears, the value is converted as if by
    assignment to an object having the return type of the function.

An assignment won't convert from a struct type to int, so there's no
definition of the behavior.  Was this an oversight?

Followups redirected to comp.lang.c; this is probably beyond what's
topical for comp.lang.java.programmer.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Tue, 2 Nov 2010, Ben Bacarisse wrote:

> Tom Anderson <twic@urchin.earth.li> writes:
>
>> On Mon, 1 Nov 2010, Thomas Pornin wrote:
>>
>>> According to Tom Anderson  <twic@urchin.earth.li>:
>>>> But will it even compile, given the lack of a return statement in a
>>>> non-void-returning method?
>>>
>>> In C, the lack of a return statement in a non-void-returning method is
>>> allowed. What triggers "undefined behaviour" (aka "all of Hell is
>>> breaking loose") is reaching the closing '}' of a function _and_ trying
>>> to use the returned value (or, more appropriately, the value which
>>> should have been returned but was not). In a C implementation with a
>>> well-defined compilation phase (that's the normal state of affairs in
>>> C), the compilation MUST NOT fail on such a lack of a return statement
>>> in a non-void-returning function: problems implied by that lack of
>>> return may become apparent only at runtime.
>>
>> Thanks - and to Eric - for the explanation.
>>
>>> Of course, nothing of the above prevents a C compiler from emitting
>>> a warning about the lack of return.
>>
>> Nor, presumably, from doing something crafty to cause that usage to
>> blow up loudly at runtime.
>
> That depends on what you mean by "that usage"!
>
> Just to be 100% clear: the simple fact of omitting the return (in some
> path through the function) can not, of itself, cause anything to blow up
> at run-time.  Anything at all is permitted, however, if the caller
> attempts to use the value that was not returned (if you see what I
> mean).

Yes - sorry, that's what i was thinking of, and i didn't explain it 
clearly. You could do something in the calling convention so that the 
caller had to check a real value had been pushed onto the stack, perhaps. 
Or specialise the function into a version called in void contexts, and a 
version called in contexts where the return value is used, with the latter 
doing the checking. Or something cleverer.

tom

-- 
life finds a way

On Tue, 2 Nov 2010, Robert Klemme wrote:

> On 01.11.2010 22:30, BartC wrote:
>> "Tom Anderson" <twic@urchin.earth.li> wrote in message
>> news:alpine.DEB.1.10.1011012102020.4900@urchin.earth.li...
>> 
>>> Python has been called 'executable pseudocode'. If written cleanly, it is
>>> highly readable, even to those who don't know it.
>> 
>> I think Python is the last language I'd use for pseudocode. No-one
>> writing Python can resist using all it's features which renders it
>> incomprehensible to anyone else. And for porting code, it is also
>> necessary to duplicate it's myriad libraries.
>> 
>> Probably Lua is better for that role, being far simpler with less
>> built-in stuff.
>
> Of course I have to throw in Ruby here.  Very clean syntax, clean OO 
> implementation and no significant whitespace.  I often find that Ruby code 
> looks like pseudo code

Except that significant whitespace is usually a notable feature of 
pseudocode!

And of course the sigils. I believe this is ruby:

@count = 99

What purpose does the @ serve?

tom

-- 
life finds a way

On Nov 2, 11:18=A0am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Nov 2, 6:12=A0pm, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>
>
>
> > On Mon, 01 Nov 2010 23:40:24 -0400, Eric Sosman =A0
>
> > <esos...@ieee-dot-org.invalid> wrote:
> > > On 11/1/2010 9:40 PM, Stefan Ram wrote:
> > >> Eric Sosman<esos...@ieee-dot-org.invalid> =A0writes:
> > ...
> > >> =A0 =A0 =A0 =A0=BBWhen two wordings are equivalent, use the shorter =
one.=AB
>
> > > =A0 =A0 =A0ITYM "When two wordings are equivalent, use the shorter."
>
> > > =A0 =A0 =A0;-)
>
> > By induction, we could shorten this to
> > =A0 =A0 "When wordings are equivalent, use the shortest."
> > --
> > Morris Keesan -- mkee...@post.harvard.edu
>
> Use the shortest of equivalent wordings.

Abbreviate.

--
Things should be as simple as possible, and no simpler. -Einstein(?)

luser- -droog <mijoryx@yahoo.com> writes:
> On Nov 2, 11:18 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>> On Nov 2, 6:12 pm, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>> > On Mon, 01 Nov 2010 23:40:24 -0400, Eric Sosman  
>> > <esos...@ieee-dot-org.invalid> wrote:
>> > > On 11/1/2010 9:40 PM, Stefan Ram wrote:
>> > >> Eric Sosman<esos...@ieee-dot-org.invalid>  writes:
>> > ...
>> > >>        »When two wordings are equivalent, use the shorter one.«
>>
>> > >      ITYM "When two wordings are equivalent, use the shorter."
>>
>> > >      ;-)
>>
>> > By induction, we could shorten this to
>> >     "When wordings are equivalent, use the shortest."
>>
>> Use the shortest of equivalent wordings.
>
> Abbreviate.

Abbr.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Nov 3, 6:45=A0am, Keith Thompson <ks...@mib.org> wrote:
> luser- -droog <mijo...@yahoo.com> writes:
> > On Nov 2, 11:18=A0am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > wrote:
> >> On Nov 2, 6:12=A0pm, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
> >> > On Mon, 01 Nov 2010 23:40:24 -0400, Eric Sosman =A0
> >> > <esos...@ieee-dot-org.invalid> wrote:
> >> > > On 11/1/2010 9:40 PM, Stefan Ram wrote:
> >> > >> Eric Sosman<esos...@ieee-dot-org.invalid> =A0writes:
> >> > ...
> >> > >> =A0 =A0 =A0 =A0=BBWhen two wordings are equivalent, use the short=
er one.=AB
>
> >> > > =A0 =A0 =A0ITYM "When two wordings are equivalent, use the shorter=
.."
>
> >> > > =A0 =A0 =A0;-)
>
> >> > By induction, we could shorten this to
> >> > =A0 =A0 "When wordings are equivalent, use the shortest."
>
> >> Use the shortest of equivalent wordings.
>
> > Abbreviate.
>
> Abbr.
>
zip (to get us back to programming).

On Nov 3, 11:41=A0am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Nov 3, 6:45=A0am, Keith Thompson <ks...@mib.org> wrote:
>
>
>
>
>
> > luser- -droog <mijo...@yahoo.com> writes:
> > > On Nov 2, 11:18=A0am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > > wrote:
> > >> On Nov 2, 6:12=A0pm, "Morris Keesan" <mkee...@post.harvard.edu> wrot=
e:
> > >> > On Mon, 01 Nov 2010 23:40:24 -0400, Eric Sosman =A0
> > >> > <esos...@ieee-dot-org.invalid> wrote:
> > >> > > On 11/1/2010 9:40 PM, Stefan Ram wrote:
> > >> > >> Eric Sosman<esos...@ieee-dot-org.invalid> =A0writes:
> > >> > ...
> > >> > >> =A0 =A0 =A0 =A0=BBWhen two wordings are equivalent, use the sho=
rter one.=AB
>
> > >> > > =A0 =A0 =A0ITYM "When two wordings are equivalent, use the short=
er."
>
> > >> > > =A0 =A0 =A0;-)
>
> > >> > By induction, we could shorten this to
> > >> > =A0 =A0 "When wordings are equivalent, use the shortest."
>
> > >> Use the shortest of equivalent wordings.
>
> > > Abbreviate.
>
> > Abbr.
>
> zip (to get us back to programming).

Language golfing at its finest.

On Nov 2, 10:13=A0pm, Keith Thompson <ks...@mib.org> wrote:
> Nick <3-nos...@temporary-address.org.uk> writes:
>
> [...]
>
> > Thanks for confirming it. =A0It's odd that an int function that ends wi=
th
> > "return;}" is a constraint violation but one that ends with a plain "}"
> > isn't, since for a void function they'd both be OK.
>
> Yes, it's odd, but it's easier for a compiler to determine that a
> return with no expression in a non-void function, or a return with
> an expression in a void function, is an error, than to detect a
> *missing* return statement.
>
> For example:
>
> =A0 =A0 int spin(void) {
> =A0 =A0 =A0 =A0 while (1) {
> =A0 =A0 =A0 =A0 =A0 =A0 continue;
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> The missing return isn't really an error, since the closing brace can
> never be reached.
>
> Also;
>
> =A0 =A0 int foo(void) {
> =A0 =A0 =A0 =A0 if (condition) {
> =A0 =A0 =A0 =A0 =A0 =A0 return 42;
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> This isn't an error if "condition" is always true.
>
> Reaching the closing "}" of a non-void function is really a run-time
> error that can sometimes, but not always, be detected at compile
> time.
>
> The standard *could* have required that no execution path in a
> non-void function may reach the closing "}", but that would require
> more analysis than the standard generally requires compilers to
> perform. =A0Compilers are of course free to warn about missing returns.
>
> Something I never noticed before: as far as I can tell, this:
>
> int func(void) {
> =A0 =A0 struct { double x; } result =3D { 0.0 };
> =A0 =A0 return result;
> }

Your last function won't compile with gcc. The relevant message:
"error: incompatible types when returning type struct <anonymous> but
int was expected".

I don't have a copy of the standard handy, so I guess that either the
standard defines its behaviour somewhere we have no recollection of,
or gcc is performing type inference by including some assignment to a
temporary variable in the intermediate representation.

Still, as far as undefined behaviour goes, it's an error I don't mind
seeing.

On Oct 21, 1:34=A0pm, markspace <nos...@nowhere.com> wrote:
> I'm doing some text parsing and I'd appreciate some input on code styles
> for loops.
> [snip]

If you care about internationalization and code points outside the
Basic Multilingual Plane:

int i =3D 0;
final int length =3D s.length();
while (i < length) {
    final int codepoint =3D s.codePointAt(i);
    if (!Character.isLetter(codepoint)) {
        break;
    }
    i +=3D Character.charCount(codepoint);
}
if (i >=3D length) {
    // ALL CHARACTERS WERE LETTERS, OR EMPTY STRING
}

If you are really paranoid, you could also check for valid surrogate
pairs, or pre-screen the string for them.

On 02.11.2010 23:15, Tom Anderson wrote:
> On Tue, 2 Nov 2010, Robert Klemme wrote:
>
>> On 01.11.2010 22:30, BartC wrote:
>>> "Tom Anderson" <twic@urchin.earth.li> wrote in message
>>> news:alpine.DEB.1.10.1011012102020.4900@urchin.earth.li...
>>>
>>>> Python has been called 'executable pseudocode'. If written cleanly,
>>>> it is
>>>> highly readable, even to those who don't know it.
>>>
>>> I think Python is the last language I'd use for pseudocode. No-one
>>> writing Python can resist using all it's features which renders it
>>> incomprehensible to anyone else. And for porting code, it is also
>>> necessary to duplicate it's myriad libraries.
>>>
>>> Probably Lua is better for that role, being far simpler with less
>>> built-in stuff.
>>
>> Of course I have to throw in Ruby here. Very clean syntax, clean OO
>> implementation and no significant whitespace. I often find that Ruby
>> code looks like pseudo code
>
> Except that significant whitespace is usually a notable feature of
> pseudocode!

Is it?  Hm...  Never thought of it that way.

> And of course the sigils. I believe this is ruby:
>
> @count = 99
>
> What purpose does the @ serve?

It denotes an instance variable of the object the code is executed 
within (i.e. which "self" points to).  "count" in contrast is a local 
variable (or a method call) or a method parameter.  Constants are 
identified by a leading uppercase letter.

There's an online version of the first edition of "Programming Ruby":
http://www.ruby-doc.org/docs/ProgrammingRuby/

Beware there are some subtle changes between version 1.8 described in 
the document and the current 1.9.  But most descriptions are still valid.

If you are looking for more introductory material there's also plenty 
around.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

On 11/3/2010 2:41 AM, Malcolm McLean wrote:

>>>> Use the shortest of equivalent wordings.
>>
>>> Abbreviate.
>>
>> Abbr.
>>
> zip (to get us back to programming).

kthxbye

On Oct 31, 6:23=A0pm, Keith Thompson <ks...@mib.org> wrote:
> Ian Collins <ian-n...@hotmail.com> writes:
> > On 11/ 1/10 08:17 AM, Stefan Ram wrote:
> >> Ian Collins<ian-n...@hotmail.com> =A0writes:
> >>>> The point of having no {} is that you realise that all the *serious*
> >>>> stuff is going on inside the while loop statement itself.
> >>> It's a great way to confuse readers!
>
> >> =A0 =A0Indeed, most people will be confused by this, since most
> >> =A0 =A0people do not know the C programming language at all.
> >> =A0 =A0However, a C programmer will not be confused by this (by
> >> =A0 =A0definition).
>
> > Restoring the context:
>
> > James Dow Allen <gm...@jamesdowallen.nospam> writes:
>
> > =A0> I prefer
> > =A0> =A0 =A0 while (*p++ =3D *q++) {
> > =A0> =A0 =A0 }
>
> > The confusion stems not from the syntax, but from the empty braces, did
> > he intend there to be some code in there?
>
> One possible alternative is:
>
> =A0 =A0 while (*p++ =3D *q++) {
> =A0 =A0 =A0 =A0 /* nothing */
> =A0 =A0 }
>
> Another is:
>
> =A0 =A0 while (*p++ =3D *q++) {
> =A0 =A0 =A0 =A0 continue;
> =A0 =A0 }

I know you weren't specifically suggesting these per se, but I might
argue that both of those are a form of over-engineering that I don't
think there's a term for.  Over verbosity?  While they certainly seem
safer overall, it somehow seems just a little more than is necessary
for even the exhausted engineer at 3am hopped on caffeine <--
(tiredness & caffeine-addled are my standard metrics for defensive
coding).

"Thomas G. Marshall" <tgmforum@gmail.com> writes:
> On Oct 31, 6:23 pm, Keith Thompson <ks...@mib.org> wrote:
>> Ian Collins <ian-n...@hotmail.com> writes:
>> > On 11/ 1/10 08:17 AM, Stefan Ram wrote:
>> >> Ian Collins<ian-n...@hotmail.com>  writes:
>> >>>> The point of having no {} is that you realise that all the *serious*
>> >>>> stuff is going on inside the while loop statement itself.
>> >>> It's a great way to confuse readers!
>>
>> >>    Indeed, most people will be confused by this, since most
>> >>    people do not know the C programming language at all.
>> >>    However, a C programmer will not be confused by this (by
>> >>    definition).
>>
>> > Restoring the context:
>>
>> > James Dow Allen <gm...@jamesdowallen.nospam> writes:
>>
>> >  > I prefer
>> >  >     while (*p++ = *q++) {
>> >  >     }
>>
>> > The confusion stems not from the syntax, but from the empty braces, did
>> > he intend there to be some code in there?
>>
>> One possible alternative is:
>>
>>     while (*p++ = *q++) {
>>         /* nothing */
>>     }
>>
>> Another is:
>>
>>     while (*p++ = *q++) {
>>         continue;
>>     }
>
> I know you weren't specifically suggesting these per se, but I might
> argue that both of those are a form of over-engineering that I don't
> think there's a term for.  Over verbosity?  While they certainly seem
> safer overall, it somehow seems just a little more than is necessary
> for even the exhausted engineer at 3am hopped on caffeine <--
> (tiredness & caffeine-addled are my standard metrics for defensive
> coding).

I wasn't specifically suggesting them, but now I will: I specifically
suggest them.  I don't find either form overly verbose.

In this particular case, I'd say that a loop with an empty body is
sufficiently unusual that there should be *some* explicit way of
indicating it; otherwise it's easily mistaken for a typo.

For example, suppose you see this:

    while (*p++ = *q++);
        do_something;

Clearly the code is either incorrect or poorly formatted -- but which?
Maybe the author's tab stop settings just don't match yours.

YMMV, and apparently it does.  I'm aware that my personal taste in
C coding style is more verbose than the average.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Nov 5, 7:58=A0pm, Keith Thompson <ks...@mib.org> wrote:
> "Thomas G. Marshall" <tgmfo...@gmail.com> writes:
>
>
>
> > On Oct 31, 6:23=A0pm, Keith Thompson <ks...@mib.org> wrote:
> >> Ian Collins <ian-n...@hotmail.com> writes:
> >> > On 11/ 1/10 08:17 AM, Stefan Ram wrote:
> >> >> Ian Collins<ian-n...@hotmail.com> =A0writes:
> >> >>>> The point of having no {} is that you realise that all the *serio=
us*
> >> >>>> stuff is going on inside the while loop statement itself.
> >> >>> It's a great way to confuse readers!
>
> >> >> =A0 =A0Indeed, most people will be confused by this, since most
> >> >> =A0 =A0people do not know the C programming language at all.
> >> >> =A0 =A0However, a C programmer will not be confused by this (by
> >> >> =A0 =A0definition).
>
> >> > Restoring the context:
>
> >> > James Dow Allen <gm...@jamesdowallen.nospam> writes:
>
> >> > =A0> I prefer
> >> > =A0> =A0 =A0 while (*p++ =3D *q++) {
> >> > =A0> =A0 =A0 }
>
> >> > The confusion stems not from the syntax, but from the empty braces, =
did
> >> > he intend there to be some code in there?
>
> >> One possible alternative is:
>
> >> =A0 =A0 while (*p++ =3D *q++) {
> >> =A0 =A0 =A0 =A0 /* nothing */
> >> =A0 =A0 }
>
> >> Another is:
>
> >> =A0 =A0 while (*p++ =3D *q++) {
> >> =A0 =A0 =A0 =A0 continue;
> >> =A0 =A0 }
>
> > I know you weren't specifically suggesting these per se, but I might
> > argue that both of those are a form of over-engineering that I don't
> > think there's a term for. =A0Over verbosity? =A0While they certainly se=
em
> > safer overall, it somehow seems just a little more than is necessary
> > for even the exhausted engineer at 3am hopped on caffeine <--
> > (tiredness & caffeine-addled are my standard metrics for defensive
> > coding).
>
> I wasn't specifically suggesting them, but now I will: I specifically
> suggest them. =A0I don't find either form overly verbose.
>
> In this particular case, I'd say that a loop with an empty body is
> sufficiently unusual that there should be *some* explicit way of
> indicating it; otherwise it's easily mistaken for a typo.
>
> For example, suppose you see this:
>
> =A0 =A0 while (*p++ =3D *q++);
> =A0 =A0 =A0 =A0 do_something;

[...snip...]

Well that gets to the heart of what I was talking about.  The
"suppose".  I don't really go much out of my way any longer to solve
problems I don't think I've ever seen.  Maybe overly verbose is less
what I was getting at and more something similar to "not worth my
thought".

Maybe another example of what I consider over protection that I
occasionally see trumpeted are using things like the following:

    if (0 =3D=3D something) ....

to prevent the accidental

    if (something =3D 0) ....

compiler accepted typo.  I suppose I am not doing this for an
aditional reason in that it perhaps goofs up the way we sound out
things we read, but even if it didn't---I wouldn't worry about it.  In
fact, it seems more worth it to me to spend time telling others to not
spend time worrying about it.  LOL.

Keith Thompson <kst-u@mib.org> writes:
>I'd say that a loop with an empty body is sufficiently
>unusual that there should be *some* explicit way of
>indicating it; otherwise it's easily mistaken for a typo.

  I just spotted a typo above! You wrote �it;�, surely you
  wanted to write �it,�. (Ok, you could have intentionally
  written �it;� in theory, that would not be actually wrong
  but very unusual [�The semicolon has been gradually
  disappearing, not only from newspapers, but from books� -
  slate] and should have *some* explicit way of indicating it
  added.)

  Ok, if you would be a great literature writer, then you
  might use such semicolons without further indications, just
  as for example the renowned programmer Donald E. Knuth used
  semicolons as loop bodies in a program he wrote two months
  ago without further indication:

      �for (p=buf;*p==' ';p++);
      (...)
      for (p=buf+1;*p==' ';p++);
      for (q=p+1;*q!='\n';q++);
      (...)
      for (k=0,cyc[cycptr]=w;w.x!=cyc[k].x || w.y!=cyc[k].y;k++);�

http://www-cs-faculty.stanford.edu/~uno/programs/dragon-calc.w

  Ok, this is a short program, and he used this �);� four
  times therein, but otherwise this is VERY RARE. We normal
  mortal programmers should NEVER take code written by very
  good programmers as a model for our own code. It would
  be much too smart, no one would understand it anymore,
  our coworkers would would think we were arrogant, and, 
  worst of all, our managers would not be able to read it!

  But can we be absolutely certain that Donald E. Knuth did
  not make a typo above? Why don't you write a letter to him,
  explaining that his loop already ends with this semicolon
  (possibly, he will be surprised to learn this!), and suggest
  that he double-checks whether this was really intended and
  then add some explicit indication to it?

>For example, suppose you see this:
>    while (*p++ = *q++);
>        do_something;

  Yes, but here to clue that hints us of the possibility of an
  error is the indentation, not the semicolon. It would be the
  same problem with braces:

    while (*p++ = *q++){}
        do_something;

  Or,

    while (*p++ = *q++){ /* intentionally empty */ }
        do_something;

ram@zedat.fu-berlin.de (Stefan Ram) quotes:
>for (p=buf+1;*p==' ';p++);
>for (q=p+1;*q!='\n';q++);

  These two loops were written by Knuth in sequence as quoted.
  He seems to want to skip spaces, and then newline characters.
  This reminds me of code I quoted before:

|while( isspace( *++c )); while( isnum( *++c ));

  which was then dismissed by Eric as

|wrong, unless the "certain circumstances" happen to include
|foreknowledge that the string is exactly of the given form,

  Well, Donald E. Knuth is known to always be grateful for
  reports of possible errors in his code.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>I'd say that a loop with an empty body is sufficiently
>>unusual that there should be *some* explicit way of
>>indicating it; otherwise it's easily mistaken for a typo.
>
>   I just spotted a typo above! You wrote »it;«, surely you
>   wanted to write »it,«. (Ok, you could have intentionally
[SNIP]

If you'd care to make the point without being quite so sarcastic,
I'd be glad to discuss it with you.  And argument from authority
doesn't particularly impress me.  Certainly Knuth is a better
programmer and computer scientist than I am; that doesn't mean I
don't, or shouldn't, prefer my own coding style to his.

>>For example, suppose you see this:
>>    while (*p++ = *q++);
>>        do_something;
>
>   Yes, but here to clue that hints us of the possibility of an
>   error is the indentation, not the semicolon. It would be the
>   same problem with braces:
>
>     while (*p++ = *q++){}
>         do_something;
>
>   Or,
>
>     while (*p++ = *q++){ /* intentionally empty */ }
>         do_something;

No, it wouldn't.  The problem with the original version:

    while (*p++ = *q++);
        do_something;

is that it's hard to be sure whether the author messed up the
indentation on the second line:

    while (*p++ = *q++);
    do_something;

or added an unintended semicolon:

    while (*p++ = *q++)
        do_something;

Braces would make it obvious which was intended.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Nov 5, 9:20=A0pm, Keith Thompson <ks...@mib.org> wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> > Keith Thompson <ks...@mib.org> writes:
> >>I'd say that a loop with an empty body is sufficiently
> >>unusual that there should be *some* explicit way of
> >>indicating it; otherwise it's easily mistaken for a typo.
>
> > =A0 I just spotted a typo above! You wrote =BBit;=AB, surely you
> > =A0 wanted to write =BBit,=AB. (Ok, you could have intentionally
>
> [SNIP]
>
> If you'd care to make the point without being quite so sarcastic,
> I'd be glad to discuss it with you. =A0And argument from authority
> doesn't particularly impress me.

....nor I (regarding Knuth), though his intent with the ";" thing may
have just been humor.  In any case, the more I reflect on this I dig
up vague recollections of

    while (..........) {}

as well as the s/{}$/;  :)

On Fri, 05 Nov 2010 18:20:40 -0700, Keith Thompson
<kst-u@mib.org> wrote:


>
>No, it wouldn't.  The problem with the original version:
>
>    while (*p++ = *q++);
>        do_something;
>
>is that it's hard to be sure whether the author messed up the
>indentation on the second line:
>
>    while (*p++ = *q++);
>    do_something;
>
>or added an unintended semicolon:
>
>    while (*p++ = *q++)
>        do_something;
>
>Braces would make it obvious which was intended.

Have you ever actually seen a case where the semicolon was
actuallly unintended?  I haven't but I suppose someone must have
sometime, somewhere.  On the other hand I've seen lots of messed
up indentation.

Personally I think all of these little gimmicks to indicate an
empty body have less than no value; they are just noise.  YMMV.
Oh yes, semicolons are quite alright.  We agree on that.

Keith Thompson <kst-u@mib.org> writes:

> No, it wouldn't.  The problem with the original version:
>
>     while (*p++ = *q++);
>         do_something;
>
> is that it's hard to be sure whether the author messed up the
> indentation on the second line:
>
>     while (*p++ = *q++);
>     do_something;
>
> or added an unintended semicolon:
>
>     while (*p++ = *q++)
>         do_something;
>
> Braces would make it obvious which was intended.

I agree entirely with this, but have always found putting the semicolon
on a line by itself - something that you never see in any other
circumstances (he says recklessly) - plenty of indication that there is
an empty loop body and that it's intentional.  If you always use braces
for every loop and if body - and many do - then braces would be more
consistent.  I tend not to (and know it means that I have to add them
sometimes, and that sometimes I leave them in when I reduce bodies to
one line, when to be utterly consistent I ought to remove them) and so
use the singleton semicolon.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

On Oct 31, 8:48=A0pm, superpollo <superpo...@tznvy.pbz> wrote:
> Ian Collins ha scritto:
>
>
>
>
>
> > On 11/ 1/10 08:17 AM, Stefan Ram wrote:
> >> Ian Collins<ian-n...@hotmail.com> =A0writes:
> >>>> The point of having no {} is that you realise that all the *serious*
> >>>> stuff is going on inside the while loop statement itself.
> >>> It's a great way to confuse readers!
>
> >> =A0 =A0Indeed, most people will be confused by this, since most
> >> =A0 =A0people do not know the C programming language at all.
> >> =A0 =A0However, a C programmer will not be confused by this (by
> >> =A0 =A0definition).
>
> > Restoring the context:
>
> > James Dow Allen <gm...@jamesdowallen.nospam> writes:
>
> > =A0> I prefer
> > =A0> =A0 =A0 while (*p++ =3D *q++) {
> > =A0> =A0 =A0 }
>
> > The confusion stems not from the syntax, but from the empty braces, did
> > he intend there to be some code in there?
>
> and what if sometime in the future you need to meat up a bit the body of
> the loop?

then you add the curly brackets. This is a variant of the YAGNI
principle.

I use this layout standard and it doesn't cause me grief.

how about
     while (*p++ =3D *q++)
          continue;

On Nov 2, 5:42=A0pm, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 01.11.2010 22:30, BartC wrote:
>
> > "Tom Anderson" <t...@urchin.earth.li> wrote in message
> >news:alpine.DEB.1.10.1011012102020.4900@urchin.earth.li...
>
> >> Python has been called 'executable pseudocode'. If written cleanly, it=
 is
> >> highly readable, even to those who don't know it.
>
> > I think Python is the last language I'd use for pseudocode. No-one
> > writing Python can resist using all it's features which renders it
> > incomprehensible to anyone else. And for porting code, it is also
> > necessary to duplicate it's myriad libraries.
>
> > Probably Lua is better for that role, being far simpler with less
> > built-in stuff.
>
> Of course I have to throw in Ruby here. =A0Very clean syntax, clean OO
> implementation and no significant whitespace. =A0I often find that Ruby
> code looks like pseudo code - but it actually can be executed. =A0:-)

when faced with the choice of learning python or ruby I chose python.
ruby looked a bit strange. Having skimmed the tutorial you mention it
looks a lot less strange! But if you write pseudo code like this then
heaven help your collegues!


ARGF.each { |line|  print line  if line =3D~ /Ruby/ }

On 11/ 6/10 10:20 PM, Nick Keighley wrote:
> On Oct 31, 8:48 pm, superpollo<superpo...@tznvy.pbz>  wrote:
>> Ian Collins ha scritto:
>>
>>
>>
>>
>>
>>> On 11/ 1/10 08:17 AM, Stefan Ram wrote:
>>>> Ian Collins<ian-n...@hotmail.com>    writes:
>>>>>> The point of having no {} is that you realise that all the *serious*
>>>>>> stuff is going on inside the while loop statement itself.
>>>>> It's a great way to confuse readers!
>>
>>>>     Indeed, most people will be confused by this, since most
>>>>     people do not know the C programming language at all.
>>>>     However, a C programmer will not be confused by this (by
>>>>     definition).
>>
>>> Restoring the context:
>>
>>> James Dow Allen<gm...@jamesdowallen.nospam>  writes:
>>
>>>   >  I prefer
>>>   >       while (*p++ = *q++) {
>>>   >       }
>>
>>> The confusion stems not from the syntax, but from the empty braces, did
>>> he intend there to be some code in there?
>>
>> and what if sometime in the future you need to meat up a bit the body of
>> the loop?
>
> then you add the curly brackets. This is a variant of the YAGNI
> principle.
>
> I use this layout standard and it doesn't cause me grief.
>
> how about
>       while (*p++ = *q++)
>            continue;

But would still make people used to the idiomatic case wonder why the 
continue?

-- 
Ian Collins

On Nov 6, 9:35=A0am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 11/ 6/10 10:20 PM, Nick Keighley wrote:
> > On Oct 31, 8:48 pm, superpollo<superpo...@tznvy.pbz> =A0wrote:
> >> Ian Collins ha scritto:
> >>> On 11/ 1/10 08:17 AM, Stefan Ram wrote:
> >>>> Ian Collins<ian-n...@hotmail.com> =A0 =A0writes:


> >>>>>> The point of having no {} is that you realise that all the *seriou=
s*
> >>>>>> stuff is going on inside the while loop statement itself.
> >>>>> It's a great way to confuse readers!
>
> >>>> =A0 =A0 Indeed, most people will be confused by this, since most
> >>>> =A0 =A0 people do not know the C programming language at all.
> >>>> =A0 =A0 However, a C programmer will not be confused by this (by
> >>>> =A0 =A0 definition).
>
> >>> Restoring the context:
>
> >>> James Dow Allen<gm...@jamesdowallen.nospam> =A0writes:
>
> >>> =A0 > =A0I prefer
> >>> =A0 > =A0 =A0 =A0 while (*p++ =3D *q++) {
> >>> =A0 > =A0 =A0 =A0 }
>
> >>> The confusion stems not from the syntax, but from the empty braces, d=
id
> >>> he intend there to be some code in there?
>
> >> and what if sometime in the future you need to meat up a bit the body =
of
> >> the loop?
>
> > then you add the curly brackets. This is a variant of the YAGNI
> > principle.
>
> > I use this layout standard and it doesn't cause me grief.
>
> > how about
> > =A0 =A0 =A0 while (*p++ =3D *q++)
> > =A0 =A0 =A0 =A0 =A0 =A0continue;
>
> But would still make people used to the idiomatic case wonder why the
> continue?

well I don't find the usual idiom clear enough

    while (*p++ =3D *q++);

I want a minimum of two lines. I usually use

    while (*p++ =3D *q++)
        ;

though in reality I hardly ever do a simple copy like this- I use
strcpy()

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> well I don't find the usual idiom clear enough

I'm not sure that is the usual idiom, actually.

>
>     while (*p++ = *q++);
>
> I want a minimum of two lines. I usually use
>
>     while (*p++ = *q++)
>         ;

I do too. 

> though in reality I hardly ever do a simple copy like this- I use
> strcpy()

No, but there are reasons to do it:

/var/www/canal$ grep -B1 '^ *; *$' source/*.c
source/bigops.c-  while(*tag && *tag==' ')   // skip leading spaces
source/bigops.c:    ;
--
source/localconfig.c-    while(waitpid(pid,&st,0) > 0)
source/localconfig.c:      ;
--
source/output.c-  for(p=parm,parcount = 0;p;parcount++,p=p->next)
source/output.c:    ;
--
source/syntax.c-    for(p->argcount = 0,pc=args; pc; p->argcount++,pc=pc->next)
source/syntax.c:      ;

That last is actually pretty offensive now I look at it.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

Ian Collins wrote:
> 
> On 11/ 1/10 08:17 AM, Stefan Ram wrote:
> > Ian Collins<ian-news@hotmail.com>  writes:
> >>> The point of having no {}
> >>> is that you realise that all the *serious*
> >>> stuff is going on inside the while loop statement itself.
> >> It's a great way to confuse readers!
> >
> >    Indeed, most people will be confused by this, since most
> >    people do not know the C programming language at all.
> >    However, a C programmer will not be confused by this (by
> >    definition).
> 
> Restoring the context:
> 
> James Dow Allen <gmail@jamesdowallen.nospam> writes:
> 
>  >
>  > I prefer
>  >     while (*p++ = *q++) {
>  >     }
>  >
> 
> The confusion stems not from the syntax,
> but from the empty braces, did
> he intend there to be some code in there?


 I prefer
     while (*p++ = *q++) {
         ;
     }

-- 
pete

pete wrote:
>   I prefer
>       while (*p++ = *q++) {
>           ;
>       }

That's humor, right?

If so, then you haven't gone far enough:

   while ( *p++ = *q++ )
   {
    {
     {
      ;
     };
    };
   };

-- 
Lew

Robert Klemme wrote:
>> Of course I have to throw in Ruby here.  Very clean syntax, clean OO
>> implementation and no significant whitespace.  I often find that Ruby
>> code looks like pseudo code - but it actually can be executed.  :-)

I find that it looks like pseudo-programming.  Sure, it can be executed, but 
it's the writer who should be.

Nick Keighley wrote:
> when faced with the choice of learning python or ruby I chose python.
> ruby looked a bit strange. Having skimmed the tutorial you mention it
> looks a lot less strange! But if you write pseudo code like this then
> heaven help your collegues!
>
> ARGF.each { |line|  print line  if line =~ /Ruby/ }

Let's just bring back APL, why don't we?

-- 
Lew

On Nov 6, 10:25=A0am, c...@tiac.net (Richard Harter) wrote:
> Have you ever actually seen a case where the semicolon was
> actuallly unintended?

I've seen 2 or 3 instances in FSF's gnu libc of the formula

#define  FOO(xxx) \
    do { floogy(xxx); } while (0);

where the trailing ";" was obviously a typo.  (It defeats
the whole purpose of this special do while (0) macro idea.)
I assume the coder "knew what he was doing", but added
the ";' almost by reflex, and never noticed thereafter!

(The "bug" may not have ill effect since the whole idea of the
macro is to allow embedding FOO(xxx) in, e.g. an if/else
or some such, and the code, we might infer, never did that.)

James

On Nov 1, 5:02=A0pm, Tom Anderson <t...@urchin.earth.li> wrote:

....[snip]...

> Python has been called 'executable pseudocode'. If written cleanly, it is
> highly readable, even to those who don't know it.

Seems to me I heard this of COBOL once.  ;)


>
> If written badly, of course, it's as bad as the cleanest bits of perl.

I have argued against perl endlessly because of this.  It seems to be
something that its designer was so very proud of, at least in the
beginning.  $| is gross.

"Thomas G. Marshall" <tgmforum@gmail.com> writes:
>I have argued against perl endlessly because of this.  It seems to be
>something that its designer was so very proud of, at least in the
>beginning.  $| is gross.

  This is a somewhat �chauvinistic� or �egocentric� point of
  view, by which Russian or Chinese should be �gross�, too,
  because it does not use �readable� latin letters but
  �unreadable� Cyrillic or Chinese symbols. However, it misses
  that for someone who has grown up in a culture with Cyrillic
  letters the inverse holds.

  We cannot judge the readability of a language from the
  outside, from the point of view of someone who does not know
  the language well, but should judge it from the inside.

  Moreover, the readability of �$|� is a very low-level
  problem. Of course, low-level details, bits and pieces
  matter a lot in programming, but we have:

      - projects running over-budget,
      - projects running over-time,
      - software often does not meet requirements, and
      - software is never delivered. 

    (After: http://en.wikipedia.org/wiki/Software_crisis )

  I believe that the cause of these major problems are
  predominantly errors in management, overall problem
  definition, analysis, and large-scale design of the
  development process and the code itself, not problems with
  small-scale questions of wordings in source code.

On Nov 6, 9:21=A0am, pete <pfil...@mindspring.com> wrote:
> Ian Collins wrote:
>
> > On 11/ 1/10 08:17 AM, Stefan Ram wrote:
> > > Ian Collins<ian-n...@hotmail.com> =A0writes:
> > >>> The point of having no {}
> > >>> is that you realise that all the *serious*
> > >>> stuff is going on inside the while loop statement itself.
> > >> It's a great way to confuse readers!
>
> > > =A0 =A0Indeed, most people will be confused by this, since most
> > > =A0 =A0people do not know the C programming language at all.
> > > =A0 =A0However, a C programmer will not be confused by this (by
> > > =A0 =A0definition).
>
> > Restoring the context:
>
> > James Dow Allen <gm...@jamesdowallen.nospam> writes:
>
> > =A0> I prefer
> > =A0> =A0 =A0 while (*p++ =3D *q++) {
> > =A0> =A0 =A0 }
>
> > The confusion stems not from the syntax,
> > but from the empty braces, did
> > he intend there to be some code in there?
>
> =A0I prefer
> =A0 =A0 =A0while (*p++ =3D *q++) {
> =A0 =A0 =A0 =A0 =A0;
> =A0 =A0 =A0}
>
> --
> pete

I've also seen a riff on Griess's "skip" command:

while ( ... )
  /* skip */ ;

Gene <gene.ressler@gmail.com> writes:
>I've also seen a riff on Griess's "skip" command:
>while ( ... )
>  /* skip */ ;

  Well, �the problem� might be related to languages which
  use the end of the expression statement

      <expression> ";"

  as the empty statement

      ";".

  We can imagine a language where the expression statement
  is written as

      <expression> ";",

  while the empty statement is written as

      "�";

  then we would have:

      while( *p++ = *q++ )�

  .

"Nick" <3-nospam@temporary-address.org.uk> wrote in message 
news:87k4kqk4ad.fsf@temporary-address.org.uk...
> /var/www/canal$ grep -B1 '^ *; *$' source/*.c
> source/bigops.c-  while(*tag && *tag==' ')   // skip leading spaces
> source/bigops.c:    ;

That might run for a long time. 

On 11/6/10 7:26 PM, Mike Schilling wrote:
>
>
> "Nick" <3-nospam@temporary-address.org.uk> wrote in message
> news:87k4kqk4ad.fsf@temporary-address.org.uk...
>> /var/www/canal$ grep -B1 '^ *; *$' source/*.c
>> source/bigops.c- while(*tag && *tag==' ') // skip leading spaces
>> source/bigops.c: ;
>
> That might run for a long time.

Nah.  He just didn't post the line that came before:

   if (*tag != '\0') return;

Of course, even so, one wonders why the condition bothers with "*tag 
&&".  Surely the more restrictive "*tag==' '" would be sufficient.

Why such silly code is relevant in a discussion about the _right_ way to 
do things, I have no idea.

Pete

On Nov 6, 9:00=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> "Thomas G. Marshall" <tgmfo...@gmail.com> writes:
>
> >I have argued against perl endlessly because of this. =A0It seems to be
> >something that its designer was so very proud of, at least in the
> >beginning. =A0$| is gross.

> This is a somewhat =BBchauvinistic=AB or =BBegocentric=AB
> point of view, by which Russian or Chinese should be
> =BBgross=AB, too, because it does not use =BBreadable=AB > latin
> letters but =BBunreadable=AB Cyrillic or Chinese symbols.
> However, it misses that for someone who has grown up
> in a culture with Cyrillic letters the inverse holds.

No, because most English speakers I know regard English as an inferior
language to other more structured, less idiomatic languages with fewer
irregulars.

> We cannot judge the readability of a language from the
> outside, from the point of view of someone who does not know
> the language well, but should judge it from the inside.

Broken logic.  You can likely become a proficient coder in anything
horrid given enough time---in fact there's a programming language
designed to be specifically difficult, it's name escapes me.  You
might even become a very comfortable insider at using a screwdriver to
pound in a nail.  That does not keep you from saying it's relatively a
terrible idea (an inside judgment), nor does it preclude a fair
outside judgment.  It does not preclude someone from having tried it
as judging it as a bad idea.  If such a thing as coding clearly
exists, then it's antithesis must also, and of all the degrees in
between.  And some languages support this better than others---
regardless of how used to it you can be.

Stefan Ram wrote:
>    We can imagine a language where the expression statement
>    is written as
>
>        <expression>  ";",
>
>    while the empty statement is written as
>
>        "Ø";
>
>    then we would have:
>
>        while( *p++ = *q++ )Ø

To save trouble figuring out how to type "Ø" on, say, U.S. keyboards, let's 
define a digraph "{}" to represent that construct:

   while( *p++ = *q++ ){}

-- 
Lew

On Sat, 06 Nov 2010 20:42:11 -0700, Thomas G. Marshall wrote:

> Broken logic.  You can likely become a proficient coder in anything
> horrid given enough time---in fact there's a programming language
> designed to be specifically difficult, it's name escapes me.

Perl?

:)

Intercal most likely.

> You might even become a very comfortable insider at using a screwdriver
> to pound in a nail.  That does not keep you from saying it's relatively
> a terrible idea (an inside judgment), nor does it preclude a fair
> outside judgment.  It does not preclude someone from having tried it as
> judging it as a bad idea.  If such a thing as coding clearly exists,
> then it's antithesis must also, and of all the degrees in between.  And
> some languages support this

Lisp, Java

> better than others

C++, Ruby, Perl

> --- regardless of how used to it you can be.

I don't know if anyone can ever get used to Perl. Or any large C++ 
codebase that has had substantial operator overloading abuse done to it.

"ClassCastException" <zjkg3d9gj56@gmail.invalid> wrote in message 
news:ib57sr$uq4$1@news.eternal-september.org...
> I don't know if anyone can ever get used to Perl.

Ask someone who's used it extensively.  The answer will be "Of course."

 

"Mike Schilling" <mscottschilling@hotmail.com> writes:
>"ClassCastException" <zjkg3d9gj56@gmail.invalid> wrote in message 
>news:ib57sr$uq4$1@news.eternal-september.org...
>> I don't know if anyone can ever get used to Perl.
>Ask someone who's used it extensively.  The answer will be "Of course."

  (Just in case someone STILL does not have seen this yet:)

http://imgs.xkcd.com/comics/lisp.jpg

  Perl - the language to Get Things Done.

Stefan Ram wrote:
> "Mike Schilling" <mscottschilling@hotmail.com> writes:
>> "ClassCastException" <zjkg3d9gj56@gmail.invalid> wrote in message 
>> news:ib57sr$uq4$1@news.eternal-september.org...
>>> I don't know if anyone can ever get used to Perl.
>> Ask someone who's used it extensively.  The answer will be "Of course."
> 
>   (Just in case someone STILL does not have seen this yet:)
> 
> http://imgs.xkcd.com/comics/lisp.jpg
> 
HA!!!!!

"Thomas G. Marshall" <tgmforum@gmail.com> writes:

> Broken logic.  You can likely become a proficient coder in anything
> horrid given enough time---in fact there's a programming language
> designed to be specifically difficult, it's name escapes me.

Whitespace is one:

  <http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29>

Brainf**k is another:

  <http://en.wikipedia.org/wiki/Brainfuck>

sherm--

-- 
Sherm Pendley
                                   <http://camelbones.sourceforge.net>
Cocoa Developer

Lew wrote:
> Stefan Ram wrote:
>>    We can imagine a language where the expression statement
>>    is written as
>>
>>        <expression>  ";",
>>
>>    while the empty statement is written as
>>
>>        "Ø";
>>
>>    then we would have:
>>
>>        while( *p++ = *q++ )Ø
> 
> To save trouble figuring out how to type "Ø" on, say, U.S. keyboards, 
> let's define a digraph "{}" to represent that construct:
> 
>   while( *p++ = *q++ ){}

This trends towards the Ada form:

    while some_bool_expr loop null; end loop;

where "null;" is the empty (do-nothing) statement in Ada.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> writes:

> On 11/6/10 7:26 PM, Mike Schilling wrote:
>>
>>
>> "Nick" <3-nospam@temporary-address.org.uk> wrote in message
>> news:87k4kqk4ad.fsf@temporary-address.org.uk...
>>> /var/www/canal$ grep -B1 '^ *; *$' source/*.c
>>> source/bigops.c- while(*tag && *tag==' ') // skip leading spaces
>>> source/bigops.c: ;
>>
>> That might run for a long time.
>
> Nah.  He just didn't post the line that came before:
>
>   if (*tag != '\0') return;
>
> Of course, even so, one wonders why the condition bothers with "*tag
> &&".  Surely the more restrictive "*tag==' '" would be sufficient.
>
> Why such silly code is relevant in a discussion about the _right_ way
> to do things, I have no idea.

That's flipping weird isn't it.  

I've just discovered it's from a chunk of part-written code that has
been #defined out.  It still makes me wonder why I wrote it like that
(there's another bit later that would be another endless loop that
didn't get picked up by the grep as there is a comment on the ; line).

So baffling but at least not live.  And thanks for the reminder that I
need to weed my codebase.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

Stefan Ram wrote:
>>> We can imagine a language where the expression statement
>>> is written as
>>>
>>>     <expression> ";",
>>>
>>> while the empty statement is written as
>>>
>>>     "Ø";
>>>
>>> then we would have:
>>>
>>>     while( *p++ = *q++ )Ø

Lew wrote:
>> To save trouble figuring out how to type "Ø" on, say, U.S. keyboards,
>> let's define a digraph "{}" to represent that construct:
>>
>>     while( *p++ = *q++ ){}

Niklas Holsti wrote:
> This trends towards the Ada form:
>
> while some_bool_expr loop null; end loop;
>
> where "null;" is the empty (do-nothing) statement in Ada.

So in effect you are saying that the C family of languages is "trending 
towards" Ada since they already have "{}" as a way of representing an empty 
(do-nothing) statement.

No, that's backwards.  C came before Ada.  So actually, Ada is trending 
towards C because it has "null" as a synonym for C's "{}".

You had it backwards, Niklas.

-- 
Lew

On Sat, 06 Nov 2010 17:26:58 -0700, Thomas G. Marshall wrote:

> On Nov 1, 5:02 pm, Tom Anderson <t...@urchin.earth.li> wrote:
> 
> ...[snip]...
> 
>> Python has been called 'executable pseudocode'. If written cleanly, it
>> is highly readable, even to those who don't know it.
> 
> Seems to me I heard this of COBOL once.  ;)
>
Anybody wrote pseudo-code that verbose deserves to be sentenced to write 
RPG III for at least 10 years and immediately given life if they have 
become RPG fans during their sentence.
 
>> If written badly, of course, it's as bad as the cleanest bits of perl.
> 
> I have argued against perl endlessly because of this.  It seems to be
> something that its designer was so very proud of, at least in the
> beginning.  $| is gross.
>
It still looks like its origin: a lightly disguised mixture of shell 
script, sed, awk with a few common UNIX utilities such as tr and sort 
thrown in.

Where others use Perl, I tend to use gawk + shell script because this is 
generally less toxic. However, I must admit that Perl regexes are rather 
good - up there with Java in that respect.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 11/06/2010 11:42 PM, Thomas G. Marshall wrote:
> in fact there's a programming language
> designed to be specifically difficult, it's name escapes me.

Malbolge is what you are looking for, I believe. The prototypical Hello 
World program took two years to write, but even then it gave everything 
in pretty unnatural casing (since then, it appears that someone has 
found a program that gives Hello World with the correct casing!).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On Nov 6, 11:11=A0am, James Dow Allen <jdallen2...@yahoo.com> wrote:
> On Nov 6, 10:25=A0am, c...@tiac.net (Richard Harter) wrote:
>
> > Have you ever actually seen a case where the semicolon was
> > actuallly unintended?
>
> I've seen 2 or 3 instances in FSF's gnu libc of the formula
>
> #define =A0FOO(xxx) \
> =A0 =A0 do { floogy(xxx); } while (0);

Interesting.  Presumably the compiler yanks the thing cleanly, and
you're still left with that IF syntax-able (<---homemade word) thing.

In C I used to use a home-crocked DBG() macro to >poof< lines out of
existance when DEBUG wasn't defined.  I suppose C would have allowed
an empty {} instead of empty space for the definition which would
allow it to remain IF syntax-able.

ClassCastException <zjkg3d9gj56@gmail.invalid> writes:
[...]
> I don't know if anyone can ever get used to Perl.
[...]

I have, but I'm not going to argue about it here.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Martin Gregorie wrote:
> Where others use Perl, I tend to use gawk + shell script because this is
> generally less toxic. However, I must admit that Perl regexes are rather
> good - up there with Java in that respect.

Java uses Perl(esque) regexes, so no coincidence.

-- 
Lew

In article <Perl-20101107051813@ram.dialup.fu-berlin.de>,
 ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> "Mike Schilling" <mscottschilling@hotmail.com> writes:
> >"ClassCastException" <zjkg3d9gj56@gmail.invalid> wrote in message 
> >news:ib57sr$uq4$1@news.eternal-september.org...
> >> I don't know if anyone can ever get used to Perl.
> >Ask someone who's used it extensively.  The answer will be "Of course."
> 
>   (Just in case someone STILL does not have seen this yet:)
> 
> http://imgs.xkcd.com/comics/lisp.jpg
> 
>   Perl - the language to Get Things Done.

ROTFL! Here's something I learned only after skimming a friend's copy 
of volume 0, <http://store.xkcd.com/>: For example, browse 
<http://xkcd.com/224/> and hover to see the tooltip, "We lost the 
documentation on quantum mechanics.  You'll have to decode the regexes 
yourself."

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Keith Thompson wrote:
> ClassCastException <zjkg3d9gj56@gmail.invalid> writes:
> [...]
>> I don't know if anyone can ever get used to Perl. [...]
>
> I have, but I'm not going to argue about it here.

I don't intend to argue about it either - there's nothing to be combative 
about - but back in the early '90's when I needed to do "scripting" type 
things on UNIX I had shell, awk and Perl to choose from, Python at the time 
wasn't all that appealing. For an entire set of tasks I therefore used Perl, 
starting with 4.019. I got good with it, and never understood why anyone had 
serious problems with it, including the so-called "line noise" "problem" 
that was never a problem for me. I found that universal software engineering 
principles (modularity, proper naming conventions, understanding scope) took 
care of problems in Perl that people always seemed to be complaining about, 
that are in fact problems in practically every other programming language.

Again, not looking to incite here, but I look at all this from the 
standpoint of a consulting developer. I don't have all that much leeway in 
what I get to use, so I have to use practically everything. The languages 
and libraries and tools I encounter are what they are, and I lose time 
complaining about them. I've used Python nearly as much as Perl, now, with a 
smattering of Ruby. I really don't much care which one I do use. I don't 
much care whether I use C#/F# in .NET or Scala/Java in a J2EE environment. 
My own-time dabbling has been Haskell and J for a few years now, and I'll 
never get to use either in the real world. :-) The way I see it, in the 
final analysis, is that complaining about crappy or missing features is a 
waste of time; do a Clint Eastwood and "improvise, adapt and overcome".

AHS
-- 
Hanging one scoundrel, it appears, does not deter the next. Well, what
of it? The first one is at least disposed of. -- H.L. Mencken 

On 06.11.2010 16:28, Lew wrote:
> Robert Klemme wrote:
>>> Of course I have to throw in Ruby here. Very clean syntax, clean OO
>>> implementation and no significant whitespace. I often find that Ruby
>>> code looks like pseudo code - but it actually can be executed. :-)
>
> I find that it looks like pseudo-programming. Sure, it can be executed,
> but it's the writer who should be.

Uh, oh...  Where can I get my "one cross each"?

> Nick Keighley wrote:
>> when faced with the choice of learning python or ruby I chose python.
>> ruby looked a bit strange. Having skimmed the tutorial you mention it
>> looks a lot less strange! But if you write pseudo code like this then
>> heaven help your collegues!
>>
>> ARGF.each { |line| print line if line =~ /Ruby/ }
>
> Let's just bring back APL, why don't we?

:-)

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

On 06.11.2010 10:30, Nick Keighley wrote:
> On Nov 2, 5:42 pm, Robert Klemme<shortcut...@googlemail.com>  wrote:
>> On 01.11.2010 22:30, BartC wrote:
>>
>>> "Tom Anderson"<t...@urchin.earth.li>  wrote in message
>>> news:alpine.DEB.1.10.1011012102020.4900@urchin.earth.li...
>>
>>>> Python has been called 'executable pseudocode'. If written cleanly, it is
>>>> highly readable, even to those who don't know it.
>>
>>> I think Python is the last language I'd use for pseudocode. No-one
>>> writing Python can resist using all it's features which renders it
>>> incomprehensible to anyone else. And for porting code, it is also
>>> necessary to duplicate it's myriad libraries.
>>
>>> Probably Lua is better for that role, being far simpler with less
>>> built-in stuff.
>>
>> Of course I have to throw in Ruby here.  Very clean syntax, clean OO
>> implementation and no significant whitespace.  I often find that Ruby
>> code looks like pseudo code - but it actually can be executed.  :-)
>
> when faced with the choice of learning python or ruby I chose python.
> ruby looked a bit strange. Having skimmed the tutorial you mention it
> looks a lot less strange!

I'm really curious what you found strange initially and what points made 
you change your mind.  That might help improve the next "Ruby for X 
coders" guide.

> But if you write pseudo code like this then
> heaven help your collegues!
>
> ARGF.each { |line|  print line  if line =~ /Ruby/ }

Well, you basically only need to know that ARGF iterates over all files 
in ARGV or reads from stdin if ARGV is empty.  I think the rest is 
pretty self explanatory, isn't it? :-)

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

On 07.11.2010 20:33, Arved Sandstrom wrote:
> For an entire set of tasks I therefore used Perl,
> starting with 4.019. I got good with it, and never understood why anyone had
> serious problems with it, including the so-called "line noise" "problem"
> that was never a problem for me. I found that universal software engineering
> principles (modularity, proper naming conventions, understanding scope) took
> care of problems in Perl that people always seemed to be complaining about,
> that are in fact problems in practically every other programming language.

Few years back I was used to Perl, too.  But nowadays I have forgotten 
all the subtleties of references arrays, scalars and implicit 
conversions going on.  That makes me wary and I wouldn't be so sure 
whether I can properly decode a Perl program without going back and 
forth through documentation nowadays.  I would not say the same about C 
for example which I do not use for several years as well.  I would still 
consider it more readable than Perl and this is what makes be believe 
that Perl has real disadvantages compared to other similar languages.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Lew wrote:
> Stefan Ram wrote:
>>>> We can imagine a language where the expression statement
>>>> is written as
>>>>
>>>>     <expression> ";",
>>>>
>>>> while the empty statement is written as
>>>>
>>>>     "Ø";
>>>>
>>>> then we would have:
>>>>
>>>>     while( *p++ = *q++ )Ø
> 
> Lew wrote:
>>> To save trouble figuring out how to type "Ø" on, say, U.S. keyboards,
>>> let's define a digraph "{}" to represent that construct:
>>>
>>>     while( *p++ = *q++ ){}
> 
> Niklas Holsti wrote:
>> This trends towards the Ada form:
>>
>> while some_bool_expr loop null; end loop;
>>
>> where "null;" is the empty (do-nothing) statement in Ada.
> 
> So in effect you are saying that the C family of languages is "trending 
> towards" Ada since they already have "{}" as a way of representing an 
> empty (do-nothing) statement.

I said nothing about trends in the "C family". The trend I see is in 
this discussion of how to use C syntax to write an empty loop body. The 
postings to which I replied try to make the empty loop body more 
visible, and less likely to be the result of a typing mistake or syntax 
goof, than is the case if just the C null statement ";" is used.

Stefan Ram imagined a language with a specific symbol, Ø, for the null 
statement, so I wanted to comment that Ada takes that approach, 
specifically to make null statements more visible.

Then you (Lew) noted that the empty compound statement {} is also a 
representation of "do nothing" in C. I think that is a good point, and 
{} is certainly more visible than a single semicolon. As one reads it 
from left to right, it suggests the same things as the Ada form: '{' 
suggests "here the loop body begins"; the empty interior suggests "do 
nothing"; and '}' suggests "here the loop body ends".

I think it would be a good idea for future C standards to deprecate the 
single semicolon as a null statement, in favour of {}. The C99 standard 
does not suggest using {}, as far as I could see.

> No, that's backwards.  C came before Ada.  So actually, Ada is trending 
> towards C because it has "null" as a synonym for C's "{}".

I was not speaking of the trends in language evolution, but of trends in 
this discussion. But I do see some small convergence in these languages. 
For one thing, Ada 2012 is introducing conditional expressions (if cond 
then value1 else value2), corresponding to the C conditional cond ? 
value1 : value2.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

On Nov 7, 9:25=A0pm, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 06.11.2010 10:30, Nick Keighley wrote:
>
>
>
>
>
> > On Nov 2, 5:42 pm, Robert Klemme<shortcut...@googlemail.com> =A0wrote:
> >> On 01.11.2010 22:30, BartC wrote:
>
> >>> "Tom Anderson"<t...@urchin.earth.li> =A0wrote in message
> >>>news:alpine.DEB.1.10.1011012102020.4900@urchin.earth.li...
>
> >>>> Python has been called 'executable pseudocode'. If written cleanly, =
it is
> >>>> highly readable, even to those who don't know it.
>
> >>> I think Python is the last language I'd use for pseudocode. No-one
> >>> writing Python can resist using all it's features which renders it
> >>> incomprehensible to anyone else. And for porting code, it is also
> >>> necessary to duplicate it's myriad libraries.
>
> >>> Probably Lua is better for that role, being far simpler with less
> >>> built-in stuff.
>
> >> Of course I have to throw in Ruby here. =A0Very clean syntax, clean OO
> >> implementation and no significant whitespace. =A0I often find that Rub=
y
> >> code looks like pseudo code - but it actually can be executed. =A0:-)
>
> > when faced with the choice of learning python or ruby I chose python.
> > ruby looked a bit strange. Having skimmed the tutorial you mention it
> > looks a lot less strange!
>
> I'm really curious what you found strange initially and what points made
> you change your mind. =A0That might help improve the next "Ruby for X
> coders" guide.
>
> > But if you write pseudo code like this then
> > heaven help your collegues!
>
> > ARGF.each { |line| =A0print line =A0if line =3D~ /Ruby/ }
>
> Well, you basically only need to know that ARGF iterates over all files
> in ARGV or reads from stdin if ARGV is empty. =A0I think the rest is
> pretty self explanatory, isn't it? :-)

oh I'm sure i could work it out. But if I were writing p-code it
wouldn't look like that!  To me p-code is either to explain something
to someone else or it's to help me figure something out. Hence my p-
code tends to reflect my programming history. It tends to be a
simplified Pascal and Python looks *very* much like my p-code (to such
an extent I thought they were stealing my ideas  :-)

On Nov 7, 3:42=A0am, "Thomas G. Marshall" <tgmfo...@gmail.com> wrote:
> On Nov 6, 9:00=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> > "Thomas G. Marshall" <tgmfo...@gmail.com> writes:


> > >I have argued against perl endlessly because of this. =A0It seems to b=
e
> > >something that its designer was so very proud of, at least in the
> > >beginning. =A0$| is gross.

I've seen some very readable perl. It had subroutines and comments and
so on. I've also seen some horrid perl.

> > This is a somewhat =BBchauvinistic=AB or =BBegocentric=AB
> > point of view, by which Russian or Chinese should be
> > =BBgross=AB, too, because it does not use =BBreadable=AB > latin
> > letters but =BBunreadable=AB Cyrillic or Chinese symbols.
> > However, it misses that for someone who has grown up
> > in a culture with Cyrillic letters the inverse holds.
>
> No, because most English speakers I know regard English as an inferior
> language to other more structured, less idiomatic languages with fewer
> irregulars.

as a native english speaker I have great sympathy for people learning
english after first learning a language more regular in spelling. Eg.
Italian, German, Dutch well pretty well every european language except
english! But I would not go so far as to call it an inferior
language.The inconsistencies reflect (partly) its multiple roots. This
is one of the strengths of english.

Italian: "english is difficult because there are so many phrases that
don't mean what they seem like they mean"

Nick: "I know, boco di lupo with learning english"


> > We cannot judge the readability of a language from the
> > outside, from the point of view of someone who does not know
> > the language well, but should judge it from the inside.

yes but we were talking pseudo code. The more weirdlyidiomatic the
langauge is the less useful it is as a pseudo-code (unless the
audience is veryfamilar with the chosen idiomatic language). I'm sure
APL is very powerful but I wouldn't choose it as a medium to explain
things to other people. Ditto Lisp.

> Broken logic. =A0You can likely become a proficient coder in anything
> horrid given enough time---in fact there's a programming language
> designed to be specifically difficult, it's name escapes me.

there's a few- Brainfuck is one

> =A0You
> might even become a very comfortable insider at using a screwdriver to
> pound in a nail. =A0That does not keep you from saying it's relatively a
> terrible idea (an inside judgment), nor does it preclude a fair
> outside judgment. =A0It does not preclude someone from having tried it
> as judging it as a bad idea. =A0If such a thing as coding clearly
> exists, then it's antithesis must also, and of all the degrees in
> between. =A0And some languages support this better than others---
> regardless of how used to it you can be.

this lisp people speak of "blub"- the language that people use when
they can't see the point of a more powerful language. "well I wrote a
compiler in FOTRAN IV so I don't see why you'd use anything else". If
a language doesn't support recursion then people who program in that
language will see recursion as unnecessary. COBOL programmers are
supposedly unaware of what a global variable is (allegedly everything
is global). The Lisp people of course implicitly believe that all non-
Lisps are a Blub.

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>this discussion. But I do see some small convergence in these languages. 
>For one thing, Ada 2012 is introducing conditional expressions (if cond 
>then value1 else value2), corresponding to the C conditional cond ? 
>value1 : value2.

  ... corresponding to the Algol-60 if:

      �3.3.2 Examples
      (...)
      if a<0 then A/B else if b=0 then B/A else z�

http://www.masswerk.at/algol60/report.htm#3

On Sun, 7 Nov 2010, Stefan Ram wrote:

> "Thomas G. Marshall" <tgmforum@gmail.com> writes:
>> I have argued against perl endlessly because of this.  It seems to be
>> something that its designer was so very proud of, at least in the
>> beginning.  $| is gross.
>
>  This is a somewhat ?chauvinistic? or ?egocentric? point of
>  view, by which Russian or Chinese should be ?gross?, too,
>  because it does not use ?readable? latin letters but
>  ?unreadable? Cyrillic or Chinese symbols. However, it misses
>  that for someone who has grown up in a culture with Cyrillic
>  letters the inverse holds.
>
>  We cannot judge the readability of a language from the
>  outside, from the point of view of someone who does not know
>  the language well, but should judge it from the inside.

perl was my primary language for about four years. I can say as an insider 
that it's unreadable. Moreover, that it's dreadful in many ways.

tom

-- 
""when i go to sleep, i dream "Wow. What a cool period of ulness."" --
TWIC, ox.clubs.ousfg -- William, ox.clubs.ousfg

On Sun, 7 Nov 2010, ClassCastException wrote:

> On Sat, 06 Nov 2010 20:42:11 -0700, Thomas G. Marshall wrote:
>
>> Broken logic.  You can likely become a proficient coder in anything
>> horrid given enough time---in fact there's a programming language
>> designed to be specifically difficult, it's name escapes me.
>
> Perl?
>
> :)
>
> Intercal most likely.

Haskell.

tom

-- 
""when i go to sleep, i dream "Wow. What a cool period of ulness."" --
TWIC, ox.clubs.ousfg -- William, ox.clubs.ousfg

On Sun, 7 Nov 2010, Stefan Ram wrote:

> "Mike Schilling" <mscottschilling@hotmail.com> writes:
>> "ClassCastException" <zjkg3d9gj56@gmail.invalid> wrote in message
>> news:ib57sr$uq4$1@news.eternal-september.org...
>>> I don't know if anyone can ever get used to Perl.
>> Ask someone who's used it extensively.  The answer will be "Of course."
>
>  (Just in case someone STILL does not have seen this yet:)
>
> http://imgs.xkcd.com/comics/lisp.jpg
>
>  Perl - the language to Get Things Done.

That's a funny (ish) comic, but it honestly isn't accurate. I wrote tons 
of perl for years, and it is absolutely *not* an effective way to Get 
Things Done for values 'thing' any bigger than a shell script. As soon as 
i learned python, i threw perl away and never looked back - i got more 
done, faster.

tom

-- 
""when i go to sleep, i dream "Wow. What a cool period of ulness."" --
TWIC, ox.clubs.ousfg -- William, ox.clubs.ousfg

On 11/06/2010 09:00 PM, Stefan Ram wrote:
> "Thomas G. Marshall"<tgmforum@gmail.com>  writes:
>> I have argued against perl endlessly because of this.  It seems to be
>> something that its designer was so very proud of, at least in the
>> beginning.  $| is gross.
>
>    This is a somewhat �chauvinistic� or �egocentric� point of
>    view, by which Russian or Chinese should be �gross�, too,
>    because it does not use �readable� latin letters but
>    �unreadable� Cyrillic or Chinese symbols. However, it misses
>    that for someone who has grown up in a culture with Cyrillic
>    letters the inverse holds.

To my knowledge, `$' and `|' are not letters in any script in the world, 
at least of any with at least 1 million speakers [1]. The situation with 
such characters is even worse, since with words as labels, you can go 
for some indication of what it means in a native language. On the other 
hand, an interpretation of `$|' would rely on knowing the names of the 
characters. And `|' is called many different things in English alone: 
vertical bar, pipe, bar, half-pipe, etc. And then using the idiomatic 
expression that pipes are related to input and output. Note that I'm 
assuming it has something to do with stdin; if it doesn't, that makes my 
argument about its unreadability even stronger since a native-born 
English speaker can't even deduce its meaning.

[1] Putting a cutoff at one million may seem chauvinistic, but with 
several thousand languages in the world, some with unusual orthographies 
that I am not aware of, "all" is a little bit wider than I dare go. If 
we're talking about programming languages, in any case, languages spoken 
by fewer than .1% of the world population are not likely going to be 
strongly influencing programming language design.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On Sun, 07 Nov 2010 15:08:04 -0800, Nick Keighley wrote:

> COBOL programmers are supposedly unaware of what a global variable
> is (allegedly everything is global).
> 
There's no allegedly about it: global is a non-term in COBOL. All data 
items are defined in one section or another of the program's DATA 
DIVISION and have the same scope, i.e. all data is accessible by any 
executable statement in the program. The sections of the data division 
are functional in that they define how the data in a section is used:
- items in the file section can be read and written with file i/o
- items in linkage section are are the formal arguments if the program
  is callable
- items in working-storage are private to the program in the Java sense
  of private.

And yet, having written far more COBOL than was ever good for me, I can 
confirm that it does a good, if verbose, job in the types of tasks it was 
designed for, which are mainly manipulating large amounts of structured 
data. Its easy to read if its tolerably written though, like all 
programming languages, can also be written dreadfully.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Sun, 07 Nov 2010 13:53:14 -0500, Lew wrote:

> Martin Gregorie wrote:
>> Where others use Perl, I tend to use gawk + shell script because this
>> is generally less toxic. However, I must admit that Perl regexes are
>> rather good - up there with Java in that respect.
> 
> Java uses Perl(esque) regexes, so no coincidence.

Yes. I use pcre a lot (writing Spamassassin rules) and in the few cases 
so far where I've used Java regexes, I've basically written a pcre and 
found no surprises.

FWIW there are a few web tools out there that can be used for interactive 
pcre development. I think they should also be useful for Java. Here are 
the ones I know about.

http://www.fileformat.info/tool/regex.htm - for Java regex development
http://www.solmetra.com/scripts/regex/ - for PHP, Perl and Python regexes






-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Arved Sandstrom wrote:
....
> I don't intend to argue about it either - there's nothing to be combative 
> about - but back in the early '90's when I needed to do "scripting" type 
> things on UNIX I had shell, awk and Perl to choose from, Python at the time 
> wasn't all that appealing. For an entire set of tasks I therefore used Perl, 
> starting with 4.019. I got good with it, and never understood why anyone had 
> serious problems with it, including the so-called "line noise" "problem" 
> that was never a problem for me. I found that universal software engineering 
> principles (modularity, proper naming conventions, understanding scope) took 
> care of problems in Perl that people always seemed to be complaining about, 
> that are in fact problems in practically every other programming language.
....

I don't really like Perl for some aesthetic reasons, which are purely a
matter of taste not objective.

I strongly agree on the benefits of applying normal software engineering
principles to Perl. It does not have to be write once, or even
maintainable only by the original writer.

Patricia

Martin Gregorie wrote:
> On Sun, 07 Nov 2010 15:08:04 -0800, Nick Keighley wrote:
> 
>> COBOL programmers are supposedly unaware of what a global variable
>> is (allegedly everything is global).
>>
> There's no allegedly about it: global is a non-term in COBOL. All data 
> items are defined in one section or another of the program's DATA 
> DIVISION and have the same scope, i.e. all data is accessible by any 
> executable statement in the program.

According to Wikipedia, that was true for earlier forms of COBOL, but 
the current standard includes local variables, too.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

On Mon, 8 Nov 2010, Martin Gregorie wrote:

> On Sun, 07 Nov 2010 15:08:04 -0800, Nick Keighley wrote:
>
>> COBOL programmers are supposedly unaware of what a global variable
>> is (allegedly everything is global).
>
> There's no allegedly about it: global is a non-term in COBOL. All data
> items are defined in one section or another of the program's DATA
> DIVISION and have the same scope, i.e. all data is accessible by any
> executable statement in the program. The sections of the data division
> are functional in that they define how the data in a section is used:
> - items in the file section can be read and written with file i/o
> - items in linkage section are are the formal arguments if the program
>  is callable
> - items in working-storage are private to the program in the Java sense
>  of private.

How big is a typical 'program'? If it's the size of a class, then COBOL's 
implicit 'global' is really an implicit 'private static'; if it's the size 
of a package, then it's really an implicit '/* default */ static'. If it's 
the size of an application, then it really is global, and i can imagine 
pain results.

A bit of googling reveals that there are various extensions to COBOL for 
things like local variables, thread-locals, making programs recursive or 
reentrant, etc. And of course there's an Object COBOL.

So, whilst it may be true that for most of its life, and for the time when 
it was most important, COBOL's programmers talked as much about global 
variables as fish do about water, but i doubt that's been true since, i 
would guess, 1990.

tom

-- 
The future will accost us with boob-slapping ferocity. -- H. G. Wells

On Mon, 08 Nov 2010 20:48:32 +0000, Tom Anderson wrote:

> How big is a typical 'program'?
>
I've written/worked on programs varying from 300 lines (a simple 'grab a 
record or two and paint a screen') called module in a mainframe online 
database application to 8000 lines or so for a monolithic data analysis 
program. It normally would be between 1000 and 3000 lines.
 
> If it's the size of a class, then
> COBOL's implicit 'global' is really an implicit 'private static';
>
It doesn't really map that way: A program is either:

- a monolithic single file which would be broken into a set of classes
  if it was written in (Java) or a smaller number of C source modules
  if it was written in C.

- or it corresponds to a single subroutine or function in Fortran/Pascal/
C terms. 

In the COBOL shops I've worked in its been unusual to break a program 
into separate compilation units, probably because the language definition 
mandates that the compiler includes a copy library. This allows you to 
define 'copy units' which contain arbitrarily large chunks of source and 
pull them into a program, altering the names of data items and procedure 
division labels as needed to avoid conflicts. A copy unit can define 
data, such as a record or print line definition, or procedure division 
items which can be anything from a single sentence paragraph to an entire 
procedure division section. 

Terminology clarification: A statement is called a 'sentence', a 
'paragraph has a name (label) and contains one or more sentences and a 
'section', which also has a name, contains one or more sections. Sections 
and paragraphs can be PERFORMed (equivalent to a procedure call) or 
referenced in a GO TO statement and yes, you can legally PERFORM and GO 
TO the same paragraph from different parts of the same program.

Since (I think) COBOL 85 its been possible to put a set of related 
programs into a single source file, somewhat like using nested classes in 
Java, but no shop I've worked in has used this ability.
 
> A bit of googling reveals that there are various extensions to COBOL for
> things like local variables, thread-locals, making programs recursive or
> reentrant, etc. And of course there's an Object COBOL.
>
The last version I used seriously was MicroFocus COBOL 90, in around 1995 
and a bit of Tandem NonStop COBOL a year or two later. I don't recall 
seeing any of those features in either COBOL implementation, but then 
again neither needed to use them. The Tandem COBOL formed callable 
modules embedded in the Pathway application manager (i.e., equivalent to 
using JBOSS or Tomcat). The MicroFocus COBOL code ran in another 
application framework, but this one was written in C and optimised for 
switching financial messages between an ATM network and the accounting 
system on a mainframe. The bank-specific logic was defined by writing 
callable COBOL modules.
     
> So, whilst it may be true that for most of its life, and for the time
> when it was most important, COBOL's programmers talked as much about
> global variables as fish do about water, but i doubt that's been true
> since, i would guess, 1990.
>
I don't know, but then I haven't seen or been involved with any newly 
written COBOL since about 1983. All the COBOL I've seen since would 
probably have dated from the mid/late 1980s since that was when the kit 
it ran on (Tandem Guardian NonStop, Stratus fault tolerant and NCR UNIX 
boxes) became widely used, and had been modified to suit changing 
requirements since then rather than being rewritten.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Mon, 08 Nov 2010 22:37:34 +0200, Niklas Holsti wrote:

> Martin Gregorie wrote:
>> On Sun, 07 Nov 2010 15:08:04 -0800, Nick Keighley wrote:
>> 
>>> COBOL programmers are supposedly unaware of what a global variable is
>>> (allegedly everything is global).
>>>
>> There's no allegedly about it: global is a non-term in COBOL. All data
>> items are defined in one section or another of the program's DATA
>> DIVISION and have the same scope, i.e. all data is accessible by any
>> executable statement in the program.
> 
> According to Wikipedia, that was true for earlier forms of COBOL, but
> the current standard includes local variables, too.
>
Are you sure? "COBOL 2002 and object-oriented COBOL" mentions locale-
based processing, not local variables, and "Features" says that it 
originally had no local variables but not that they have been added.

I suppose if you include callable programs (i.e. with LINKAGE SECTIONs) 
in the same source file as the program that calls them you could say the 
data items in the data division of the callable programs are local, but 
thats about it. In any case I consider the concept of a multi-program 
source file to be a misfeature the typical COBOL program is big enough 
already without putting several of them in a single source file.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On November 8, 2010 17:02, in comp.lang.c, martin@address-in-sig.invalid
wrote:

> On Mon, 08 Nov 2010 22:37:34 +0200, Niklas Holsti wrote:
> 
>> Martin Gregorie wrote:
>>> On Sun, 07 Nov 2010 15:08:04 -0800, Nick Keighley wrote:
>>> 
>>>> COBOL programmers are supposedly unaware of what a global variable is
>>>> (allegedly everything is global).
>>>>
>>> There's no allegedly about it: global is a non-term in COBOL. All data
>>> items are defined in one section or another of the program's DATA
>>> DIVISION and have the same scope, i.e. all data is accessible by any
>>> executable statement in the program.
>> 
>> According to Wikipedia, that was true for earlier forms of COBOL, but
>> the current standard includes local variables, too.
>>
> Are you sure? "COBOL 2002 and object-oriented COBOL" mentions locale-
> based processing, not local variables, and "Features" says that it
> originally had no local variables but not that they have been added.

IBM's COBOL compilers support the LOCAL-STORAGE SECTION (which provides
a "threadable" or "object" isolated storage) along with the usual
WORKING-STORAGE SECTION (which provides a compile-unit-wide storage).

FWIW, COBOL programs are typically managed in a way similar to C functions;
each COBOL program (typically) represents one callable entrypoint (i.e. a
single "function") with arguments ("LINKAGE SECTION"), local static
variables ("WORKING-STORAGE SECTION"), and (now) thread/object-local static
variables ("LOCAL-STORAGE SECTION"). 

> I suppose if you include callable programs (i.e. with LINKAGE SECTIONs)
> in the same source file as the program that calls them you could say the
> data items in the data division of the callable programs are local, but
> thats about it. In any case I consider the concept of a multi-program
> source file to be a misfeature the typical COBOL program is big enough
> already without putting several of them in a single source file.
> 
> 

-- 
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
----------      Slackware - Because I know what I'm doing.         ------

Tom Anderson wrote:
> On Sun, 7 Nov 2010, ClassCastException wrote:
>
>> On Sat, 06 Nov 2010 20:42:11 -0700, Thomas G. Marshall wrote:
>>
>>> Broken logic.  You can likely become a proficient coder in anything
>>> horrid given enough time---in fact there's a programming language
>>> designed to be specifically difficult, it's name escapes me.
>>
>> Perl?
>>
>> :)
>>
>> Intercal most likely.
>
> Haskell.
>
> tom

You're kidding, right? Haskell has a steeper learning curve, so may be 
considered difficult in that sense, but once you've gotten good at it (which 
doesn't take all that long) its ability to write clean, concise, correct 
programs dwarfs that of most languages. It certainly wasn't *designed* to be 
difficult.

AHS
-- 
Hanging one scoundrel, it appears, does not deter the next. Well, what
of it? The first one is at least disposed of. -- H.L. Mencken 

"Tom Anderson" <twic@urchin.earth.li> wrote in message 
news:alpine.DEB.1.10.1011082035220.27105@urchin.earth.li...
> A bit of googling reveals that there are various extensions to COBOL for 
> things like local variables, thread-locals, making programs recursive or 
> reentrant, etc. And of course there's an Object COBOL.

AKA MOVE  COBOL + 1 TO COBOL.
 

"Mike Schilling" <mscottschilling@hotmail.com> writes:
> "Tom Anderson" <twic@urchin.earth.li> wrote in message 
> news:alpine.DEB.1.10.1011082035220.27105@urchin.earth.li...
>> A bit of googling reveals that there are various extensions to COBOL for 
>> things like local variables, thread-locals, making programs recursive or 
>> reentrant, etc. And of course there's an Object COBOL.
>
> AKA MOVE  COBOL + 1 TO COBOL.

I thought it was
    ADD 1 TO COBOL.
or possibly
    ADD 1 TO COBOL GIVING COBOL.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <kst-u@mib.org> writes:
> "Mike Schilling" <mscottschilling@hotmail.com> writes:

>> AKA MOVE  COBOL + 1 TO COBOL.

You can't compute in a MOVE statement.

> I thought it was
>     ADD 1 TO COBOL.
> or possibly
>     ADD 1 TO COBOL GIVING COBOL.

...or possibly
           COMPUTE COBOL = COBOL + 1.

-- 
Jukka Lahtinen

Keith Thompson <kst-u@mib.org> writes:

> "Thomas G. Marshall" <tgmforum@gmail.com> writes:
>> On Oct 31, 6:23 pm, Keith Thompson <ks...@mib.org> wrote:
>>> Ian Collins <ian-n...@hotmail.com> writes:
>>> > On 11/ 1/10 08:17 AM, Stefan Ram wrote:
>>> >> Ian Collins<ian-n...@hotmail.com>  writes:
>>> >>>> The point of having no {} is that you realise that all the *serious*
>>> >>>> stuff is going on inside the while loop statement itself.
>>> >>> It's a great way to confuse readers!
>>>
>>> >>    Indeed, most people will be confused by this, since most
>>> >>    people do not know the C programming language at all.
>>> >>    However, a C programmer will not be confused by this (by
>>> >>    definition).
>>>
>>> > Restoring the context:
>>>
>>> > James Dow Allen <gm...@jamesdowallen.nospam> writes:
>>>
>>> >  > I prefer
>>> >  >     while (*p++ = *q++) {
>>> >  >     }
>>>
>>> > The confusion stems not from the syntax, but from the empty braces, did
>>> > he intend there to be some code in there?
>>>
>>> One possible alternative is:
>>>
>>>     while (*p++ = *q++) {
>>>         /* nothing */
>>>     }
>>>
>>> Another is:
>>>
>>>     while (*p++ = *q++) {
>>>         continue;
>>>     }
>>
>> I know you weren't specifically suggesting these per se, but I might
>> argue that both of those are a form of over-engineering that I don't
>> think there's a term for.  Over verbosity?  While they certainly seem
>> safer overall, it somehow seems just a little more than is necessary
>> for even the exhausted engineer at 3am hopped on caffeine <--
>> (tiredness & caffeine-addled are my standard metrics for defensive
>> coding).
>
> I wasn't specifically suggesting them, but now I will: I specifically
> suggest them.  I don't find either form overly verbose.
>
> In this particular case, I'd say that a loop with an empty body is
> sufficiently unusual that there should be *some* explicit way of
> indicating it; otherwise it's easily mistaken for a typo.  [snip]

That could be simply

    do ; while (*p++ = *q++);

The probability that the empty loop body resulted from a typo is
extremely small.

cri@tiac.net (Richard Harter) writes:

> On Fri, 05 Nov 2010 18:20:40 -0700, Keith Thompson
> <kst-u@mib.org> wrote:
>
>
>>
>>No, it wouldn't.  The problem with the original version:
>>
>>    while (*p++ = *q++);
>>        do_something;
>>
>>is that it's hard to be sure whether the author messed up the
>>indentation on the second line:
>>
>>    while (*p++ = *q++);
>>    do_something;
>>
>>or added an unintended semicolon:
>>
>>    while (*p++ = *q++)
>>        do_something;
>>
>>Braces would make it obvious which was intended.
>
> Have you ever actually seen a case where the semicolon was
> actuallly unintended?  [snip]

Not often, but on rare occasions I've spent some time
chasing down a problem that turned out to be an extra
semicolon like in the original version.

> Personally I think all of these little gimmicks to indicate an
> empty body have less than no value; they are just noise.  [snip]

I sympathize with the personal reaction.  Despite that, if
what we're interested in is an actual software engineering
result, a measurement of both costs and benefits should be
undertaken, across a full product lifecycle, and then base
an assessment on the measured data rather than just
anecdotal evidence.

James Dow Allen <jdallen2000@yahoo.com> writes:

> On Nov 1, 1:59 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> On 11/ 1/10 12:32 AM, Richard wrote:
>> > James Dow Allen<gm...@jamesdowallen.nospam>  writes:
>>
>> >> "BGB / cr88192"<cr88...@hotmail.com>  might have writ, in
>> >>news:i9v341$2so$1@news.albasani.net:
>>
>> >>> ... some compilers will warn about unused local
>> >>> variables, which is personally a bit annoying.
>>
>> >> I once used a "language" where some unused variables, believe it or not,
>> >> caused Fatal Errors!!  I even complained about it on Usenet in
>> >> Message<90...@sun.uucp>  :
>>
>> >>http://groups.google.com/group/comp.unix.wizards/msg/3774732a57ef112d?
>> >> hl=en&dmode=source
>>
>> >> (People e-mailed me in response to that post, saying they'd printed
>> >> it and taped it to the wall!)
>>
>> >>> "christian.bau"<christian....@cbau.wanadoo.co.uk>  wrote:
>> >>>> while( *p++ = *q++ );
>>
>> >>>> is an idiom known to every C programmer.
>>
>> >> I prefer
>> >>      while (*p++ = *q++) {
>> >>      }
>>
>> >> James Dow Allen
>>
>> > Why? That's ridiculous.
>>
>> > The point of having no {} is that you realise that all the *serious*
>> > stuff is going on inside the while loop statement itself.
>>
>> It's a great way to confuse readers!
>
> I find these objections baffling.  It's only a short slide from
>      while (foo) ;
> to
>      while (foo) gak;
> so the construction
>      while (foo) {
>      }
> is the clearest way *to emphasize* that the while-body is empty!

No doubt you would agree that

    NO_BODY:  while (foo) goto NO_BODY;

has greater and therefore clearer emphasis that the loop body is
intentionally empty.  This construction is therefore absolutely
and undeniably the best possible way to indicate empty loop
bodies.  How could any reasonable person disagree?  ;)

On Nov 9, 4:22=A0pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
> I sympathize with the personal reaction. =A0Despite that, if
> what we're interested in is an actual software engineering
> result, a measurement of both costs and benefits should be
> undertaken, across a full product lifecycle, and then base
> an assessment on the measured data rather than just
> anecdotal evidence.
>
You can't measure everything. The main benefit is that readable code
is more maintainable. However there are far too many variables -
experience and skill of maintaining programmer, familiarity of
maintainer with source code, complexity of function, caffeine level of
maintaining programmer - which will entirely swamp any signal from the
symbol used to represent an empty loop.

On Sun, 07 Nov 2010 10:27:11 -0800, Keith Thompson wrote:

> ClassCastException <zjkg3d9gj56@gmail.invalid> writes: [...]
>> I don't know if anyone can ever get used to Perl.
> [...]
> 
> I have

This is, quite possibly, the most frightening thing I have ever read.

On Sun, 07 Nov 2010 15:08:04 -0800, Nick Keighley wrote:

> On Nov 7, 3:42 am, "Thomas G. Marshall" <tgmfo...@gmail.com> wrote:
>> On Nov 6, 9:00 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> > "Thomas G. Marshall" <tgmfo...@gmail.com> writes:
> 
> 
>> > >I have argued against perl endlessly because of this.  It seems to
>> > >be something that its designer was so very proud of, at least in the
>> > >beginning.  $| is gross.
> 
> I've seen some very readable perl. It had subroutines and comments and
> so on. I've also seen some horrid perl.

And guess which of the two he saw while on mescaline and which while 
sober? ;)

ClassCastException <zjkg3d9gj56@gmail.invalid> writes:
> On Sun, 07 Nov 2010 10:27:11 -0800, Keith Thompson wrote:
>> ClassCastException <zjkg3d9gj56@gmail.invalid> writes: [...]
>>> I don't know if anyone can ever get used to Perl.
>> [...]
>> 
>> I have
>
> This is, quite possibly, the most frightening thing I have ever read.

If you want to have a language war, please take it elsewhere.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Nov 9, 9:31=A0am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> James Dow Allen <jdallen2...@yahoo.com> writes:
>
>
>
> > On Nov 1, 1:59 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> On 11/ 1/10 12:32 AM, Richard wrote:
> >> > James Dow Allen<gm...@jamesdowallen.nospam> =A0writes:
>
> >> >> "BGB / cr88192"<cr88...@hotmail.com> =A0might have writ, in
> >> >>news:i9v341$2so$1@news.albasani.net:
>
> >> >>> ... some compilers will warn about unused local
> >> >>> variables, which is personally a bit annoying.
>
> >> >> I once used a "language" where some unused variables, believe it or=
 not,
> >> >> caused Fatal Errors!! =A0I even complained about it on Usenet in
> >> >> Message<90...@sun.uucp> =A0:
>
> >> >>http://groups.google.com/group/comp.unix.wizards/msg/3774732a57ef112=
d?
> >> >> hl=3Den&dmode=3Dsource
>
> >> >> (People e-mailed me in response to that post, saying they'd printed
> >> >> it and taped it to the wall!)
>
> >> >>> "christian.bau"<christian....@cbau.wanadoo.co.uk> =A0wrote:
> >> >>>> while( *p++ =3D *q++ );
>
> >> >>>> is an idiom known to every C programmer.
>
> >> >> I prefer
> >> >> =A0 =A0 =A0while (*p++ =3D *q++) {
> >> >> =A0 =A0 =A0}
>
> >> >> James Dow Allen
>
> >> > Why? That's ridiculous.
>
> >> > The point of having no {} is that you realise that all the *serious*
> >> > stuff is going on inside the while loop statement itself.
>
> >> It's a great way to confuse readers!
>
> > I find these objections baffling. =A0It's only a short slide from
> > =A0 =A0 =A0while (foo) ;
> > to
> > =A0 =A0 =A0while (foo) gak;
> > so the construction
> > =A0 =A0 =A0while (foo) {
> > =A0 =A0 =A0}
> > is the clearest way *to emphasize* that the while-body is empty!
>
> No doubt you would agree that
>
> =A0 =A0 NO_BODY: =A0while (foo) goto NO_BODY;
>
> has greater and therefore clearer emphasis that the loop body is
> intentionally empty. =A0This construction is therefore absolutely
> and undeniably the best possible way to indicate empty loop
> bodies. =A0How could any reasonable person disagree? =A0;)


Yeek.  If you're gonna be gross, be less gross:

        NO_BODY: if (foo) goto NO_BODY;

lol...

On Tue, 09 Nov 2010 10:32:01 -0800, Keith Thompson wrote:

> ClassCastException <zjkg3d9gj56@gmail.invalid> writes:
>> On Sun, 07 Nov 2010 10:27:11 -0800, Keith Thompson wrote:
>>> ClassCastException <zjkg3d9gj56@gmail.invalid> writes: [...]
>>>> I don't know if anyone can ever get used to Perl.
>>> [...]
>>> 
>>> I have
>>
>> This is, quite possibly, the most frightening thing I have ever read.
> 
> If you want to have a language war, please take it elsewhere.

Why? It's been ages since cljp has had a decent flamewar, or more than 
about 1000 posts a month. :)

On Mon, 8 Nov 2010, Arved Sandstrom wrote:

> Tom Anderson wrote:
>> On Sun, 7 Nov 2010, ClassCastException wrote:
>>
>>> On Sat, 06 Nov 2010 20:42:11 -0700, Thomas G. Marshall wrote:
>>>
>>>> Broken logic.  You can likely become a proficient coder in anything
>>>> horrid given enough time---in fact there's a programming language
>>>> designed to be specifically difficult, it's name escapes me.
>>>
>>> Perl?
>>>
>>> :)
>>>
>>> Intercal most likely.
>>
>> Haskell.
>
> You're kidding, right? Haskell has a steeper learning curve, so may be 
> considered difficult in that sense, but once you've gotten good at it 
> (which doesn't take all that long) its ability to write clean, concise, 
> correct programs dwarfs that of most languages. It certainly wasn't 
> *designed* to be difficult.

It was designed to be used by highly intelligent people. In the hands of 
intelligent people who have learned it, it is usable and powerful, and 
indeed, not difficult.

But most people, even most programmers, are not highly intelligent. For 
them, i suspect it would always be difficult.

Does that make it a difficult language?

I am also dubious about the idea that it's good for writing clean code. I 
see a lot of Haskell that tends towards wrapping a problem in the smallest 
possible ball of the strongest possible abstractions. That makes for 
concise, and perhaps elegant, code, but i'm not sure i'd call that clean. 
Clean to me implies a sort of self-opening limpidness, a quality which is 
at odds with cleverness.

tom

-- 
Get a bicycle. You will not regret it. If you live. -- Mark Twain

On Mon, 8 Nov 2010, Mike Schilling wrote:

> "Tom Anderson" <twic@urchin.earth.li> wrote in message 
> news:alpine.DEB.1.10.1011082035220.27105@urchin.earth.li...
>> A bit of googling reveals that there are various extensions to COBOL for 
>> things like local variables, thread-locals, making programs recursive or 
>> reentrant, etc. And of course there's an Object COBOL.
>
> AKA MOVE  COBOL + 1 TO COBOL.

I'd been told it was ADD ONE TO COBOL GIVING COBOL, but perhaps i was 
misled.

tom

-- 
Get a bicycle. You will not regret it. If you live. -- Mark Twain

"Martin Gregorie" <martin@address-in-sig.invalid> wrote in message 
news:ib8tn3$4pk$1@localhost.localdomain...
> On Sun, 07 Nov 2010 15:08:04 -0800, Nick Keighley wrote:
>
>> COBOL programmers are supposedly unaware of what a global variable
>> is (allegedly everything is global).

> And yet, having written far more COBOL than was ever good for me, I can
> confirm that it does a good, if verbose, job in the types of tasks it was
> designed for, which are mainly manipulating large amounts of structured
> data.

Verboseness can still depend on the programmer. The only Cobol I ever did 
was at college, on punched cards. Everyone was walking around with huge 
stacks of cards up to 6-8" high, while my pile was only about an inch high, 
for exactly the same assignment.

-- 
Bartc 

On Tue, 09 Nov 2010 22:10:12 +0000, Tom Anderson wrote:

> On Mon, 8 Nov 2010, Mike Schilling wrote:
> 
>> "Tom Anderson" <twic@urchin.earth.li> wrote in message
>> news:alpine.DEB.1.10.1011082035220.27105@urchin.earth.li...
>>> A bit of googling reveals that there are various extensions to COBOL
>>> for things like local variables, thread-locals, making programs
>>> recursive or reentrant, etc. And of course there's an Object COBOL.
>>
>> AKA MOVE  COBOL + 1 TO COBOL.
> 
> I'd been told it was ADD ONE TO COBOL GIVING COBOL, but perhaps i was
> misled.
>
None of the examples posted so far in this branch of the thread would 
compile because COBOL is a reserved word. 

There are so many reserved words in COBOL that the common idiom is to 
include a hyphen in your data names and labels because very few reserved 
words contain one. That said, there are three valid ways of incrementing 
a variable, listed in personal order of preference:

ADD 1 TO COBOL-COUNT.
COMPUTE COBOL-COUNT = COBOL-COUNT + 1.
ADD 1 TO COBOL-COUNT GIVING COBOL-COUNT.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Tue, 09 Nov 2010 22:19:12 +0000, BartC wrote:

> "Martin Gregorie" <martin@address-in-sig.invalid> wrote in message
> news:ib8tn3$4pk$1@localhost.localdomain...
>> On Sun, 07 Nov 2010 15:08:04 -0800, Nick Keighley wrote:
>>
>>> COBOL programmers are supposedly unaware of what a global variable is
>>> (allegedly everything is global).
> 
>> And yet, having written far more COBOL than was ever good for me, I can
>> confirm that it does a good, if verbose, job in the types of tasks it
>> was designed for, which are mainly manipulating large amounts of
>> structured data.
> 
> Verboseness can still depend on the programmer. The only Cobol I ever
> did was at college, on punched cards. Everyone was walking around with
> huge stacks of cards up to 6-8" high, while my pile was only about an
> inch high, for exactly the same assignment.
>
I meant verboseness in the sense that almost any COBOL statement is 
considerably longer than the equivalent statement in any other 
programming language simply because its a limited subset of English 
rather than the pseudo-mathematical notation used by almost every other 
language. About the only exception is that you can write 
	MOVE ALL ZERO TO TOTAL-ARRAY.
where almost all other languages require a loop.

I wouldn't consider a line count as a good measure of verbosity in COBOL 
or any other semi-free format language, because reduced line count can 
make for amazingly unreadable code of the one statement per line 
convention isn't followed. Compare the following:

ARRAY-TOTALLING.
    MOVE ZERO TO ARRAY-TOTAL. PERFORM ADD ARRAY-ELEMENT(I) TO ARRAY-TOTAL
    VARYING I FROM 1 BY 1 UNTIL I > ARRAY-SIZE END-PERFORM. MOVE
    ARRAY-TOTAL TO TL-VALUE. WRITE TOTAL-LINE AFTER 1.

with

ARRAY-TOTALLING SECTION.
AT-1.
    MOVE ZERO TO ARRAY-TOTAL. 
    PERFORM 
        ADD ARRAY-ELEMENT(I) TO ARRAY-TOTAL
        VARYING I FROM 1 BY 1 UNTIL I > ARRAY-SIZE 
    END-PERFORM. 
    MOVE ARRAY-TOTAL TO TL-VALUE. 
    WRITE TOTAL-LINE AFTER 1.
AT-EXIT.
    END.

NOTE Both can be executed with the same statement, as follows.

    PERFORM ARRAY_TOTALLING.

.... 4 lines vs 11 lines - I know which I'd rather read. Now extend that 
to 20-30 inline statements and the condensed code is a real mess. Anybody 
who wrote code like that would be off the project so fast he wouldn't 
know what happened in any shop I've worked in. 

Yeah, I know that you can write Java like that too if you put your mind 
to it, but IMO its less readable in COBOL if only because a full stop is 
harder to spot than  a semi-colon.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Nov 9, 5:42=A0pm, ClassCastException <zjkg3d9g...@gmail.invalid>
wrote:
> On Sun, 07 Nov 2010 15:08:04 -0800, Nick Keighley wrote:
> > On Nov 7, 3:42=A0am, "Thomas G. Marshall" <tgmfo...@gmail.com> wrote:
> >> On Nov 6, 9:00=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> >> > "Thomas G. Marshall" <tgmfo...@gmail.com> writes:
>
> >> > >I have argued against perl endlessly because of this. =A0It seems t=
o
> >> > >be something that its designer was so very proud of, at least in th=
e
> >> > >beginning. =A0$| is gross.
>
> > I've seen some very readable perl. It had subroutines and comments and
> > so on. I've also seen some horrid perl.
>
> And guess which of the two he saw while on mescaline and which while
> sober? ;)

what they were the same program?!!

On Tue, 09 Nov 2010 23:14:14 +0000, Martin Gregorie wrote:

> I meant verboseness in the sense that almost any COBOL statement is
> considerably longer than the equivalent statement in any other
> programming language simply because its a limited subset of English
> rather than the pseudo-mathematical notation used by almost every other
> language. About the only exception is that you can write
> 	MOVE ALL ZERO TO TOTAL-ARRAY.
> where almost all other languages require a loop.

(def total-array (vec (take n (repeat 0))))

So, emphasis on the "almost".

> ARRAY-TOTALLING.
>     MOVE ZERO TO ARRAY-TOTAL. PERFORM ADD ARRAY-ELEMENT(I) TO
>     ARRAY-TOTAL VARYING I FROM 1 BY 1 UNTIL I > ARRAY-SIZE END-PERFORM.
>     MOVE ARRAY-TOTAL TO TL-VALUE. WRITE TOTAL-LINE AFTER 1.

(def array-total (vec (take n (iterate inc 1))))
(def tl-value array-total)
(println 1)
(println total-line)

is more readable than either.

On Nov 9, 5:46=A0pm, Martin Gregorie <mar...@address-in-sig.invalid>
wrote:

....[snip]...

> ADD 1 TO COBOL-COUNT.
> COMPUTE COBOL-COUNT =3D COBOL-COUNT + 1.
> ADD 1 TO COBOL-COUNT GIVING COBOL-COUNT.

Just reading this @#$% makes me wanna cry.

Tom Anderson wrote:
> On Mon, 8 Nov 2010, Arved Sandstrom wrote:
[ SNIP ]
>> You're kidding, right? Haskell has a steeper learning curve, so may
>> be considered difficult in that sense, but once you've gotten good
>> at it (which doesn't take all that long) its ability to write clean,
>> concise, correct programs dwarfs that of most languages. It
>> certainly wasn't *designed* to be difficult.
>
> It was designed to be used by highly intelligent people. In the hands
> of intelligent people who have learned it, it is usable and powerful,
> and indeed, not difficult.
>
> But most people, even most programmers, are not highly intelligent.
> For them, i suspect it would always be difficult.
>
> Does that make it a difficult language?
>
> I am also dubious about the idea that it's good for writing clean
> code. I see a lot of Haskell that tends towards wrapping a problem in
> the smallest possible ball of the strongest possible abstractions.
> That makes for concise, and perhaps elegant, code, but i'm not sure
> i'd call that clean. Clean to me implies a sort of self-opening
> limpidness, a quality which is at odds with cleverness.
>
> tom

On the latter point, and I don't disagree about the nature of much of the 
Haskell code we see, I think what you're describing there is 
intermediate/beginner-expert code. In other words, stuff written by Haskell 
coders who have just recently reached the point where they _can_ write like 
that, and therefore delight in demonstrating it. I follow the main Haskell 
NG, and also the odd mailing list, and have my share of good Haskell books, 
and based on the material I see there, the true experts have generally 
gotten away from that and are writing for clarity again.

The same phenomenon happens in other languages too, to the extent that a 
given language makes terseness and extreme abstraction possible. It's 
absolutely possible in Java.

The degree to which people do this is, I believe, also related to the amount 
of exposure they've had to the real world, i.e. business experience, and the 
degree to which their code is going to be seen and used by other people. You 
know, and I know, that you can't perpetrate your super-concise, 
super-elegant, but impenetrable-to-the-unwashed code onto the shoulders of 
follow-on average maintainers, and get away with it for long. Not if you're 
a professional.

AHS
-- 
Hanging one scoundrel, it appears, does not deter the next. Well, what
of it? The first one is at least disposed of. -- H.L. Mencken 

On Tue, 09 Nov 2010 18:13:34 -0800, Thomas G. Marshall wrote:

> Just reading this @#$% makes me wanna cry.
>
Sadly, there's still useful stuff that COBOL can do more concisely than 
other more recent languages. 

Apart from its ability to fill an array or data structure with a literal 
value without using an explicit loop there's its edited fields. A field 
defined like this:

  PIC $,$$$,$$$,$$9.99DB BLANK WHEN ZERO

is always filled by moving a value to it with the following effects:

value	effect
zero	the field is entirely space-filled
5       $0.05
-1      $0.01DB
6995    $69.95
102400  $1,024.00

I don't know how to do this is any other language in a single statement 
with or without the use of conditional formatting, yet its a very common 
requirement in a financial program. 

OK, I'll shut up now.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Wed, 10 Nov 2010 12:50:33 +0000, Martin Gregorie wrote:

> On Tue, 09 Nov 2010 18:13:34 -0800, Thomas G. Marshall wrote:
> 
>> Just reading this @#$% makes me wanna cry.
>>
> Sadly, there's still useful stuff that COBOL can do more concisely than
> other more recent languages.

Even a Lisp with a suitable DSL?

"Robert Klemme" <shortcutter@googlemail.com> wrote in message
news:8jojqhFcgkU1@mid.individual.net...
> On 06.11.2010 10:30, Nick Keighley wrote:


>> But if you write pseudo code like this then
>> heaven help your collegues!
>>
>> ARGF.each { |line|  print line  if line =~ /Ruby/ }
>
> Well, you basically only need to know that ARGF iterates over all files in
> ARGV or reads from stdin if ARGV is empty.  I think the rest is pretty
> self explanatory, isn't it? :-)

Yes, but Ruby seems to delight in these kinds of off-kilter syntaxes.

For the purposes of pseudo-code, which of the following is clearer:

a.each {|line| ... }         # or:

for each line in a { ... }   # ?

Or which of the following:

99.times do |i| ... end      # (and what's the first i value, 0 or 1?) or:

for i =1 to 99 do ... end    # (or any of countless variations)?

It seems that once this way of using an iterator (or generator or whatever
it is) became available, then every program must make use of it at every 
opportunity ...

-- 
Bartc 

"Robert Klemme" <shortcutter@googlemail.com> wrote in message 
news:8jojk8Fba2U1@mid.individual.net...
> On 06.11.2010 16:28, Lew wrote:

>> Nick Keighley wrote:

>>> ARGF.each { |line| print line if line =~ /Ruby/ }
>>
>> Let's just bring back APL, why don't we?
>
> :-)

That *is* just a smiley, isn't it? You can't always tell with APL.

-- 
bartc  

On Wed, 10 Nov 2010, Ken Wesson wrote:

> On Wed, 10 Nov 2010 12:50:33 +0000, Martin Gregorie wrote:
>
>> On Tue, 09 Nov 2010 18:13:34 -0800, Thomas G. Marshall wrote:
>>
>>> Just reading this @#$% makes me wanna cry.
>>
>> Sadly, there's still useful stuff that COBOL can do more concisely than
>> other more recent languages.
>
> Even a Lisp with a suitable DSL?

Including the code needed to define the DSL, of course.

tom

-- 
I could tell you a great many more particulars but suppose that you are
tired of it by this time. -- John Backhouse, Trainspotter Zero

On Wed, 10 Nov 2010, Ken Wesson wrote:

> On Tue, 09 Nov 2010 23:14:14 +0000, Martin Gregorie wrote:
>
>> I meant verboseness in the sense that almost any COBOL statement is
>> considerably longer than the equivalent statement in any other
>> programming language simply because its a limited subset of English
>> rather than the pseudo-mathematical notation used by almost every other
>> language. About the only exception is that you can write
>> 	MOVE ALL ZERO TO TOTAL-ARRAY.
>> where almost all other languages require a loop.
>
> (def total-array (vec (take n (repeat 0))))

total_array = [0 for x in total_array]

>> ARRAY-TOTALLING.
>>     MOVE ZERO TO ARRAY-TOTAL. PERFORM ADD ARRAY-ELEMENT(I) TO
>>     ARRAY-TOTAL VARYING I FROM 1 BY 1 UNTIL I > ARRAY-SIZE END-PERFORM.
>>     MOVE ARRAY-TOTAL TO TL-VALUE. WRITE TOTAL-LINE AFTER 1.
>
> (def array-total (vec (take n (iterate inc 1))))
> (def tl-value array-total)
> (println 1)
> (println total-line)
>
> is more readable than either.

Are you serious?

tom

-- 
I could tell you a great many more particulars but suppose that you are
tired of it by this time. -- John Backhouse, Trainspotter Zero

On Wed, 10 Nov 2010, Arved Sandstrom wrote:

> Tom Anderson wrote:
>
>> I am also dubious about the idea that it's good for writing clean code. 
>> I see a lot of Haskell that tends towards wrapping a problem in the 
>> smallest possible ball of the strongest possible abstractions. That 
>> makes for concise, and perhaps elegant, code, but i'm not sure i'd call 
>> that clean. Clean to me implies a sort of self-opening limpidness, a 
>> quality which is at odds with cleverness.
>
> On the latter point, and I don't disagree about the nature of much of 
> the Haskell code we see, I think what you're describing there is 
> intermediate/beginner-expert code. In other words, stuff written by 
> Haskell coders who have just recently reached the point where they _can_ 
> write like that, and therefore delight in demonstrating it. I follow the 
> main Haskell NG, and also the odd mailing list, and have my share of 
> good Haskell books, and based on the material I see there, the true 
> experts have generally gotten away from that and are writing for clarity 
> again.

Interesting. I hadn't thought of it like that.

> The same phenomenon happens in other languages too, to the extent that a 
> given language makes terseness and extreme abstraction possible. It's 
> absolutely possible in Java.

I can attest to that. I've done even worse things in Python.

> The degree to which people do this is, I believe, also related to the 
> amount of exposure they've had to the real world, i.e. business 
> experience, and the degree to which their code is going to be seen and 
> used by other people. You know, and I know, that you can't perpetrate 
> your super-concise, super-elegant, but impenetrable-to-the-unwashed code 
> onto the shoulders of follow-on average maintainers, and get away with 
> it for long. Not if you're a professional.

There is a school of thought that says that if you can find a few guys who 
can handle the super-rocket-science code, you don't need to hire the 
average guys. I've never worked anywhere quite like that, though.

tom

-- 
Hawaii may be many things, but it is not the sort of place you go to
for smart, sexy, geeky women. It's more the place for luau excess,
non-literate arts, and maritime athleticism. -- applez

On Thu, 11 Nov 2010 23:09:40 +0000, Tom Anderson wrote:

> On Wed, 10 Nov 2010, Ken Wesson wrote:
> 
>> On Tue, 09 Nov 2010 23:14:14 +0000, Martin Gregorie wrote:
>>
>>> ARRAY-TOTALLING.
>>>     MOVE ZERO TO ARRAY-TOTAL. PERFORM ADD ARRAY-ELEMENT(I) TO
>>>     ARRAY-TOTAL VARYING I FROM 1 BY 1 UNTIL I > ARRAY-SIZE
>>>     END-PERFORM. MOVE ARRAY-TOTAL TO TL-VALUE. WRITE TOTAL-LINE AFTER
>>>     1.
>>
>> (def array-total (vec (take n (iterate inc 1))))
>> (def tl-value array-total)
>> (println 1)
>> (println total-line)
>>
>> is more readable than either.
> 
> Are you serious?

Of course I am.

Ah, I see. Looking at the crossposts it looks like you may be a Java 
programmer. I hear they like their code verbose. I also hear that Java is 
the COBOL of the 21st century. ;)

On Thu, 11 Nov 2010 22:38:48 +0000, Tom Anderson wrote:

> On Wed, 10 Nov 2010, Ken Wesson wrote:
> 
>> On Wed, 10 Nov 2010 12:50:33 +0000, Martin Gregorie wrote:
>>
>>> On Tue, 09 Nov 2010 18:13:34 -0800, Thomas G. Marshall wrote:
>>>
>>>> Just reading this @#$% makes me wanna cry.
>>>
>>> Sadly, there's still useful stuff that COBOL can do more concisely
>>> than other more recent languages.
>>
>> Even a Lisp with a suitable DSL?
> 
> Including the code needed to define the DSL, of course.

Fair enough, if you add the entire size of a COBOL compiler implemented 
in COBOL onto every COBOL program. ;)

On Fri, 12 Nov 2010 02:19:16 +0100, Ken Wesson wrote:

> On Thu, 11 Nov 2010 22:38:48 +0000, Tom Anderson wrote:
> 
>> On Wed, 10 Nov 2010, Ken Wesson wrote:
>> 
>>> On Wed, 10 Nov 2010 12:50:33 +0000, Martin Gregorie wrote:
>>>
>>>> On Tue, 09 Nov 2010 18:13:34 -0800, Thomas G. Marshall wrote:
>>>>
>>>>> Just reading this @#$% makes me wanna cry.
>>>>
>>>> Sadly, there's still useful stuff that COBOL can do more concisely
>>>> than other more recent languages.
>>>
>>> Even a Lisp with a suitable DSL?
>> 
>> Including the code needed to define the DSL, of course.
> 
> Fair enough, if you add the entire size of a COBOL compiler implemented
> in COBOL onto every COBOL program. ;)
>
They exist: at least one of the ICL COBOL compilers (the VME/B one) was 
written in COBOL. However, it was a semi-cheat because it ran in COIL, a 
sort of JVM optimised to execute COBOL. I assume the code it generated 
also ran in COIL but who knows: we only knew COIL existed because the 
only time I saw the compiler crash the dump said it was a COIL-machine 
dump. I never saw that from compiled COBOL, which always produced a very 
nicely formatted COBOL-specific dump.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Fri, 12 Nov 2010, Ken Wesson wrote:

> On Thu, 11 Nov 2010 23:09:40 +0000, Tom Anderson wrote:
>
>> On Wed, 10 Nov 2010, Ken Wesson wrote:
>>
>>> On Tue, 09 Nov 2010 23:14:14 +0000, Martin Gregorie wrote:
>>>
>>>> ARRAY-TOTALLING.
>>>>     MOVE ZERO TO ARRAY-TOTAL. PERFORM ADD ARRAY-ELEMENT(I) TO
>>>>     ARRAY-TOTAL VARYING I FROM 1 BY 1 UNTIL I > ARRAY-SIZE
>>>>     END-PERFORM. MOVE ARRAY-TOTAL TO TL-VALUE. WRITE TOTAL-LINE AFTER
>>>>     1.
>>>
>>> (def array-total (vec (take n (iterate inc 1))))
>>> (def tl-value array-total)
>>> (println 1)
>>> (println total-line)
>>>
>>> is more readable than either.
>>
>> Are you serious?
>
> Of course I am.
>
> Ah, I see. Looking at the crossposts it looks like you may be a Java 
> programmer. I hear they like their code verbose. I also hear that Java 
> is the COBOL of the 21st century. ;)

Statements which i cannot honestly deny.

The context i was reading your statement about readability in was 
readability to a programmer who doesn't know the language - we'd been 
having that discussion about languages which look like pseudocode. I have 
never worked with COBOL, and although i wouldn't want to read very much of 
it, i understand what the chunk above is doing. I don't know any kind of 
LISP, although i did read a LISP book about fifteen years ago, and i find 
your chunk of LISP rather impenetrable - the latter three lines are fine, 
but i don't know what vec does, nor take, nor iterate and inc, although i 
guess 'iterate inc 1' is something to do with a loop counter. Which atom 
is the name of the array?

I'm going to guess that vec is the array, and that an array can be a 
function, and that it calls its argument with each of its elements (how 
would this happen, though?), and that the argument is essentially the 
array dereferencing operator, itself bound to (curried with?) an argument 
which is a closure that supplies an incrementing count.

Which, i have to say, is not how i think about totalling lists.

tom

-- 
dream warrior, sun dancer

On Fri, 12 Nov 2010 20:53:47 +0000, Tom Anderson wrote:

> I'm going to guess that vec is the array, and that an array can be a
> function, and that it calls its argument with each of its elements (how
> would this happen, though?), and that the argument is essentially the
> array dereferencing operator, itself bound to (curried with?) an
> argument which is a closure that supplies an incrementing count.

Eh, not quite.

Actually that code produces an array of the values 1 ... n. I'm not sure 
why I posted it. I think the COBOL code is supposed to sum the array.

(def array-total (reduce + the-array))

Short'n'sweet. :)

On Sat, 13 Nov 2010 05:41:50 +0100, Ken Wesson wrote:

> Actually that code produces an array of the values 1 ... n. I'm not sure
> why I posted it. I think the COBOL code is supposed to sum the array.
>
Thats right. The WRITE statement is somewhat more complex too. If TOTAL 
line was defined like this:

01   TOTAL-LINE
 05  FILLER      PIC X(13) VALUE "Array total: ".
 05  TL-VALUE    PIC Z(6)9.99.

and ARRAY-TOTAL was, say, 12.5, the WRITE would send the character string
"\nArray total:      12.50" to the printer, assuming TOTAL-LINE is 
defined as a FILE SECTION record in a printer file definition. 

What does the Lisp look like if it totals the array and outputs a similar 
line to that shown above?


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Sat, 13 Nov 2010, Ken Wesson wrote:

> On Fri, 12 Nov 2010 20:53:47 +0000, Tom Anderson wrote:
>
>> I'm going to guess that vec is the array, and that an array can be a 
>> function, and that it calls its argument with each of its elements (how 
>> would this happen, though?), and that the argument is essentially the 
>> array dereferencing operator, itself bound to (curried with?) an 
>> argument which is a closure that supplies an incrementing count.
>
> Eh, not quite.
>
> Actually that code produces an array of the values 1 ... n. I'm not sure
> why I posted it. I think the COBOL code is supposed to sum the array.

I believe so. Perhaps your proofreading would be aided by writing in a 
more readable language? :)

> (def array-total (reduce + the-array))
>
> Short'n'sweet. :)

As long as you know what reduce does, that is indeed pretty obvious.

tom

-- 
Socialism - straight in the mainline!

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Nov 9, 4:22 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>>
>> I sympathize with the personal reaction.  Despite that, if
>> what we're interested in is an actual software engineering
>> result, a measurement of both costs and benefits should be
>> undertaken, across a full product lifecycle, and then base
>> an assessment on the measured data rather than just
>> anecdotal evidence.
>>
> You can't measure everything.

Or one might say you can't go faster than the speed of light,
but neither statement is relevant to the point I was making.

> The main benefit is that readable code
> is more maintainable.

Perhaps that is so, but until some sort of data is collected this
statement is just unsupported speculation.

> However there are far too many variables -
> experience and skill of maintaining programmer, familiarity of
> maintainer with source code, complexity of function, caffeine level of
> maintaining programmer - which will entirely swamp any signal from the
> symbol used to represent an empty loop.

Here again, unsupported speculation.  The only way to know whether
this assertion holds up is to actually measure.  Furthermore, if
actual measurements were done, and done seriously so as to try to
account for effects like the ones mentioned, and despite that the
differences were not statistically significant, that result would
still tell us something of interest.  More to the point, it would
tell us /something/, in contrast to simply giving statements of
opinion, which tells us /nothing/ beyond the fact of the opinion
being stated.

The best way to end a "religious" argument is to bring measurement
into the process.  If someone isn't willing to measure, or at
least talk about what it would take to measure, then all they want
is to keep having a non-resolvable argument, and there is little
point in either listening to them or talking to them.

"Thomas G. Marshall" <tgmforum@gmail.com> writes:

> On Nov 9, 9:31 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> James Dow Allen <jdallen2...@yahoo.com> writes:
>>
>>
>>
>> > On Nov 1, 1:59 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> >> On 11/ 1/10 12:32 AM, Richard wrote:
>> >> > James Dow Allen<gm...@jamesdowallen.nospam>  writes:
>>
>> >> >> "BGB / cr88192"<cr88...@hotmail.com>  might have writ, in
>> >> >>news:i9v341$2so$1@news.albasani.net:
>>
>> >> >>> ... some compilers will warn about unused local
>> >> >>> variables, which is personally a bit annoying.
>>
>> >> >> I once used a "language" where some unused variables, believe it or not,
>> >> >> caused Fatal Errors!!  I even complained about it on Usenet in
>> >> >> Message<90...@sun.uucp>  :
>>
>> >> >>http://groups.google.com/group/comp.unix.wizards/msg/3774732a57ef112d?
>> >> >> hl=en&dmode=source
>>
>> >> >> (People e-mailed me in response to that post, saying they'd printed
>> >> >> it and taped it to the wall!)
>>
>> >> >>> "christian.bau"<christian....@cbau.wanadoo.co.uk>  wrote:
>> >> >>>> while( *p++ = *q++ );
>>
>> >> >>>> is an idiom known to every C programmer.
>>
>> >> >> I prefer
>> >> >>      while (*p++ = *q++) {
>> >> >>      }
>>
>> >> >> James Dow Allen
>>
>> >> > Why? That's ridiculous.
>>
>> >> > The point of having no {} is that you realise that all the *serious*
>> >> > stuff is going on inside the while loop statement itself.
>>
>> >> It's a great way to confuse readers!
>>
>> > I find these objections baffling.  It's only a short slide from
>> >      while (foo) ;
>> > to
>> >      while (foo) gak;
>> > so the construction
>> >      while (foo) {
>> >      }
>> > is the clearest way *to emphasize* that the while-body is empty!
>>
>> No doubt you would agree that
>>
>>     NO_BODY:  while (foo) goto NO_BODY;
>>
>> has greater and therefore clearer emphasis that the loop body is
>> intentionally empty.  This construction is therefore absolutely
>> and undeniably the best possible way to indicate empty loop
>> bodies.  How could any reasonable person disagree?  ;)
>
>
> Yeek.  If you're gonna be gross, be less gross:
>
>         NO_BODY: if (foo) goto NO_BODY;

Using 'while' rather than 'if' was part of the joke.

On Sat, 13 Nov 2010 13:16:56 +0000, Martin Gregorie wrote:

> On Sat, 13 Nov 2010 05:41:50 +0100, Ken Wesson wrote:
> 
>> Actually that code produces an array of the values 1 ... n. I'm not
>> sure why I posted it. I think the COBOL code is supposed to sum the
>> array.
>>
> Thats right. The WRITE statement is somewhat more complex too. If TOTAL
> line was defined like this:
> 
> 01   TOTAL-LINE
>  05  FILLER      PIC X(13) VALUE "Array total: ".

Eww. COBOL so stupid it needs to be told how long string literal is. :)

>  05  TL-VALUE    PIC Z(6)9.99.
> 
> and ARRAY-TOTAL was, say, 12.5, the WRITE would send the character
> string "\nArray total:      12.50" to the printer, assuming TOTAL-LINE
> is defined as a FILE SECTION record in a printer file definition.
> 
> What does the Lisp look like if it totals the array and outputs a
> similar line to that shown above?

For a function that does this, using the Lisp in question:

(defn print-total! [arr]
  (println (format "Array total: %9.2f" (reduce + arr))))

I'm assuming your Z(6)9.99 means it should pad for six digits left of the 
decimal point and round to the nearest hundredth:

user=> (println (format "Array total: %9.2f" 1.7845))
Array total:      1.78

The 9 is the total width of the field, including the dot and two cents 
digits.

The ! in the function name is conventional for functions called for side 
effects. More ordinarily you'd have a function just return the formatted 
string and the upper part of your presentation layer would actually feed 
it to the output. Or you'd have a GUI constructor generate an "Array 
total:" label control left of an empty non-editable text box and 
something else populate the text box with data, enabling it to be 
selected and copied to the clipboard. The GUI system would be tasked with 
laying everything out appropriately. The text box would be made wide 
enough for nine characters and right justified and you'd just use "%.2f" 
in the format. Added advantage with a reasonable MVC GUI would be the 
ability to update the displayed number on the fly when things changed 
elsewhere. The Lisp in question runs on the JVM and has a Java-aware FFI 
so this can even be a Java Swing GUI.

The code was short and sweet though wasn't it? The only thing slightly 
mysterious, really, is the format specifier, and a) it's similar to what 
a C programmer would use in a printf for the same job and b) COBOLs is a 
damn sight uglier. :)

On Sat, 13 Nov 2010 13:49:02 +0000, Tom Anderson wrote:

> On Sat, 13 Nov 2010, Ken Wesson wrote:
> 
>> (def array-total (reduce + the-array))
>>
>> Short'n'sweet. :)
> 
> As long as you know what reduce does, that is indeed pretty obvious.

Some Lisps and many functional languages call it fold or foldl. It 
applies the supplied function to the first two elements of a sequence, 
then to the result and the third element, etc.; if the function is 
associative and commutative the distinction from foldr is not going to 
matter. (reduce + (reverse the-array)) gives you foldr at the cost of 
copying the array once to reverse it, so using double the memory 
(temporarily) and double the traversal overhead time (two full traversals 
instead of one). Of course depending on the operation the traversal time 
might not dominate. + would dominate with bignums in the array.

Interestingly, reverse can be defined as a reduction too: (reduce conj 
nil the-array). Conj'ing two integers won't work but the four-argument 
form uses the third argument and the first array element, then the result 
and the second, etc., and nil is treated as an empty list. (Conj is 
basically just cons with the argument order reversed, so the list comes 
first and it works with reduce and other HOFs.)

So foldl can be gotten as (reduce op (reduce conj nil the-input)).

On 11.11.2010 01:06, BartC wrote:
> "Robert Klemme" <shortcutter@googlemail.com> wrote in message
> news:8jojqhFcgkU1@mid.individual.net...
>> On 06.11.2010 10:30, Nick Keighley wrote:
>
>
>>> But if you write pseudo code like this then
>>> heaven help your collegues!
>>>
>>> ARGF.each { |line| print line if line =~ /Ruby/ }
>>
>> Well, you basically only need to know that ARGF iterates over all
>> files in
>> ARGV or reads from stdin if ARGV is empty. I think the rest is pretty
>> self explanatory, isn't it? :-)
>
> Yes, but Ruby seems to delight in these kinds of off-kilter syntaxes.
>
> For the purposes of pseudo-code, which of the following is clearer:
>
> a.each {|line| ... } # or:
>
> for each line in a { ... } # ?

In Ruby that would be

for line in a
   ...
end

:-)  Frankly, I don't see a big difference but then again: I'm biased.

> Or which of the following:
>
> 99.times do |i| ... end # (and what's the first i value, 0 or 1?) or:

99.times iterates from 0 to 98 (including).

> for i =1 to 99 do ... end # (or any of countless variations)?

Again, in Ruby

for i in 0..98
   ...
end

or with a half open interval

for i in 0...99
   ...
end

0.upto 98 do |i|
   ...
end

but I'm digressing.  Still, I find all those pretty readable - at least 
for someone who knows English.

> It seems that once this way of using an iterator (or generator or whatever
> it is) became available, then every program must make use of it at every
> opportunity ...

Well, it's just the standard idiom in the same way as java.util.Iterator 
dictates the standard iteration idiom in Java.  But nobody forces you to 
use it.  Conversely I have seen numerous times people iterate through 
java.util.List with get(int) (let's not debate efficiency in case of 
LinkedList - that's a different story).

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

On Sun, 14 Nov 2010 08:12:19 +0100, Ken Wesson wrote:

> On Sat, 13 Nov 2010 13:16:56 +0000, Martin Gregorie wrote:
> 
>> Thats right. The WRITE statement is somewhat more complex too. If TOTAL
>> line was defined like this:
>> 
>> 01   TOTAL-LINE
>>  05  FILLER      PIC X(13) VALUE "Array total: ".
> 
> Eww. COBOL so stupid it needs to be told how long string literal is. :)
>
COBOL is designed around fixed length fields. Don't forget, its name is 
an acronym: Common Business Oriented Language. This style of print 
formatting is somewhat OTT for simple print lines like this one, but 
works rather well for complex multi-column reports on plain paper and 
statements or invoices that are output on pre-printed paper.

>> What does the Lisp look like if it totals the array and outputs a
>> similar line to that shown above?
> 
> For a function that does this, using the Lisp in question:
> 
> (defn print-total! [arr]
>   (println (format "Array total: %9.2f" (reduce + arr))))
>
Neat.
 
> I'm assuming your Z(6)9.99 means it should pad for six digits left of
> the decimal point and round to the nearest hundredth:
>
Correct.
 
> The code was short and sweet though wasn't it? The only thing slightly
> mysterious, really, is the format specifier, and a) it's similar to what
> a C programmer would use in a printf for the same job and b) COBOLs is a
> damn sight uglier. :)
>
Sure, though the more complex number formats may be easier in COBOL, e.g.

 PIC $,$$$,$$9.99BDB BLANK WHEN ZERO   

which would output a debit of 5 cents as "        $0.05 DB", leave a zero 
amount as entirely blank and output a price of fifteen hundred dollars 
and 23 cents as "    1,500.23   " as the result of MOVEing a value to the 
field.
 
IMO most of COBOL's misfeatures are the result of the original language 
design committee's assumption that: 
- there exist a bunch of programmers who can understand all the
  implications of a MOVE statement while being incapable of
  understanding an assignment statement. The implications of MOVE are 
  non-trivial: MOVE will convert the content almost any source field to
  match almost any destination field and this includes moving group
  fields whose components may be of mixed types and different lengths
  from the source.

- that these programmers can deal with complex logic expressed in almost
  English but are mathematical illiterates. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On November 14, 2010 07:50, in comp.lang.c, martin@address-in-sig.invalid
wrote:
<snip>
> IMO most of COBOL's misfeatures are the result of the original language
> design committee's assumption that:
> - there exist a bunch of programmers who can understand all the
>   implications of a MOVE statement while being incapable of
>   understanding an assignment statement. The implications of MOVE are
>   non-trivial: MOVE will convert the content almost any source field to
>   match almost any destination field and this includes moving group
>   fields whose components may be of mixed types and different lengths
>   from the source.
> 
> - that these programmers can deal with complex logic expressed in almost
>   English but are mathematical illiterates.

You forget that, at the time that COBOL was first proposed and
standardized, "programmers" were either "Computer Scientists", or they were
code monkeys.

COBOL was not designed for the /programmer's/ understanding; it was designed
so that /accountants/ could specify and follow the business logic.

  Analyst: So, tell me how you calculate the final price of an item, given
           it's price and the local sales tax expressed as a percentage of
           price.

  Accountant: I multiply the price by the percentage, which gives me the tax
              amount. I then add the tax amount to the price, which gives me
              the final price.

  Analyst:  Programmer, input this...
               MULTIPLY PRICE BY PERCENTAGE GIVING TAX-AMOUNT.
               ADD PRICE, TAX-AMOUNT GIVING FINAL-PRICE. 
  ad nauseum
-- 
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
----------      Slackware - Because I know what I'm doing.         ------

Martin Gregorie wrote:
>> 01   TOTAL-LINE
>>   05  FILLER      PIC X(13) VALUE "Array total: ".

Ken Wesson wrote:
> Eww. COBOL so stupid it needs to be told how long [a] string literal is. :)

So SQL is stupid, too.

-- 
Lew

On Sun, 14 Nov 2010 13:14:16 -0500, Lew Pitcher wrote:

> 
> You forget that, at the time that COBOL was first proposed and
> standardized, "programmers" were either "Computer Scientists", or they
> were code monkeys.
>
> COBOL was not designed for the /programmer's/ understanding; it was
> designed so that /accountants/ could specify and follow the business
> logic.
>
At the time COBOL was designed the majority of commercial programmers 
were writing assembler - a task that required rather more in-depth 
understanding of the target machine that a code monkey has. I'd also 
dispute that there many computer scientists around at the time: 
University computers mainly belonged to the departments of mathematics, 
sciences and engineering - and most of them wrote Fortran or Algol 60.

As I said - designing a language for those who supposedly could 
understand English but not logic or basic maths was a mistake since 
nobody but the programmers are going to look at the code. Accountants 
certainly won't and a high proportion of systems analysts back in the day 
wouldn't look at code either: I worked with enough who wouldn't even 
visit the programming office.
 
 
-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Sun, 14 Nov 2010 12:50:57 +0000, Martin Gregorie wrote:

> On Sun, 14 Nov 2010 08:12:19 +0100, Ken Wesson wrote:
> 
>> On Sat, 13 Nov 2010 13:16:56 +0000, Martin Gregorie wrote:
>> 
>>> Thats right. The WRITE statement is somewhat more complex too. If
>>> TOTAL line was defined like this:
>>> 
>>> 01   TOTAL-LINE
>>>  05  FILLER      PIC X(13) VALUE "Array total: ".
>> 
>> Eww. COBOL so stupid it needs to be told how long string literal is. :)
>>
> COBOL is designed around fixed length fields. Don't forget, its name is
> an acronym: Common Business Oriented Language.

And all along I'd thought it was COBOL: Broken Old Language. I guess the 
stuffed shirts that thought it up didn't even realize that acronymic 
language names and the like are supposed to start with themselves, like 
GNU (Gnu's Not Unix).

> Sure, though the more complex number formats may be easier in COBOL,
> e.g.
> 
>  PIC $,$$$,$$9.99BDB BLANK WHEN ZERO
> 
> which would output a debit of 5 cents as "        $0.05 DB", leave a
> zero amount as entirely blank and output a price of fifteen hundred
> dollars and 23 cents as "    1,500.23   " as the result of MOVEing a
> value to the field.
>  
> IMO most of COBOL's misfeatures are the result of the original language
> design committee's assumption that:
> - there exist a bunch of programmers who can understand all the
>   implications of a MOVE statement while being incapable of
>   understanding an assignment statement. The implications of MOVE are
>   non-trivial: MOVE will convert the content almost any source field to
>   match almost any destination field and this includes moving group
>   fields whose components may be of mixed types and different lengths
>   from the source.
> 
> - that these programmers can deal with complex logic expressed in almost
>   English but are mathematical illiterates.

It sounds like COBOL really, really was basically "BASIC for guys that 
wear suits and ties". (BASIC being another non-recursive acronymic 
language name: Beginner's All-purpose Symbolic Instruction Code. 
Coincidence?)

It also sounds like COBOL's sole significant advantages are convenient 
currency datatypes and a bunch of fancy string-formatting capabilities -- 
the sort of thing easily added to any decent HLL as a library. ;)

On Sun, 14 Nov 2010 13:20:10 -0500, Lew wrote:

> Martin Gregorie wrote:
>>> 01   TOTAL-LINE
>>>   05  FILLER      PIC X(13) VALUE "Array total: ".
> 
> Ken Wesson wrote:
>> Eww. COBOL so stupid it needs to be told how long [a] string literal
>> is. :)
> 
> So SQL is stupid, too.

Certainly is, but then, it doesn't have pretensions to be a Turing-
complete general purpose application programming language, just a domain-
specific language used to talk to databases.

On 24-10-2010 20:33, Martin Gregorie wrote:
> On Sun, 24 Oct 2010 14:53:40 -0400, Arne Vajhøj wrote:
>
>> On 24-10-2010 08:03, Martin Gregorie wrote:
>>> On Sat, 23 Oct 2010 22:15:27 -0400, Arne Vajhøj wrote:
>>>
>>>> On 22-10-2010 14:46, markspace wrote:
>>>>> On 10/22/2010 11:12 AM, BGB / cr88192 wrote:
>>>>>> probably, but OTOH, MS has different guidelines for C#, and C and
>>>>>> C++ tend
>>>>>> to use slightly other conventions as well...
>>>>>
>>>>> And MS meas what to C or C++? They implement a compiler, they don't
>>>>> issue the standard. If IEEE or ANSI published standards for C coding,
>>>>> I'd say we should follow them. It happens that they don't (AFAIK), so
>>>>> coding standards tend to be wild west style.
>>>>
>>>> If you do serious Win32 API/MFC/ALT programming, then you better stick
>>>> to MS coding convention.
>>>>
>>>> A lot of that stuff goes way beyond the C and C++ standards and are
>>>> truly MS land.
>>>>
>>> Agreed. I dislike their so-called Hungarian notation intensely. I find
>>> that jumble of crap at the front, e.g. psaGetValues(), obscures the
>>> name and, worse, if refactoring a design requires you to change the
>>> type of a variable or the return value from a function you have to
>>> change its name as well!
>>
>> I don't like it either.
>>
>> But for good and for worse that is what MS unmanaged C/C++ developers
>> has to live with.
>>
> Indeed, but its yet another reason I don't write code in that environment.
>
> BTW, what do you make of this situation: at the start of a major project
> in which there was a project manager, a technical manager and I was the
> design authority and C was the programming language, and my design and
> project-specific infrastructure specifications (e.g. a set of common
> supporting libraries to handle intra-process connections and an active
> data dictionary used to transform a set on incoming data formats to
> common internal formats) had been signed off, the TM wrote a spec.
> mandating K&R naming and coding standards and went off on leave for two
> weeks.
>
> Meanwhile two of us got stuck in and wrote and tested the supporting
> libraries to the standards that he'd released.
>
> At this point the TM returned, tore up his original coding standards and
> re-issued them mandating 'Hungarian notation'. His next action was to
> tell me that the support libraries must be rewritten in hungarian
> notation.
>
> By now the rest of the programmers were on board and we had a challenging
> deadline to meet, so I told him to get stuffed and was able to make this
> stick due to looming deadlines. All the code I wrote both then and
> subsequently (under even tighter deadlines) adhered to the original
> standards.
>
> I maintain he was right out order changing his issued standards so
> radically. What do you guys think?

Obviously convention should not be changed after initial phase
of project.

Arne

On 24-10-2010 19:30, BGB / cr88192 wrote:
> "Arne Vajh�j"<arne@vajhoej.dk>  wrote in message
> news:4cc48c64$0$23764$14726298@news.sunsite.dk...
>> On 23-10-2010 23:40, BGB / cr88192 wrote:
>>> "Arne Vajh�j"<arne@vajhoej.dk>   wrote in message
>>> news:4cc3963a$0$23751$14726298@news.sunsite.dk...
>>>> On 22-10-2010 14:12, BGB / cr88192 wrote:
>>>>> probably, but OTOH, MS has different guidelines for C#, and C and C++
>>>>> tend
>>>>> to use slightly other conventions as well...
>>>>>
>>>>> in all cases though, most of these conventions are immaterial.
>>>>>
>>>>> the compiler doesn't care, and there is little reason people should
>>>>> care
>>>>> either, since a human is smarter and more flexible than a compiler,
>>>>> people
>>>>> should presumably act as such...
>>>>>
>>>>> what weight do they hold, as they are basically just statements of
>>>>> preferences by some party, rather than being based strictly on what is
>>>>> most
>>>>> practical or convinient, or being imposed by a limitation of the
>>>>> technology,
>>>>> or similar...
>>>>
>>>> Maybe you should read a tutorial.
>>>>
>>>> In most cases coding conventions do not claim that the choice
>>>> is better or more logical than any other convention.
>>>>
>>>> The main point in coding convention is consistency.
>>>>
>>>> You pick a convention and stick to it.
>>>>
>>>
>>> and, in the name of consistency, one can stick to the existing
>>> practices...
>>>
>>> now, if one goes and looks at the Apache class library, one will see that
>>> they don't exactly strictly follow the style conventions in the tutorial
>>> either...
>>
>> Apache projects require the code to follow their specified
>> coding standard.
>>
>> Some Apache projects follow the standard Java coding standard
>> completely.
>>
>> Some of them follow it with a few changes. The most common change
>> is the location of the {.
>
> yes, but it is not the exact same convention from the link elsewhere in the
> thread, which sort of invalidates the whole "one true convention" argument,
> in favor of a "code in this project should use 'this' particular
> convention"...

They either use that link or define their standard as delta
from that.

It can almost not do more to recognize that link as THE standard.

Arne