Stylistic note on loops
markspace
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?
Lew
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
bcr666
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 "-".
Fred
It is suspicious that you start the loop at the second character
(i=1). This will likely cause problems when s is empty or the first
character is not a letter.
--
Fred K
Tom McGlynn
> 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.
>
> Any thoughts on how to format this? Would 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=1; i<s.length() && Character.isLetter(s.charAt(i)); i += 1)
{
}
This I would prefer to see as:
for (i=1; i<s.length(); i += 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
BGB / cr88192
"markspace" <nos...@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...
markspace
> 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;
}
Lew
> 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.
> 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"?
> 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:
>> int i = 1;
>> while( Character.isLetter( s.charAt( i ) ) ) {
>> i++;
>> }
>
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 sanity
> (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 (most
>
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
Patricia Shanahan
> 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
Arne Vajhøj
I would go for the while loop in this case.
It is logically a while operation and not a for operation.
Arne
BGB / cr88192
"Lew" <l...@lewscanon.com> wrote in message
news:68aa61a9-5999-410a...@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.
Lew
>> <--
>> 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
Lew
> 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
Lew
> r...@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
BGB / cr88192
"Lew" <no...@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.
Arne Vajhøj
> 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
Eric Sosman
> 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
eso...@ieee-dot-org.invalid
Arne Vajhøj
>> 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
> 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
Arne Vajhøj
> Arne Vajhøj<ar...@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>
>
> »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
Arne Vajhøj
> Patricia Shanahan<pa...@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.
>
>
>> 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".
>
> 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
Arne Vajhøj
> r...@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
Eric Sosman
> [...]
> 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
eso...@ieee-dot-org.invalid
Patricia Shanahan
...
> 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
Eric Sosman
> [...]
> In C, to skip two space-separated integral numerals
> (under certain circumstances):
>
> while( isnum( *++c )); while( isspace( *++c )); while( isnum( *++c ));
>
... 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
eso...@ieee-dot-org.invalid
ClassCastException
> 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);
}
BGB / cr88192
"Arne Vajhøj" <ar...@vajhoej.dk> wrote in message
news:4cc0f389$0$23764$1472...@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...
BGB / cr88192
> On 21-10-2010 15:55, BGB / cr88192 wrote:
>> "markspace"<nos...@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...
BGB / cr88192
"Eric Sosman" <eso...@ieee-dot-org.invalid> wrote in message
news:i9r03t$ppg$1...@news.eternal-september.org...
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.
Eric Sosman
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
eso...@ieee-dot-org.invalid
BGB / cr88192
"Arne Vajh�j" <ar...@vajhoej.dk> wrote in message
news:4cc0f4a3$0$23764$1472...@news.sunsite.dk...
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...
markspace
> 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.
markspace
> "Arne Vajh�j"<ar...@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. ;)
markspace
> 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.
Arne Vajhøj
> "Arne Vajh�j"<ar...@vajhoej.dk> wrote in message
> news:4cc0f389$0$23764$1472...@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
BGB / cr88192
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...
markspace
> 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.
BGB / cr88192
> On 10/21/2010 11:48 PM, BGB / cr88192 wrote:
>
>> "Arne Vajh�j"<ar...@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...).
Arne Vajhøj
> Arne Vajh�j<ar...@vajhoej.dk> writes:
>> The cost of the ending period being removed is approx. zero
>
>
> �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
ClassCastException
> 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.
Tom Anderson
> 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
Tom Anderson
> 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 Anderson
> Arne Vajh?j <ar...@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
christian.bau
> 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.
BGB / cr88192
"Tom Anderson" <tw...@urchin.earth.li> wrote in message
news:alpine.DEB.1.10.1...@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...
BGB / cr88192
"christian.bau" <christ...@cbau.wanadoo.co.uk> wrote in message
news:493ce92e-97c0-47e2...@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.
markspace
> 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.
Arne Vajhøj
> 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
Arne Vajhøj
> 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
Arne Vajhøj
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
Arne Vajhøj
> "Lew"<l...@lewscanon.com> wrote in message
> news:68aa61a9-5999-410a...@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
Arne Vajhøj
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
Arne Vajhøj
> 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
Arne Vajhøj
>>>> 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
Arne Vajhøj
> "markspace"<nos...@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"<ar...@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
BGB / cr88192
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.
Robert Klemme
> 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/
Martin Gregorie
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 |
Martin Gregorie
> 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.
Eric Sosman
>
> 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
eso...@ieee-dot-org.invalid
markspace
> 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.
BGB / cr88192
"Martin Gregorie" <mar...@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...
Arne Vajhøj
> 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
Arne Vajhøj
Or the next maintainer will miss something critical, because
he assumed that everything was written in a certain style.
Arne
Arne Vajhøj
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
BGB / cr88192
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, ...
Martin Gregorie
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?
Jim Janney
> 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
Leif Roar Moldskred
>
> 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
Lew
>> NB: [sic] 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
>
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 = null; // emphasize that algorithm depends on
initial 'null' state
private boolean condn = 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
Arne Vajhøj
> On Mon, 25 Oct 2010, Jim Janney wrote:
>
>> Tom Anderson <tw...@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 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.
>
> 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
ClassCastException
Nah. The trouble with tabs is that tabs very obviously should always be
exactly 8 spaces, but 8 is way too deep an indent. ;-)
Scouser
news:loops-2010...@ram.dialup.fu-berlin.de...
> Eric Sosman <eso...@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
James Dow Allen
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" <christ...@cbau.wanadoo.co.uk> wrote:
>> while( *p++ = *q++ );
>>
>> is an idiom known to every C programmer.
I prefer
while (*p++ = *q++) {
}
James Dow Allen
Richard
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.
Malcolm McLean
> "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.
Ian Collins
It's a great way to confuse readers!
--
Ian Collins
Donkey Hottie
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.
Sherm Pendley
> 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
Ian Collins
> Ian Collins<ian-...@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!
>
> 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?
--
Ian Collins
superpollo
and what if sometime in the future you need to meat up a bit the body of
the loop?
bye
Ian Collins
You add some. I don't see the relevance of the question.
--
Ian Collins
superpollo
if braces are already there, then you have to type less... :-)
bye
Keith Thompson
One possible alternative is:
while (*p++ = *q++) {
/* nothing */
}
Another is:
while (*p++ = *q++) {
continue;
}
--
Keith Thompson (The_Other_Keith) ks...@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"
ClassCastException
YAGNI!
Malcolm McLean
>
> 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" */ }
>
character of some sort and * comment * is the comment syntax, and the
program consists of two printing statements.
Malcolm McLean
> 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.
Richard
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
Malcolm McLean
> 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'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.
James Dow Allen
> On 11/ 1/10 12:32 AM, Richard wrote:
> > James Dow Allen<gm...@jamesdowallen.nospam> writes:
>
> >>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!)
>
> >>>> 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!
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