«

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

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

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

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


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

It is not easy but one should do it.

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

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

An IDE with refactoring capability can do that safely.

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

Arne

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

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

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

Arne

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

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

Arne

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

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

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

Arne

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

Another idiom you may encounter for empty loop bodies is

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

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

--
Eric Sosman
lid

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

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

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

--
Eric Sosman
lid

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

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

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

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

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

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


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

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

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

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


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


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

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


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

or such...

"Arne Vajhøj" <> wrote in message
news:4cc0f247$0$23765$...
> On 21-10-2010 15:55, BGB / cr88192 wrote:
>> "markspace"<> 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...