-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113143/#review41476
-----------------------------------------------------------



kmymoney/dialogs/transactioneditor.cpp
<http://git.reviewboard.kde.org/r/113143/#comment30321>

    Please declare variables at the point of their initialization, there is no 
point in declaring the number variable outside of the if statement. And use a 
const reference if you don't intend to change it.
    
    const QString &number = tr.splits().front().number();



kmymoney/mymoney/mymoneyfile.h
<http://git.reviewboard.kde.org/r/113143/#comment30322>

    Please pass a 'const QString &' as a parameter instead of by-value.
    And why does 'strNumericPart' only forward to the 'numericPart' private 
function, why don't you make 'numericPart' public and remove 'strNumericPart'?



kmymoney/mymoney/mymoneyfile.h
<http://git.reviewboard.kde.org/r/113143/#comment30323>

    Please pass a 'const QString &' as a parameter instead of by-value.



kmymoney/mymoney/mymoneyfile.cpp
<http://git.reviewboard.kde.org/r/113143/#comment30324>

    Please pass a 'const QString &' as a parameter instead of by-value.


The above are just some plain old C++ coding style suggestions. Also should 
'numericPart' really belong to the mymoneyfile object? If so I would add some 
testcases for it in the mymoneyfiletest suite.

- Cristian Oneț


On Oct. 7, 2013, 8:10 p.m., Allan Anderson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113143/
> -----------------------------------------------------------
> 
> (Updated Oct. 7, 2013, 8:10 p.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 319801
>     http://bugs.kde.org/show_bug.cgi?id=319801
> 
> 
> Repository: kmymoney
> 
> 
> Description
> -------
> 
> If a user's sequence of check numbers is broken by, say 'ATM' or an invoice 
> number such as 'No 123-001 ABC', the next check number produced will be '1', 
> entries containing alpha or punctuation characters not being saved.
> The fix corrects this by saving the complete entry, and uses any entered 
> numeric part to calculate the next number in sequence.  If an existing 
> numeric entry is edited, this entry will be taken into account for the next 
> number.
> 
> There are some quirks.  If the entry which led to the current 'next number' 
> is deleted, it is not possible to revert to the previous, now forgotten, 
> 'next number', so the produced 'next number' is likely to leave a 'gap', and 
> may need editing.  Also, there is no check that a new 'next number' does not 
> already exist.  For instance, if there is the erroneous sequence 23,23,24, 
> the 'next number' will be the expected 25.  However, if the user corrects the 
> error by changing a 23 to 22, the new 'next number' will be 23, which also 
> already exists.  I'm not sure if such issues, which exist also in the current 
> release, are worthy of fixing for a fairly unimportant area, without becoming 
> more involved.
> 
> 
> Diffs
> -----
> 
>   kmymoney/dialogs/transactioneditor.h f07dafb 
>   kmymoney/dialogs/transactioneditor.cpp 39049cf 
>   kmymoney/mymoney/mymoneyfile.h af0c6fb 
>   kmymoney/mymoney/mymoneyfile.cpp ff7302c 
> 
> Diff: http://git.reviewboard.kde.org/r/113143/diff/
> 
> 
> Testing
> -------
> 
> Many manual entries checked, including coping with all values in the unit 
> tests.  The unit test runs OK.
> 
> 
> Thanks,
> 
> Allan Anderson
> 
>

_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel

Reply via email to