Board index » cppbuilder » Re: programming style

Re: programming style


2005-03-06 10:37:41 PM
cppbuilder66
Rudy Velthuis [TeamB] wrote:
Quote
Why? One of the great advantages of a (C/C++/Java/C#-style) for loop is
that you have all the looping conditions in one place, whereas with
while, you have them all over the place, which is IMO much more error
prone.
Using while loops one can find a loop invariant and prove that
an algoritm is correct. This is not possible with for loops.
I once stated that already in one of these groups.
tinyurl.com/4k5sz
Then after that I contacted my old teacher and he
stated that one needed to know the implementation of
the language when incrementing the loop counter.
And after that when one could construct a while loop from
the for loop.
For those who can read Dutch his reply:
<quote>
Beste Hans,
Ik heb inderdaad een aantal jaren kkp gegeven en mogelijk is dat
citaat inderdaad van mij. Punt van for-loops in een de meeste
programmeertalen is dat onduidelijk is wanneer de loop-teller
van waarde verandert. In de for-lus van pascal
for i=1 to n
do begin
a ; b ;
end
of in java
for (int i=0 ; i < 10 ; i++) {
a ; b ;
}
is dit niet direct duidelijk. Je hebt de definitie van de taal nodig
om dit te achterhalen. Als je weet dat in beide gevallen de teller
aan het eind van de herhalingsstatements wordt opgehoogd kun je de
for-lus in een while omschrijven en is dit punt duidelijk.
Ander punt is dat in het algemeen niet duidelijk is of de teller-variabele
na de herhaling nog een waarde heeft.
In java is die integer i weer weg, in pascal is de integer i na afloop
nog wel beschikbaar maar is onduidelijk wat zijn waarde is.
Dit maakt het lastig om een eindbewering van de herhaling op te stellen
omdat je feitelijk niet meer van die herhalingsvariabele mag uitgaan.
Al met al dus lastig als je niet goed op de hoogte bent van de eigenschappen
van de for-lus in de betreffende programmeertaal...maar niet onmogelijk
en in elk geval met wat eigen formele toevoegingen wel te doen.
Zo kun je in Java voor de formeliteit aannemen dat na de for-lus
de (volgens de scoperegels niet meer bestaande) i de waarde 10
zal hebben (nl. not (i <10) and (0<= i <= 10)
(laatste is onderdeel van de invariant)).
Overigens aardig om nog eens iets van een oud-student te horen.
</quote>
For some info about 'Program Correctness using Induction':
tinyurl.com/38399
Hans.
 
 

Re:Re: programming style

J Alexander wrote:
Quote
This is the most irrelevant to the quality of code. And as usual the most
irrelevant stuff is often also the most hotly debated.
There is no debate let even a hot one here. There was a question
of the OP and he got some answers. That's all.
Quote
Get a copy of Sutter&Alexandrescu book about coding standards. This topic is
in Chapter 0, which discusses things that are a mater of individual taste.
Ah.. Did you read it ? Do you read complete books about things "most
irrelevant to the quality of code" ? Or a chapter ?
Nice.
Hans.
 

Re:Re: programming style

Hans Galema wrote:
Quote
Rudy Velthuis [TeamB] wrote:

>Why? One of the great advantages of a (C/C++/Java/C#-style) for
>loop is that you have all the looping conditions in one place,
>whereas with while, you have them all over the place, which is IMO
>much more error prone.

Using while loops one can find a loop invariant and prove that
an algoritm is correct. This is not possible with for loops.

I once stated that already in one of these groups.
tinyurl.com/4k5sz

Then after that I contacted my old teacher and he
stated that one needed to know the implementation of
the language when incrementing the loop counter.
And after that when one could construct a while loop from
the for loop.

For those who can read Dutch his reply:
<quote>
Punt van for-loops in een de meeste
programmeertalen is dat onduidelijk is wanneer de loop-teller
van waarde verandert. In de for-lus van pascal
"Point of for-loops is that in most programming languages, it is not
clear whan the for-loop variable changes its value. in the for-loop of
Pascal"
Quote
for i=1 to n
do begin
a ; b ;
end

of in java
"or in Java"

for (int i=0 ; i < 10 ; i++) {
a ; b ;
}
is dit niet direct duidelijk. Je hebt de definitie van de taal nodig
om dit te achterhalen.
"This is not immediately clear. You need the definition of the language
to find out."
Well, I would hope that someone programming is actually aware of the
definition of the language.
Quote
Ander punt is dat in het algemeen niet duidelijk is of de
teller-variabele na de herhaling nog een waarde heeft.
"Another point is that it is generally not clear whether the for-loop
variable still has a value after the repetition."
If you need that, you use while, but otherwise you can use a for loop.
It is often irrelevant, so I don't see this as a reason to generally
use while loops instead of for loops.
Quote
In java is die integer i weer weg, in pascal is de integer i na afloop
nog wel beschikbaar maar is onduidelijk wat zijn waarde is.
Dit maakt het lastig om een eindbewering van de herhaling op te
stellen omdat je feitelijk niet meer van die herhalingsvariabele mag
uitgaan.
"In Java, the Integer is gone, in Pascal the integer is still
available, but it is unclear what its value is. This makes it hard to
make a final statement about the loop (?) since you can't assume (the
value of) the loop variable anymore."
Your teacher forgot that if you don't declare the int in the for loop,
it is quite clear which value it will have. After all, this is well
described in the language documentation.
And how often does one need the value? For the rare cases where it is
really not celar, and you need it, use while.
Quote
Al met al dus lastig als je niet goed op de hoogte bent van
de eigenschappen van de for-lus in de betreffende
programmeertaal...
"All in all a problem if you are not aware of the properties of the for
loop in the programming language at hand."
<snip>
Quote
For some info about 'Program Correctness using Induction':

tinyurl.com/38399
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"There's many a bestseller that could have been prevented by a good
teacher." -- Flannery O'Connor (1925-1964)
 

{smallsort}

Re:Re: programming style

As an old programmer told me years ago: Code is written once to be read many times.
Surely making the reading job harder or easier has a big impact on the productivity
of people who do maintenance and debugging.
J Alexander wrote:
Quote
This is the most irrelevant to the quality of code. And as usual the most
irrelevant stuff is often also the most hotly debated.
Get a copy of Sutter&Alexandrescu book about coding standards. This topic is
in Chapter 0, which discusses things that are a mater of individual taste.
 

Re:Re: programming style

Jonathan Benedicto wrote:
Quote
void __fastcall TMyClass::MyMethod(AnsiString x, int i)
I prefer to leave a space between '(' and the first argument. That
allows me to use the [tab] key to align the next argument underneath.
I also like putting items on new lines to make them stand out or to
create more space.
struct MyStruct
{
int x,
y,
z;
};
enum TMyEnum { meOne,
meTwo,
meEtc };
void __fastcall TMyClass
::MyMethod( AnsiString x,
int i )
{
if( x==0 )
{
}
else
{
}
try
{
}catch( Exception & E )
{
}
for( int t=i;
t<x.Length();
t++)
{
// Hope this is readable.
}
}
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: programming style

Vladimir Stefanovic wrote:
Quote
>Learning how to code the most popular way would help
>enormously when a team starts work on a project. However,
>I prefer using the Tab key instead of hitting space 3 times.

Me too, but there was some reason not to use '\t' which I cannot
remember - could be something with draft printing.
You can tell the IDE not to use TAB characters.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: programming style

One advantage under Borland IDEs is that it allows you to indent the
line below to line up with the first argument. Using smart tab the
cursor will jump from the function name to the first argument:
In the example below '!' is where the cursor is positioned after
hitting [return] then [tab] twice.
void wibble( char * fred );
! ! !
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: programming style

Ed Mulroy [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
[...]
If it has enough enum values to line wrap I prefer it to be formatted
much as a structure declaration is done. Using your brace style that
might be something like this:

enum TMyEnum {
meOne,
meTwo,
meThree,
meFour,
meFive,
meEtc
};
One thing I slowly started to do during the
last years, is to put the commas /before/
the identifiers in these cases:
enum TMyEnum { meOne
, meTwo
, meThree
, meFour
, meFive
, meEtc
};
The same goes for other lists:
bool result = callSomeFunc( someLongArg
, someOtherFunc(someOtherArg)
, yetAnotherArg );
struct SomeStruct {
SomeStruct( int someV
, long someOtherV
, bool yetAnotherV )
: someValue(someV)
, someOtherValue(someOtherV)
, yetAnotherValue(yetAnotherV)
{
}
int someValue;
long someOtherValue;
bool yetAnotherValue;
};
The advantage of this is that you can more easily
add/remove/comment lines:
struct SomeStruct {
SomeStruct( int someV
// , long someOtherV
, bool yetAnotherV )
: someValue(someV)
// , someOtherValue(someOtherV)
, yetAnotherValue(yetAnotherV)
{
}
int someValue;
// long someOtherValue;
bool yetAnotherValue;
};
Quote
. Ed
[...]
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: programming style

Quote
One thing I slowly started to do during the
last years, is to put the commas /before/
the identifiers in these cases:
I think that is unique to your code. If the comma is before the name
then the situation where a comma is missing moves from after the last
item to before the first. The increased ease of adding and removing
comments is interesting.
As you can see from code I have posted on here, my brace and indent
style resembles yours.
enum TMyEnum
{
meOne,
meTwo,
meThree,
meFour,
meFive,
meEtc
};
But for newsgroup messages I often indent with 4 spaces instead of the
2 I use in my code because news reader fonts typically show spaces as
very small.
. Ed
"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
Quote
Ed Mulroy [TeamB] < XXXX@XXXXX.COM >wrote:
>[...]
>If it has enough enum values to line wrap I prefer it to be
>formatted
>much as a structure declaration is done. Using your brace style
>that
>might be something like this:
>
>enum TMyEnum {
>meOne,
>meTwo,
>meThree,
>meFour,
>meFive,
>meEtc
>};

One thing I slowly started to do during the
last years, is to put the commas /before/
the identifiers in these cases:

enum TMyEnum { meOne
, meTwo
, meThree
, meFour
, meFive
, meEtc
};

The same goes for other lists:

bool result = callSomeFunc( someLongArg
, someOtherFunc(someOtherArg)
, yetAnotherArg );

struct SomeStruct {
SomeStruct( int someV
, long someOtherV
, bool yetAnotherV )
: someValue(someV)
, someOtherValue(someOtherV)
, yetAnotherValue(yetAnotherV)
{
}

int someValue;
long someOtherValue;
bool yetAnotherValue;
};

The advantage of this is that you can more easily
add/remove/comment lines:

struct SomeStruct {
SomeStruct( int someV
// , long someOtherV
, bool yetAnotherV )
: someValue(someV)
// , someOtherValue(someOtherV)
, yetAnotherValue(yetAnotherV)
{
}

int someValue;
// long someOtherValue;
bool yetAnotherValue;
};

>. Ed
>[...]
 

Re:Re: programming style

Ed Mulroy [TeamB] wrote:
Quote
I think that is unique to your code.
Actually, I have been doing this for around 5 years now <g>
Quote
If the comma is before the name then the situation where a comma is
missing moves from after the last item to before the first. The
increased ease of adding and removing comments is interesting.
Yes, when I tried justifying the gain I found the argument pretty minor
- it is only really significant for the last row. In practice I found
I extended lists often enough for this to be a benefit.
I also quite like the braces and commas lining up - it draws my eye
down the page in a way I find helps me take the information in more
quickly. However, I think research shows that tricks that work well
for one reader are often not applicable for others, so it is not
something I push.
Quote
As you can see from code I have posted on here, my brace and indent
style resembles yours.

enum TMyEnum
{
meOne,
meTwo,
meThree,
meFour,
meFive,
meEtc
};
This one should work just as well, favouring front insertion over back
insertion. So Schobi and I like queues, you appear more stack-based ;?)
However, I really don't like this format for declaring functions - too
many lines lost at the top. But so much of this conversation is
personal taste.
AlisdairM(TeamB)
 

Re:Re: programming style

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
Idle curiousity driven side question:

Do you do

ret_type FuncName(NameOfType * & var_name)
or
ret_type FuncName(NameOfType *& var_name)
The second. It's still pretty clear that the *& is not part of the
identifier.
Quote
Other side question, what font size and screen size do you use?
My screen size is 1600x1200 and the font size, well, I had to bump it
up to 14 I think. But Jody's screen at the time this decision was
made was using 8pt fonts at I think the same res.
Quote
Looking at that now I have to admit that, depening upon the previous
character, the '&' might be better with a space to its left.
I like this approach not only for visual readabiliy, but because it
nicely sits on the fence betwen both religious sides of the issue. It
draws little heat from either group... since it's not endorsing their
opposing group's view.
--
Chris (TeamB);
 

Re:Re: programming style

"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
Quote
I use a prefix like 'T' to distinguish the type from the instance:

TMyClass MyClass;

That way both the type and the instance can have a descriptive name eg:

TCodeFormatter CodeFormatter;
CodeFormatter.Format( "unreadable.cpp" );

instead of :

CodeFormatter TheCodeFormatter;
I understand this but why use T? We normally use something similar
but different enough to indicate that it's not a Borland class (derived
from TObject). It just seems to defeat the purpose, especially when you
have multiple suppliers like TString, QString whatever...
 

