473,326 Members | 2,128 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Coding style survey

Which do you think is best?

1.
a) type* p;
b) type *p;

2.
a) return (var);
b) return(var);
c) return var;

3.
a) return (ptr->var);
b) return(ptr->var);
c) return ptr->var;

4.
a) return (foo(ptr->var));
b) return(foo(ptr->var));
c) return foo(ptr->var);

5.
a) a = (b+c);
b) a=(b+c);
c) a = b+c;
d) a=b+c;

6.
a)
type foo(type arg1, type arg2, ...) {
declarations;
code;
return;
}
b)
type foo(type arg1, type arg2, ...) {
declarations;

code;

return;
}
c)
type foo(type arg1, type arg2, ...)
{
declarations;
code;
return;
}
d)
type foo(type arg1, type arg2, ...)
{
declarations;

code;

return;
}
e)
type foo(type arg1, type arg2, ...)
{
declarations;
code;
return;
}
f)
type foo(type arg1, type arg2, ...)
{
declarations;

code;

return;
}

Nov 14 '05
63 3427

On Thu, 29 Jan 2004, Old Wolf wrote:
[Arthur wrote:]
char c, *p, q, *x;

or whatever it really was; I'm not going to take the time to look
back right now. I maintain that this is a Bad Idea.
What do you think of
char , *p[], q(), *x;
then? :)


Slightly better, in that the compiler will refuse to compile it,
rather than let it sit on your disk misleading future programmers. :)

Recently I wrote some code like:

const unsigned char s[] = {
foo(1),
foo(2),
/* ... (about 10 entries) */
}, *ps = s;

so that later on I could iterate with ps, or use the results
from the functioncalls in many places. Using this syntax
avoided having to type out "const unsigned char" twice (or use typedef)


Ooh, dear, typing 'const unsigned char' twice! ;-) Anyway, this
sort of thing is one of very few exceptions to the general rule.
I have seen and appreciated the idiom

typedef struct foo { bar blah; } foo, *pfoo;

even though I would obviously prefer to write

typedef struct foo foo;
typedef foo *pfoo;
struct foo { bar blah; };

in such situations, if they ever arose in my own code. And it's
possible to get borderline cases like the one you describe, even
in real code. But I'd still write

const unsigned char s[] = {
foo(1),
foo(2),
/* ... (about 10 entries) */
};
const unsigned char *ps = s;

in code meant for human consumption. The extra 'const unsigned char'
is quick to code, in an editor with cut-and-paste; and if you are
seriously concerned that 'unsigned char' may change in future versions,
you should be using a typedef anyway.

-Arthur
Nov 14 '05 #51
"Arthur J. O'Dwyer" wrote:
.... snip ...
... I myself religiously avoid returning struct
types by value, and I also rarely 'const'ify anything anyway
(preferring to #define CONSTANT if it's never going to change, or
make a static global 'Constant' if the user might want to change
it, or make it a parameter if it's local to a function). However,
*if* one wanted to make a 'const struct myADT', this would be an
excellent way to do so.


Counter example, taken from my hashlib package. This contains a
defined structure holding various fields with current data about
the hashtable, including the number of items stored, deleted,
count of probes, collisions, and error status. The record itself
is NEVER exposed to the user, since it is essential that it be
modified only by the operation of the package. However the
definition of the structure is published in the header file. The
user can access the current contents by executing:

status = hshstatus(h);

where h is the value returned on opening the hashtable (something
like the FILE * returned on opening a file). Assuming the user
has correctly declared status as something like:

hshstats status;

he can safely retrieve all those fields, and I have never exposed
them to prying hands.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #52
CBFalconer wrote:
Counter example, taken from my hashlib package.


How can we download a copy of hashlib?

Nov 14 '05 #53
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
So there are exceptions. As a rule of thumb, however, if a function
calls another function that returns a value, then the caller is the
appropriate level to process that value - not simply to return it to a
higher level.
Any reasons for that statement?


Sure. The basic idea of structured programming is that the program is
divided into a hierarchy of functions, becoming more general-purpose as you
move down the hierachy, more specific as you move up.


Exactly. So it is perfectly reasonable to define a low-level function to
handle generic data, and then add a function to handle specific data
which does nothing but find the specific data and then invoke the first
function on it.
The other principle is that each function performs one closely-defined task,
and is a black box to the function that calls it.
Exactly. So when foo(bar) foos a bar, but you don't know or care how,
foo_largest(bar) should not try to second-guess it, but should find the
largest bar and then foo it using the lower-level function foo().
This means that barb() shouldn't know the intricacies of foo(). Any change
to foo() shouldn't imply a change in barb(), but only in bar() (where it is
unavoidable).
This does not absolutely preclude returning a result directly from foo() in
barb(), but it does mean that occasions for doing so will be rare,
Nonsense. It is exactly because you don't care what foo() and bar() do
internally, but do know that bar() returns a struct baz, that it can
call foo() which also returns a struct baz.
and can be used as a marker for code that is likely to be poorly-designed,
because the function hierarchy isn't abstracting foo() from bar().


