Agree, I'm not a big fan of the 2 solutions you gave though.<div><div><br></div><div>When I remember to avoid variable shadowing, I have a couple of tricks to rename problematic variables:<div>for example a variable named "row" could be renamed as: </div>
<div> - indexRow / itemRow / cellRow / childRow / parentRow ( who owns the variable)</div><div> - rowToInsert/rowToDelete (action on the variable)</div><div><div> - newRow / oldRow / tmpRow ( lifetime of the variable)</div>
</div><div> - ....</div><div>There is almost always one prefix or suffix that can be added and gives more information about the variable.</div><div>Julien.</div><div><div><br><div class="gmail_quote">On Thu, Apr 8, 2010 at 6:15 PM, Luis Ibanez <span dir="ltr"><<a href="mailto:luis.ibanez@kitware.com">luis.ibanez@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I see,<br>
<br>
It is too bad that Qt got satisfied with a lower quality bar.<br>
<br>
<br>
We can still avoid having local variables with the same<br>
names as member variables and member methods.<br>
<br>
For example,<br>
many of the offending warnings were fixed by replacing<br>
<br>
ambiguousvariablename<br>
<br>
with<br>
<br>
ambiguousvariablenameValue<br>
<br>
we could have as well used the more arcane<br>
<br>
ambiguousvariablename_<br>
<br>
<br>
Making good choices on names of methods, and variables<br>
is a an effective way of documenting the code.<br>
<br>
<br>
Luis<br>
<br>
<br>
-----------------------------------------------------------------------------------<br>
<div><div></div><div class="h5">On Thu, Apr 8, 2010 at 6:08 PM, Julien Finet <<a href="mailto:julien.finet@kitware.com">julien.finet@kitware.com</a>> wrote:<br>
> Hi Luis,<br>
> I understand your concern.<br>
> We can't change the name of the method index() as it is a virtual method<br>
> that has been declared in a Qt subclass.<br>
> And the problem we face here is that the Qt library doesn't care about<br>
> shadow variables. (and if I recall, they didn't plan on changing that).<br>
> We unofficially decided during the CTK Pre Hackfest that a CTK class should<br>
> follow the naming convention of its derived class, Qt in this example.<br>
> Is that still OK for everybody ?<br>
> Setting up KWStyle seems like a good idea. Can we configure it in a way to<br>
> check a style depending on a filename (ideally the style of the derived<br>
> class)<br>
> Julien.<br>
> On Thu, Apr 8, 2010 at 5:50 PM, Luis Ibanez <<a href="mailto:luis.ibanez@kitware.com">luis.ibanez@kitware.com</a>> wrote:<br>
>><br>
>> I recall that at some point we discussed a<br>
>> naming convention for Qt-like classes, but<br>
>> I'm not sure if we arrived to a consensus.<br>
>><br>
>><br>
>> The file:<br>
>><br>
>> Libs/DICOM/Core/ctkDICOMModel.cxx<br>
>><br>
>> had an abundant use of local variables with<br>
>> names matching some member variables and<br>
>> member methods.<br>
>><br>
>> A notable example:<br>
>><br>
>> "index"<br>
>><br>
>> I just committed a fix for most of them,<br>
>> but for the long run it will be great if we<br>
>> agree on some naming convention.<br>
>><br>
>> I would vote against having a method of a C++ class<br>
>> to be called "index()" for example. :-)<br>
>><br>
>> a more useful name will be "getIndex()", for example,<br>
>> or in this particular case, it looks like what the function<br>
>> is actually doing is generating an index, so good names<br>
>> could be<br>
>><br>
>> ctkDICOMModel::generatgeIndex ( int row, int column, const QModelIndex<br>
>> & parentValue ) const<br>
>><br>
>> or<br>
>><br>
>> ctkDICOMModel::computeIndex ( int row, int column, const QModelIndex &<br>
>> parentValue ) const<br>
>><br>
>> or<br>
>><br>
>> ctkDICOMModel::produceIndex ( int row, int column, const QModelIndex &<br>
>> parentValue ) const<br>
>><br>
>><br>
>> There is already another<br>
>><br>
>> createIndex(int, int, Node *)<br>
>><br>
>><br>
>> so it will be fine if we use<br>
>><br>
>> ctkDICOMModel::createIndex ( int row, int column, const QModelIndex &<br>
>> parentValue ) const<br>
>><br>
>> since the signature will be different.<br>
>><br>
>><br>
>> ---<br>
>><br>
>><br>
>> Do we have a document on coding style ?<br>
>><br>
>> if we do,<br>
>> we probably should setup KWStyle testing<br>
>> before things get out of control.<br>
>><br>
>><br>
>><br>
>> Luis<br>
><br>
><br>
</div></div></blockquote></div><br></div></div></div></div>