[PATCH 4/4] Move the variable initialisations closer to use and add blanks
thiago at macieira.org
Mon Dec 16 14:13:55 UTC 2013
On segunda-feira, 16 de dezembro de 2013 11:48:20, Dirk Hohndel wrote:
> > That's a good point. I don't mind having the variables declared at the top
> > provided they are *few* variables. If there are tens of variables and the
> > function is big enough I don't remember what this variable is or does, we
> > have a problem either way. I solved it by moving the variables closer to
> > the use- point, but splitting the function is another way.
> And generally the one I prefer.
> Given my lack of fluency in C++ / Qt I haven't been as strict with this
> as I should have... but it's something I plan to push for a little more
> strongly again.
I'll modify patch 4 then and re-send. I'll also update patch 1 so the file name
is passed from the caller function, so please don't apply any of the patches.
> As Linus pointed out, it's ok to declare the variables later in the
> function. For example if you have a bunch of sanity checks in the
> beginning (dive != NULL, amount_selected == 1, waxing phase of the moon)
> then create a scope after those are done and declare the variables in
> that scope
Right, if the initialisation of the variables has a cost, it's best to leave
them to later. One exception we usually make in C++ is the variable that gets
returned: often compilers do Return Variable Optimisation (RVO) better if you
always return the same variable. Another school of thought is that you should
file bugs for when they don't :-)
Now, I also subscribe to the philosophy of doing validity checks as late as
possible, unless that would create clutter. If you're doing something wrong,
you deserve to pay the penalty, like allocating memory then deallocating it
soon after. It's also known as "optimise for the common case" :-)
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the subsurface