But that is exactly what it _does_ do!
If you need to prepare data for foo() then that would be an
indication that foo() is badly written.


Nonsense. Look at the example I gave: it could easily be an indication
that foo() can work on any data, and the calling function uses it to
work on specific data.

It means that foo() is too general for the real caller to use.


For _that_ real caller to use. Other functions could easily put it to
good use.

Richard
Nov 14 '05 #54
"E. Robert Tisdale" wrote:
CBFalconer wrote:
Counter example, taken from my hashlib package.


How can we download a copy of hashlib?


By keeping your eyes open. However, I don't think you want to.
It is copyright and released under the GPL, and I would look amiss
upon your altering it in any way. The rest of the world would
probably look amiss upon any code you released after using it.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #55
More data points...

Papadopoulos Giannis wrote:
Which do you think is best?
I take that to mean, "Which do I prefer to use?" (-:
'There is no best. There is only prefer or not prefer.'
1.
a) type* p;
To me, p is a type*. And because I usually initialize my
variables, and because I usually put them on one line each, the
"type* p, q;" issue is not an issue for me.
2.
c) return var; 3.
c) return ptr->var; 4.
c) return foo(ptr->var); 5.
d) a=b+c;
But prefer "a = b + c;".
6.
c)
type foo(type arg1, type arg2, ...)
{
declarations;
code;
return;
}


C is closest, but prefer 4-space indent (NO TABS!!) and a blank
line after declarations. It does depend on the complexity of the
function.

--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
Nov 14 '05 #56

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
Exactly. So it is perfectly reasonable to define a low-level function to
handle generic data, and then add a function to handle specific data
which does nothing but find the specific data and then invoke the first
function on it.
Problem is there are two ways a function can be "more general". The first
way is by being simpler. For instance, a triangle is the simplest
geometrical shapes. All other polygons can be built up out of triangles. It
is therefore reasonable to have "triangle" as your lowest level graphics
function.
The other way is by being more complex. "quad" takes more parameters and is
harder to write than "triangle". It can also draw a triangle (by making two
points identical). However it is not usually a good idea to implement
"triangle" in terms of "quad".
Nonsense. It is exactly because you don't care what foo() and bar()
do internally, but do know that bar() returns a struct baz, that it can
call foo() which also returns a struct baz.
Read through the example again. You will see that a change to foo(), the
lowest level function, doesn't require any changes to bar(), but does break
barb(), the highest-level function. This is the sort of undesirable
situation you will get if you handle information at the wrong level, and it
is very easy for bugs to slip through.
It means that foo() is too general for the real caller to use.


For _that_ real caller to use. Other functions could easily put it to
good use.

So we're in the situation where the user wants to draw a triangle but the
graphics system will only draw quads. Sometimes this is unavoidable (the
Sega Saturn had hardware that would only rasterise quads), but most people
would say that this indicates something is wrong with the way the library is
defined. Special cases are only seldom well handled by supplying the
parameters to the more general cases.
I'll give an exception that proves the rule. MS Windows has a function
TextOut that takes x, y co-ordinates, a string, and the length of the string
to write. Obviously 99% of the time you want to pass str, strlen(str). It
makes sense to write a convenience function

int TextOutZ(HWND hwnd, int x, int y, char *str)
{
return TextOut(hwnd, x, y, str, strlen(str));
}

However it only makes sense because TextOut() wasn't designed with C in
mind - it is a hang over from the Pascal days. If Windows was being
rewritten from scratch today everyone would use C NUL-terminated strings as
a matter of course.

We don't want to be too strong and say never, ever must one return the
return value of another function directly. It's rather like global
variables, gotos, and very long functions - occasionally they are called for
but too many indicate that the person who wrote the code hasn't really
grasped the principles of structured programming.
Nov 14 '05 #57

"Paul Hsieh" <qe*@pobox.com> wrote in message
c), return is not a function. Though you want to ask why you are
returning the return value from another function directly - this is
unusual.


Its not unusual, and it might be a macro rather than a function.

