Nolan Cafferky wrote:
This may not inform the current conversation at all, but a while back
I went on a cross-compiler compatibility binge for all of my active
projects, and I found that some compilers (*cough* Borland *cough) had
some very strange compiler/run time errors unless all variable
I think Tom stated it pretty well:
When the variable is going to be set anyway in
straight-line code at the top of the function, then it's mostly a
matter of taste whether you set it with an initializer or an assignment.
the key phrase is: "set anyway in straigh-tline code at the top of
Well, clearly you should only assign meaningful values to variables, but
I don't see anything wrong with omitting an initializer, initializing
the variable before using it, and letting the compiler warn you if you
forget to do this correctly.
The problem that that introduces is that you
<[EMAIL PROTECTED]> writes:
> initializers also force you to declare variables in the scope where they
> are needed. Instead of declaring every variable at the start of the
> function, it's better to declare them as nested as practical (not as
> nested as possible, but as nested as practical
On Thu, 2006-11-02 at 14:23 -0500, [EMAIL PROTECTED] wrote:
> Yes, the compiler can detect unitialized variables,
In most situations, anyway.
> I've seen too many less-scarred developers add an " = NULL" to quiet
> down the tool. But that's (arguably) worse than leaving the variable
> uninitia
On 11/3/06, Tom Lane <[EMAIL PROTECTED]> wrote:
imad <[EMAIL PROTECTED]> writes:
> Well, its about the coding style. And I doubt there exists a data type
> which may not have
> an initializer. A NULL / Zero is an option in all cases and you can do
> whatever you want to assign it a value immediat
<[EMAIL PROTECTED]> writes:
> initializers also force you to declare variables in the scope where they
> are needed. Instead of declaring every variable at the start of the
> function, it's better to declare them as nested as practical (not as
> nested as possible, but as nested as practical).
I
Yeah, I agree with that. But as Andrew noted, we don't really have any
hard and fast coding rules --- the only guideline is to do your best to
make your code readable, because other people *will* have to read it.
I'm not really looking for hard/fast rules. Just picking brains.
In t
imad <[EMAIL PROTECTED]> writes:
> Well, its about the coding style. And I doubt there exists a data type
> which may not have
> an initializer. A NULL / Zero is an option in all cases and you can do
> whatever you want to assign it a value immediately after the
> initialization section. My two cen
> Shouldn't we turn on warnings by the compiler on uninitialized
> variables? This can also be helpful.
Those warnings should already be enabled, at least with GCC.
Yes, the compiler can detect unitialized variables,
But, that introduces a new problem. There are a lot of tools out the
The disadvantage of using initializers is that you end up contorting the code
to allow you to squeeze things into the initializers and it limits what you
can do later to the code without undoing them.
For example, if later you find out you have to, say, lock a table before the
itupdesc init
Gregory Stark <[EMAIL PROTECTED]> writes:
> People expect initializers to be simple expressions, macro calls, accessor
> functions, and so on. Not to call out to complex functions that implement key
> bits of the function behaviour.
Yeah, I agree with that. But as Andrew noted, we don't really ha
On 11/2/06, Gregory Stark <[EMAIL PROTECTED]> wrote:
<[EMAIL PROTECTED]> writes:
> I would probably write that as:
>
>
>
> static TransactionId
> _bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
>
Gregory Stark wrote:
<[EMAIL PROTECTED]> writes:
I would probably write that as:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey
On Thu, 2006-11-02 at 23:53 +0500, imad wrote:
> Shouldn't we turn on warnings by the compiler on uninitialized
> variables? This can also be helpful.
Those warnings should already be enabled, at least with GCC.
-Neil
---(end of broadcast)---
TIP
<[EMAIL PROTECTED]> writes:
> I would probably write that as:
>
>
>
> static TransactionId
> _bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
> Buffer buf, ScanKey itup_scankey)
> {
> Tup
Shouldn't we turn on warnings by the compiler on uninitialized
variables? This can also be helpful.
--Imad
www.EnterpriseDB.com
On 11/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I've noticed a trend in the PostgreSQL code base - for some reason, we tend
to avoid initializing automatic
I've noticed a trend in the PostgreSQL code base - for some reason, we tend to avoid initializing automatic variables (actually, the code base is pretty mixed on this point).
For example in _bt_check_unique() we have:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Rel
18 matches
Mail list logo