Re:Re: programming style

Randall Parker wrote:
Quote
Vladimir,

I could have joined your team with little or no change to my current
coding style. About the only thing I do differently is not putting the
blanks in the printf example you show first.
Yeah, but do you snip quotes? <g>
.a
 

Re:Re: programming style

"Duane Hebert" wrote:
Quote
I understand this but why use T? We normally use something similar
but different enough to indicate that it's not a Borland class (derived
from TObject). It just seems to defeat the purpose, especially when you
have multiple suppliers like TString, QString whatever...
T is just an old habit from my VLC days. It makes it very clear for me it is
a Type ;-). To mark my own components I put an identifier between the T and
the classname:
TmyObjectFactory ObjectFactory;
A lot of third-party VCL component suppliers do the same: TkbmMemtable or
FastReport's TfrDesigner.
And in C++ we have namespaces. I always write std::string.
Peter
 

Re:Re: programming style

Quote
My preference is "None of the above."

TMyClass * mc;
The down side to this is that it is ambiguous whether it is a variable
declaration or a multiplication. In C, of course, it doesn't matter because
x * y;
would be optimized out as a no-op.
but in C++
x * y;
may actually perform some use because the * operator may be overloaded.
in your example TMyClass is obviously a type, so the ambiguity is not
severe, but I just thought I'd point it out.
Regards,