Better qualify that by "unusual in well-written C programs". A macro that
evaluates to a value based on its parameters is a function. You might say it
isn't a "function" in C terms. Here you're making a logic error based on
confusion between the linguistic and the mathematical set theory use of
categories. This error is "Before you cross the road, wait until there are
no cars coming" Tum-tee-tum-tum, crump! Kid run over by a bus.
Nov 14 '05 #58
CBFalconer wrote:
By keeping your eyes open.
It's vaporware!
However, I don't think you want to.
It is copyright and released under the GPL and
I would look amiss upon your altering it in any way.
You had not better release it under the GPL then.
The GPL gives me the right to modify and redistribute it.
The rest of the world would probably look amiss
upon any code you released after using it.


I don't think that I could use it.

Nov 14 '05 #59

On Fri, 30 Jan 2004, CBFalconer wrote:

"Arthur J. O'Dwyer" wrote:

... I myself religiously avoid returning struct
types by value, and I also rarely 'const'ify anything anyway
(preferring to #define CONSTANT if it's never going to change, or
make a static global 'Constant' if the user might want to change
it, or make it a parameter if it's local to a function). However,
*if* one wanted to make a 'const struct myADT', this would be an
excellent way to do so.


Counter example, taken from my hashlib package. This contains a
defined structure holding various fields with current data about
the hashtable, including the number of items stored, deleted,
count of probes, collisions, and error status. The record itself
is NEVER exposed to the user, since it is essential that it be
modified only by the operation of the package. However the
definition of the structure is published in the header file. The
user can access the current contents by executing:

status = hshstatus(h);

where h is the value returned on opening the hashtable (something
like the FILE * returned on opening a file). Assuming the user
has correctly declared status as something like:

hshstats status;

he can safely retrieve all those fields, and I have never exposed
them to prying hands.


To what is this a "counter-example"? I see allusions to "private"
data, user-defined types, and encapsulation, but the part of my
post that you quoted wasn't talking about such high-level stuff.
I just said that if you wanted to make a const struct, then initializing
it with the value returned by a function would be an excellent idea.

So, if you're disagreeing with something I wrote, could you say
so? Or if you're agreeing with something I wrote, could you say
that too? Or if you're just describing hashlib, could you start a
new thread? ;-)

On second glance, I realize that you can't use the result of a
function to initialize a struct at file scope; is *that* what you
meant to say, maybe?

-Arthur
Nov 14 '05 #60
"Arthur J. O'Dwyer" wrote:
On Fri, 30 Jan 2004, CBFalconer wrote:
"Arthur J. O'Dwyer" wrote:

... I myself religiously avoid returning struct
types by value, and I also rarely 'const'ify anything anyway
(preferring to #define CONSTANT if it's never going to change, or
make a static global 'Constant' if the user might want to change
it, or make it a parameter if it's local to a function). However,
*if* one wanted to make a 'const struct myADT', this would be an
excellent way to do so.


Counter example, taken from my hashlib package. This contains a
defined structure holding various fields with current data about
the hashtable, including the number of items stored, deleted,
count of probes, collisions, and error status. The record itself
is NEVER exposed to the user, since it is essential that it be
modified only by the operation of the package. However the
definition of the structure is published in the header file. The
user can access the current contents by executing:

status = hshstatus(h);

where h is the value returned on opening the hashtable (something
like the FILE * returned on opening a file). Assuming the user
has correctly declared status as something like:

hshstats status;

he can safely retrieve all those fields, and I have never exposed
them to prying hands.


To what is this a "counter-example"? I see allusions to "private"
data, user-defined types, and encapsulation, but the part of my
post that you quoted wasn't talking about such high-level stuff.
I just said that if you wanted to make a const struct, then initializing
it with the value returned by a function would be an excellent idea.

So, if you're disagreeing with something I wrote, could you say
so? Or if you're agreeing with something I wrote, could you say
that too? Or if you're just describing hashlib, could you start a
new thread? ;-)


I was disagreeing with the first sentence of the portion I quoted,
which I read as denigrating returning structures from functions.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #61

On Sat, 31 Jan 2004, CBFalconer wrote:

"Arthur J. O'Dwyer" wrote:
On Fri, 30 Jan 2004, CBFalconer wrote:
"Arthur J. O'Dwyer" wrote:
>
> ... I myself religiously avoid returning struct
> types by value, Counter example, taken from my hashlib package. This contains a
defined structure holding various fields with current data about
the hashtable, including the number of items stored, deleted,
count of probes, collisions, and error status. The record itself
is NEVER exposed to the user, since it is essential that it be
modified only by the operation of the package. However the
definition of the structure is published in the header file. The
user can access the current contents by executing:

