[PATCH 4/4] Move the variable initialisations closer to use and add blanks

Thiago Macieira 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.

[snip]
> 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...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20131216/1a5c5ea3/attachment.sig>


More information about the subsurface mailing list