) the comma-list is better.
I've been silently following this coding style discussion with a bit
of fun I must say, but I'd like to +1 this sum up.
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
signature.asc
Description: Digital signature
On Mon, Oct 02, 2006 at 05:01:51PM -0700, Roy T. Fielding wrote:
In any case, I prefer the style of C code that more directly reflects
the underlying assembly, even if an optimizing compiler would produce
the same assembler for both. It is just natural to read use the result
of this save
I don't understand all of this... Just because there were some
bugs in some code because someone forgot the precendence
rules for C should mean we abandon standard C idioms...
while ((c = getchar()) != EOF)
is like one of the 1st C shortcuts people learn and is
SOP for C coding.
--
Jim Jagielski wrote:
rules for C should mean we abandon standard C idioms...
shouldn't
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If
Jim Jagielski wrote:
I don't understand all of this... Just because there were some
bugs in some code because someone forgot the precendence
rules for C should mean we abandon standard C idioms...
while ((c = getchar()) != EOF)
is like one of the 1st C shortcuts people learn and is
I don't feel strongly enough about all on one line vs assignment on
one and test on another to really push one over the other, however.
But that comma method is an abomination ;)
--
===
Jim Jagielski [|] [EMAIL
On Wednesday 04 October 2006 19:04, Jim Jagielski wrote:
But that comma method is an abomination ;)
Heh. Is a sequence of statements separated by semicolons an abomination too?
--
Nick Kew
On Mon, 2 Oct 2006, Garrett Rooney wrote:
Or the even more readable:
rv = do_something(args);
if (rv == APR_SUCCESS) {
}
+1 for simple code like this.
It comes naturally when you need to do stuff like
rv = dostuff(...);
if(rv != APR_SUCCESS rv != whatever) {
...
and is also less likely
On 10/2/06, Garrett Rooney [EMAIL PROTECTED] wrote:
Or the even more readable:rv = do_something(args);if (rv == APR_SUCCESS) {}+1.Using the comma operator is orders of magnitude too nasty/subtle to use. -- justin
Jeff Trawick wrote:
Or the even more readable:
rv = do_something(args);
if (rv == APR_SUCCESS) {
}
+1 to this one
That's my preference as well. Unambiguous and easy to read.
Bill
We have a bunch of new bug reports[1], detailing bugs of the form
if ((rv = do_something(args) == APR_SUCCESS))
for
if ((rv = do_something(args)) == APR_SUCCESS)
Of course, that's a C classic, and can be a *** to spot.
We can avoid this by adopting an alternative coding style
this by adopting an alternative coding style
that doesn't rely on confusing parentheses:
if (rv = do_something(args), rv == APR_SUCCESS)
Can I suggest adopting this as a guideline for new code,
to avoid this kind of bug?
Or the even more readable:
rv = do_something(args);
if (rv == APR_SUCCESS
a C classic, and can be a *** to spot.
We can avoid this by adopting an alternative coding style
that doesn't rely on confusing parentheses:
if (rv = do_something(args), rv == APR_SUCCESS)
Can I suggest adopting this as a guideline for new code,
to avoid this kind of bug?
Or the even more
Garrett Rooney wrote:
Or the even more readable:
rv = do_something(args);
if (rv == APR_SUCCESS) {
}
yuck! Think of all the harmless newlines you are senselessly wasting.
Our children will have to code with no newlines if we do not conserve
them today. Won't someone please think of the
classic, and can be a *** to spot.
We can avoid this by adopting an alternative coding style
that doesn't rely on confusing parentheses:
if (rv = do_something(args), rv == APR_SUCCESS)
Can I suggest adopting this as a guideline for new code,
to avoid this kind of bug?
Or the even more
Am Montag, den 02.10.2006, 22:39 +0200 schrieb Ruediger Pluem:
if (((rc = apr_procattr_create(procattr, p)) == APR_SUCCESS)
((rc = apr_procattr_cmdtype_set(procattr,
APR_SHELLCMD_ENV)) == APR_SUCCESS)
((rc =
On Monday 02 October 2006 21:39, Ruediger Pluem wrote:
In general I agree with the above, but there are situations were the old
style really makes sense, e.g (from log_child in server/log.c):
if (((rc = apr_procattr_create(procattr, p)) == APR_SUCCESS)
((rc =
Am Montag, den 02.10.2006, 19:56 +0100 schrieb Nick Kew:
Can I suggest adopting this as a guideline for new code,
to avoid this kind of bug?
Is there an apache coding style guide?
Thx,
Joachim
On 10/02/2006 11:15 PM, Joachim Zobel wrote:
Am Montag, den 02.10.2006, 19:56 +0100 schrieb Nick Kew:
Can I suggest adopting this as a guideline for new code,
to avoid this kind of bug?
Is there an apache coding style guide?
Yes of course:
http://httpd.apache.org/dev/styleguide.html
On 10/02/2006 11:12 PM, Nick Kew wrote:
On Monday 02 October 2006 21:39, Ruediger Pluem wrote:
In general I agree with the above, but there are situations were the old
style really makes sense, e.g (from log_child in server/log.c):
if (((rc = apr_procattr_create(procattr, p)) ==
on the warnings. Or use lint.
We can avoid this by adopting an alternative coding style
that doesn't rely on confusing parentheses:
if (rv = do_something(args), rv == APR_SUCCESS)
Which nobody uses because it is so weird and unusual (speaking as a perl
programmer who uses even more weird
On Monday 02 October 2006 23:31, Roy T. Fielding wrote:
We can avoid this by adopting an alternative coding style
that doesn't rely on confusing parentheses:
if (rv = do_something(args), rv == APR_SUCCESS)
Which nobody uses because it is so weird and unusual (speaking as a perl
On Oct 2, 2006, at 3:54 PM, Nick Kew wrote:
On Monday 02 October 2006 23:31, Roy T. Fielding wrote:
We can avoid this by adopting an alternative coding style
that doesn't rely on confusing parentheses:
if (rv = do_something(args), rv == APR_SUCCESS)
Which nobody uses because it is so
On 20/09/2006, at 06:20, Joe Orton wrote:
Hi Davi,
On Tue, Sep 19, 2006 at 11:34:03PM -0300, Davi Arnaut wrote:
Clean up code style in the cache code and shrink the mod_mem_cache
store_body function.
The casts to/from void * are unnecessary and could just be removed
rather than being
Clean up code style in the cache code and shrink the mod_mem_cache
store_body function.
Index: modules/cache/mod_mem_cache.c
===
--- modules/cache/mod_mem_cache.c.orig
+++ modules/cache/mod_mem_cache.c
@@ -52,27 +52,30 @@
module
who'll use
2.0) of holding up the release in order to fix up the coding style?
I might just be overreacting, but I'm particularly worried about
making this a release showstopper because I fear that it could
offset some of the potential benefits of 2.0.
I assert that a big part of the value
On Sat, Nov 10, 2001 at 06:21:18PM -0800, Brian Pane wrote:
While I'm not opposed in principle to doing a code cleanup before
GA, I'd feel much more comfortable if it either:
* didn't delay the release, or
* added some quantifiable, incremental value for users.
I think it adds some
27 matches
Mail list logo