status = hshstatus(h);

where h is the value returned on opening the hashtable (something
like the FILE * returned on opening a file). Assuming the user
has correctly declared status as something like:

hshstats status;

he can safely retrieve all those fields, and I have never exposed
them to prying hands.
To what is this a "counter-example"?

I was disagreeing with the first sentence of the portion I quoted,
which I read as denigrating returning structures from functions.


Okay. Well, I shall continue to religiously avoid returning structs
by value from functions. In the case you quote, if I were not being
utterly paranoid, I would simply make 'hshstatus' return a pointer
to the "real" record, const-qualified. :)

const struct hshstats status;
status = hshstatus(h);

If I were being paranoid, I might make the user pass in his buffer
explicitly [despite NRV optimization's being common, as E.R. Tisdale
pointed out a while back]. I just like being explicit about these
things, I guess:

struct hshstats status;
hshstatus(h, &status);

Or I might see your allusion to "FILE *" above, and make an exact
analogue of that scheme, although that would be overkill for most
applications:

struct hshstats *status;
status = hshgetstatus(h);
[...]
hshkillstatus(status);

Anyway, there are plenty of ways to do it. Your hashlib is an
excellent example of how somebody can use return-struct-by-value to
do something useful, but it's not gonna convert me. ;-D
[Why don't I like returning structs? Mostly because it's not as
transparent as most of the C language that I do use -- it's not
clear whether it's going to be fast or slow unless you know what
sorts of optimization your compiler does with returning structs.]

-Arthur
Nov 14 '05 #62
"Arthur J. O'Dwyer" wrote:
.... snip ...
Okay. Well, I shall continue to religiously avoid returning structs
by value from functions. In the case you quote, if I were not being
utterly paranoid, I would simply make 'hshstatus' return a pointer
to the "real" record, const-qualified. :)

const struct hshstats status;
status = hshstatus(h);
.... snip ...
Anyway, there are plenty of ways to do it. Your hashlib is an
excellent example of how somebody can use return-struct-by-value to
do something useful, but it's not gonna convert me. ;-D


Most such techniques are not idiot or enemy proof. Once the user
can lay his hands on a pointer to internal data he can muck with
it. The const qualifier is easily overridden.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #63
Papadopoulos Giannis wrote:
Which do you think is best?

1.
a) type* p;
b) type *p;
b
2.
a) return (var);
b) return(var);
c) return var;
c
3.
a) return (ptr->var);
b) return(ptr->var);
c) return ptr->var;
c
4.
a) return (foo(ptr->var));
b) return(foo(ptr->var));
c) return foo(ptr->var);
c
5.
a) a = (b+c);
b) a=(b+c);
c) a = b+c;
d) a=b+c;
a = b + c;
6.
a)
type foo(type arg1, type arg2, ...) {
declarations;
code;
return;
}
b)
type foo(type arg1, type arg2, ...) {
declarations;

code;

return;
}
c)
type foo(type arg1, type arg2, ...)
{
declarations;
code;
return;
}
d)
type foo(type arg1, type arg2, ...)
{
declarations;

code;

return;
}
e)
type foo(type arg1, type arg2, ...)
{
declarations;
code;
return;
}
f)
type foo(type arg1, type arg2, ...)
{
declarations;

code;

return;
}


a

Nov 14 '05 #64

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: GTF | last post by:
PHP Web Survey Idea.. I have been given an opportunity to create a web based survey. This is a fairly lengthy survey of 60 pages on paper (various multiple choice and free form). These are...
1
by: Nico Baumgarten | last post by:
Dear Madam/Sir, You are invited to participate in an international research study. This research project is headed and led by Cambridge student Nico Baumgarten. What is it all about? It is a...
18
by: craig | last post by:
I am curious about how many of you prefer style 1 vs. style 2, and why. Are there names for these style? style 1: method { }
144
by: Natt Serrasalmus | last post by:
After years of operating without any coding standards whatsoever, the company that I recently started working for has decided that it might be a good idea to have some. I'm involved in this...
2
by: David | last post by:
Hello all -- Is it possible to code XML to launch a survey/ad when a user clicks on a listed podcast? In other words, you are subscribed to myfeed.xml. You click on a podcast listing. Is it...
13
by: benben | last post by:
Is there an effort to unify the c++ coding standard? Especially identifier naming. Not a big issue but it would be annoying to have to incorporate different coding styles simultaneously when...
0
by: Janet93 | last post by:
If you are involved in the development of scientific computing software, you are invited to participate in a survey on developing this kind of software. If you have already received this request, I...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.