Bugfix/nw23001440/editc problems

[cosentino-smeup]

Description

With this branch we have fixed all the problems occurring when formatting decimal values to string.

Most relevant changes:

• spotted the operation to do for any edit code
• properly managed every edit code
• fixed all problems, errors and all wrong tests based on the old version
• added some unsupported edit code cases: negative number with X edit code, out of limit of number with Y edit code (<=2, >9)
• refactored the structure of code in the source "formatting.kt"

Related to:
T15_A50

Checklist:

• There are tests regarding this feature
• The code follows the Kotlin conventions (run ./gradlew ktlintCheck)
• The code passes all tests (run ./gradlew check)
• There is a specific documentation in the docs directory

[lanarimarco]

I like it, but I have some doubts.

First: I have seen that you have commented in some mute test, the assertion related the edicode X, I remember something but my memories are a little bit confused...

Second: The editcode is a really messy operation code, in my opinion, when we work with this level of complexity we should create some unit tests in order to test the related logic, also before to test this logic through the rpgle program interpretation.
In this case I whould have written a test suite named FormattingTest and create for each editcode a test unit decimalFormatF1(), decimalFormatFn(), for each function defined in DecimalValue.formatAs extension function.
What do you think about this?

[cosentino-smeup]

1. The edit code X, in case of negative numbers, transforms the last digit in a letter with the following translation:

0 }
1 J
2 K
3 L
4 M
5 N
6 O
7 P
8 Q
9 R

If the last digit of the negative number is "0" will be replaced with "}"
If the last digit of the negative number is "1" will be replaced with "J"
and so on ..

The meaning of this translation to make the string 1 character shorter. We must go back many years behind this decision where saving a byte use to make the difference.

The problem was that the character "}" could work only with Italian settings.

To avoid other unknown side effects, has been decided not to support negative numbers with the X edit code.

2. Regarding unit tests, I am not sure what benefits they could bring, which integration tests do not already provide. Another point, because I don't know the entire development infrastructure yet, is when they would run. I know for example that IT run after a commit in a branch. What about the unit tests?

[lanarimarco]

Jariko works this way: - Transform an rpgle program into a model of: - Statement (codop) - Expression (bif) - Value - ... - Invoke Statement.execute for each statement - The statements use expressions - The expressions return values - and so on... We also use helper classes (or helper functions), for example the main logic behind EDITC implementation is in DecimalValue.formatAs and in this extension function we have defined a function for each editcode. What I mean is: since that the logic behind the editcode (for instance 1) is the function f1(), if we write a test unit (a method annotated with @test) for f1(), we can test the logic behind the edicode "1" by skipping all the stages related the rpgle interpretation. This thing could accelerate development and fixes. It's only an idea for the future, in case we realize that there are a lot of issues to fix. Il giorno ven 2 feb 2024 alle ore 09:16 cosentino-smeup < ***@***.***> ha scritto:

…

1. The edit code X, in case of negative numbers, transforms the last digit in a letter with the following translation: 0 } 1 J 2 K 3 L 4 M 5 N 6 O 7 P 8 Q 9 R If the last digit of the negative number is "0" will be replaced with "}" If the last digit of the negative number is "1" will be replaced with "J" and so on .. The meaning of this translation to make the string 1 character shorter. We must go back many years behind this decision where saving a byte use to make the difference. The problem was that the character "}" could work only with Italian settings. To avoid other unknown side effects, has been decided not to support negative numbers with the X edit code. 1. Regarding unit tests, I am not sure what benefits they could bring, which integration tests do not already provide. Another point, because I don't know the entire development infrastructure yet, is when they would run. I know for example that IT run after a commit in a branch. What about the unit tests? — Reply to this email directly, view it on GitHub <#409 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJR622WOWEV4ZEPCCU4OIQDYRSOEDAVCNFSM6AAAAABCTD742OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRTGI4TONJZHE> . You are receiving this because you commented.Message ID: ***@***.***>

-- [image: smeup] <https://www.smeup.com> Marco Lanari R&D Department - Developer Office: 0521940611 <00390521940611> www.smeup.com *SMEUP LAB SRL* Via Carra, 8 - 43122 Parma (PR)

[lanarimarco]

Ok, I will merge it as soon as the previous pr will be approved.